使用java.util.zip将带有日文字符的文件名写入zip文件时会变成垃圾*

我有一个名称包含日语字符的目录，我需要使用java.util.zip中的zip utils将其写入zip文件。写入zip文件成功，但当我使用Windows内置的压缩文件实用程序或7-zip打开生成的zip文件时，名称中包含日语字符的目录将显示为一堆垃圾字符。我的系统上安装了日语/东亚语言包——我可以用日语名称创建目录，所以这不是问题所在

有趣的是，如果我使用java.util.zip编写一个单独的脚本来读取生成的zip文件，那么目录名是正确的，并且我可以将zip的内容提取到适当命名的目录中，使用日语字符。但我无法使用我尝试过的商业zip工具来实现这一点，这无疑是我们的客户想要做的

关于是什么导致了这个问题，以及我如何解决这个问题，有什么想法吗

---

我知道，但是我仍然需要解决这个问题。

如果java.util.zip仍然像，我不确定是否可能（使用内置类）。我以前见过上面提到的方法，但从未使用过。

J2SEAPI始终使用UTF-8（八个） 条目的位（Unicode字符集） 名称和注释，而不是CP437 （又称IBM437，真正的IBM-PC 字符集），该字符集由 来自PKWARE的事实上的标准PKZIP。 因此，您无法读或写 带有国际条目的ZIP文件 文件名，例如“täscht.txt” 在由（南方）创建的ZIP文件中 德语

[省略其他问题的说明]

TrueZIP库是为了克服这些限制/缺点而开发的

---

奇迹确实发生了，Sun/Oracle确实修复了长期存在的bug/rfe：

现在可以[在创建时设置文件名编码][1]zip文件/流（需要Java 7）

---

[1] ：，java.nio.charset.charset）

问得好。如果您可以使用脚本提取它，并在最后获得正确的文件名，这意味着这些字符的编码方式支持这些字符，例如Shift JIS或UTF-8。它们肯定是UTF-8或Java版本。请参阅此链接：我不知道TrueZIP库，但该评论有点误导。“事实上的标准”PKZIP软件PKWARE的制造商发布了该格式的实际规范。该规范允许使用CP437或UTF-8。如果ZIP应用程序符合规范，则可以使用任意一种编码。因此，“您不能用i18n化的条目名读取或写入ZIP文件”的说法通常是不正确的。任何应用程序都可以符合该规范（也不清楚-我不确定在德国南部有什么关系）。尽管如此，一些应用程序和zip工具并不完全符合该规范，特别是2007年9月首次添加的UTF-8部分。因此，例如，Windows Vista“压缩文件夹”无法正确读取条目名称用UTF-8编码的.ZIP文件。不确定Mac内置的zip工具。我也不确定J2SEAPI是否符合zip规范的Sept2007修订版。尽管规范中支持UTF-8，但J2SEAPI可能比规范早，并且在Unicode支持方面做了一些超出规范的事情。非常有用。依我看，这应该是它自己的答案（和投票）。我认为“南部德语”部分仅仅是一个轻率的动机，因为条目名称包含非ascii字符“ä”。很高兴它提供了信息。我对此发表了评论，因为对于如何用Java解决这个问题，我没有任何好的想法。所以你的答案仍然是最好的！只是想补充一下。。。文章说“ZIP文件格式不支持Unicode。文件名在内部只是8位字符串，没有定义的字符集或Unicode编码（afaik）。这意味着文件的编写者和读者必须就相互理解的格式达成一致。”这从来都不是完全正确的。在作者2005年发表这篇文章时，编码是IBM437。对于需要该字符集之外的内容的字符，没有达成一致意见。2007年，PKZIP将UTF-8添加到规范中。正如Kaleb所说，现在还不清楚J2SE是否进化到支持该规范更新。我想不会。我试过使用Chilkat库，但结果比使用标准的zip实用程序差。哇，这是个好消息。我们的客户还需要一段时间才能从中受益，但我很高兴这不仅仅是一个溃烂的伤口。