java升级到1.8解压文件时出现问题答案

【问题标题】：Issue while unzipping file on java upgrade to 1.8java升级到1.8解压文件时出现问题
【发布时间】：2016-05-31 10:03:19
【问题描述】：

Java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)

我正在使用核心 java.util.zip 类。现在在使用此代码解压缩客户端文件时：

public static InputStream unzip(String file,InputStream zip)
        throws IOException {
    file = file.toLowerCase();
    ZipInputStream zin = new ZipInputStream(new BufferedInputStream(zip));
    ZipEntry ze;
    while( (ze = zin.getNextEntry()) != null ) {
        if ( ze.getName().toLowerCase().equals(file) )
            return zin;
    }
    throw new RuntimeException(file+" not found in zip");
}

我收到以下错误：

invalid entry size (expected 1355916815 but got 5650884111 bytes)

但是，相同的代码在 JDK 1.6 中也能正常工作。

我找了一天也没有发现Java JDK中有与此代码对应的任何更改。

请帮助我找到合适的原因或链接来支持我的发现。

【问题讨论】：

标签： java java-8 jdk1.6 zipinputstream

【解决方案1】：

嗯，1355916815 == (int) 5650884111L 而5650884111 是一个数字，不能使用为 ZIP 格式的大小字段保留的四个字节来表示。

既然你说它在 Java 6 中工作，它不支持 ZIP64 格式，我们可以得出结论，你有一个 ZIP 文件实际上不支持 5650884111 字节的文件，而是由工具生成的它只是忽略了这个限制，只存储了实际大小的低 32 位。

显然，由于提取过程的原因，无效文件碰巧起作用了。它通过处理压缩字节并使用存储在标头中的未压缩大小验证生成的字节数，之后。当提取的字节数存储在 32 位 int 变量中并在提取过程中静默溢出并且仅在最后验证时，它似乎与存储的 32 位大小相同。

由于介于 Java 6 和 Java 8 之间，添加了 ZIP64 支持，我想现在解码器已更改为使用 long 变量，这是合理的，因为可以使用相同的解码器来处理两者，旧的 ZIP 和 ZIP64 文件。然后，提取的字节数不再溢出，并且注意到存储的大小1355916815 与实际提取的5650884111 字节数不匹配。

除非您需要支持 Java 6，否则（重新）将文件创建为有效的 ZIP64 文件应该可以解决问题。

(ZIP64 support has been added in Java 7)

【讨论】：