mineDiamond

发现一个bug，左侧为最新开发版，右侧为该PR版本，账号名称右侧显示成了"..."，但是是有足够空间的

就目前而言，“快捷启动”是一个临时的、一次性的动作。用户点击“启动并进入世界”时，这个意图只对本次启动有效，不应该被保存。 而HMCLGameRepository管理版本文件和持久化配置，不适合持有一次性、临时的字段，我之前在VersionSetting中添加了新的字段，不过目前由于设置功能删掉这个字段也就删掉了，我认为不需要修改什么，除非未来添加了设置不同预设的功能再根据情况持有快速启动字段。

在windows上双击标题就是全屏，或者表现为全屏，此时不会显示任务栏 https://github.com/user-attachments/assets/92582edd-cb3d-419d-919e-4e50bb58ab98 即便区分全屏和最大化，有几点的表现也不正确 1. 这个合理了 2. 双击最大化明明没全屏，后按F11却显示“按ESC可退出全屏模式” 3. 依旧不合理 4. 依旧不合理

如果可以的话，请给出整合包的下载链接

根据我的测试，问题在整合包中的jade mod（名字为`[玉 🔍] Jade-1.20.1-Forge-11.13.2.jar`），该mod名称中含特殊图标🔍，HMCL无法正确读取该图标，导致出错 解决方法是重命名该mod，使其不包含🔍字符。

进一步测试，似乎HMCL对压缩包内任意文件名存在emoji就会读取出错

> > 根据我的测试，问题在整合包中的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...

w，怪了怪了，看来还要再研究研究

我简单研究一下，如果只出现一处含emoji的标题确实不会出错，但是如果有含有其它非ASCII字符（不一定是emoji）时就会出错了，若含有多个包含emoji而不包含非emoji的非ASCII名称，也不会出错。 根据测试，出错的主要原因是checkUTF8方法调用的zc.toString使用的却是GBK(GB18030)来解码，导致出错 调用checkUTF8时条件为 ```java 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的解码器就会解码失败从而抛出异常。