HMCL-dev
[Bug] 无法导入整合包
问题描述 | Bug Description
无法导入整合包,提示"下载的文件已损坏",多次更换下载源后也无法解决问题
启动器崩溃报告 / 启动器日志文件 | Launcher Crash Report / Launcher Log File
hmcl-exported-logs-2025-11-13T22-49-47.zip
这是一个内部整合包,通过特殊方式分发,但我可以尝试使用Magnet的方式分享给你,使用 我会持续做种 Magnet:magnet:?xt=urn:btih:19021e37e8975d2846585495bfd14072cf4bc762&dn=CRAFT+OF+DUTY+1.3.5%28%E7%9B%B4%E6%8E%A5%E6%8B%96%E5%85%A5%E5%90%AF%E5%8A%A8%E5%99%A8%E5%AE%89%E8%A3%85%29.zip
根据我的测试，问题在整合包中的jade mod（名字为[玉 🔍] Jade-1.20.1-Forge-11.13.2.jar），该mod名称中含特殊图标🔍，HMCL无法正确读取该图标，导致出错
解决方法是重命名该mod，使其不包含🔍字符。
谢谢你,但是我不知道此问题是否仍然需要保持开放
可以继续开放但也可以关闭 然后开个子问题: 当整合包内有模组名称含有emoji图标时无法正确导入 也可以改此issue的标题和内容
根据我的测试，问题在整合包中的jade mod（名字为
[玉 🔍] Jade-1.20.1-Forge-11.13.2.jar），该mod名称中含特殊图标🔍，HMCL无法正确读取该图标，导致出错 解决方法是重命名该mod，使其不包含🔍字符。
问题是HMCL实际上能读取
也就是说hmcl可以解析这个jar文件里面的东西，但是无法解析包含这个jar文件的压缩包
这纯粹是JDK的问题了
根据我的测试，问题在整合包中的jade mod（名字为
[玉 🔍] Jade-1.20.1-Forge-11.13.2.jar），该mod名称中含特殊图标🔍，HMCL无法正确读取该图标，导致出错 解决方法是重命名该mod，使其不包含🔍字符。问题是HMCL实际上能读取
也就是说hmcl可以解析这个jar文件里面的东西，但是无法解析包含这个jar文件的压缩包
这纯粹是JDK的问题了 ZipFileSystem.java
private final void checkUTF8(byte[] a) throws ZipException { try { int end = a.length; int pos = 0; while (pos < end) { // ASCII fast-path: When checking that a range of bytes is // valid UTF-8, we can avoid some allocation by skipping // past bytes in the 0-127 range if (a[pos] < 0) { zc.toString(Arrays.copyOfRange(a, pos, a.length)); break; } pos++; } } catch(Exception e) { throw new ZipException("invalid CEN header (bad entry name)"); } }
我已经说了“HMCL对压缩包内任意文件名存在emoji就会读取出错”这个结论（我把JDK的问题也作为HMCL的问题了，我个人倾向于把依赖环境的问题也当成软件自己的问题一样对待，不过这可能造成误解了，抱歉）
我在自己电脑上搞了个multimc整合包，里面也打包了一个名字含emoji的mod，导出再重新导入后没有出现问题 系统：macOS 26.1 JDK：zulu-17.0.17
这咋回事（
我简单研究一下，如果只出现一处含emoji的标题确实不会出错，但是如果有含有其它非ASCII字符（不一定是emoji）时就会出错了，若含有多个包含emoji而不包含非emoji的非ASCII名称，也不会出错。
根据测试，出错的主要原因是checkUTF8方法调用的zc.toString使用的却是GBK(GB18030)来解码，导致出错
调用checkUTF8时条件为
if (zc.isUTF8() || (flag & FLAG_USE_UTF8) != 0) {
checkUTF8(inode.name);
} else {
checkEncoding(inode.name);
}
两个条件的操作符是“或”，这导致如果CEN header的general purpose bit flag声明自己使用的是utf-8，不管目前的解码器zc究竟是什么编码，也能导致checkUTF8执行，但是却可能使用的是错误的解码器去解码utf-8内容，导致出错，比如在这里使用的是GB18030编码。
不过我也没搞懂为什么解码器类型有时出错有时又不出错的
根据我的测试，我的判断如下： 通常来说，部分压缩软件倾向于使用GBK编码保存文件名称（在我的Windows上），但是GB18030规范中虽然包含emoji，很多压缩软件会在包含emoji的文件名使用utf-8保存。 这导致如下结果：
- 如果全部使用ASCII字符，Java会把他当作utf-8来解码，但是这个没问题，因为utf-8和GBK都兼容ASCII。
- 如果存在中文但是不存在emoji，压缩软件会使用GBK编码，Java也会使用GBK解码，这也没问题。
- 如果存在且仅存在含emoji的中文，压缩软件会使用utf-8编码，Java也会使用utf-8解码，这也没问题。
- 如果同时存在不包含emoji的中文和包含emoji的中文，其中前者会使用GBK编码，后者会使用utf-8编码，但是ZipFileSystem的实现中，默认一个压缩文件的编码是不变的，不会中途更改解码器类型，Java会使用GBK解码，此时遇到其它正常文本是正常的，但当解码到存在emoji的utf-8文本时，GBK的解码器就会解码失败从而抛出异常。
