在Java上將文件解壓縮時升級到1.8時出現的問題

Question

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中的此代碼相對應的任何更改的任何情況。

請幫助我找到合適的原因或鏈接以支持我的發現。

Answer 1

好吧， 1355916815 == (int) 5650884111L而5650884111是無法使用為ZIP格式的size字段保留的四個字節表示的數字。

如您所言，它在不支持ZIP64格式的Java 6中工作，我們可以得出結論，您有一個ZIP文件，該文件實際上不支持5650884111字節的文件，而是由一個忽略了該限制的工具生成的並僅存儲實際大小的低32位。

顯然，無效文件是由於這種方式偶然起作用的，提取過程得以實現。 通過處理壓縮后的字節， 然后使用頭中存儲的未壓縮大小來驗證所得的字節數，從而工作。 當提取的字節數存儲在32位int變量中並且在提取過程中無提示地溢出並且僅在最后進行驗證時，它看起來與存儲的32位大小相同。

我想自從在Java 6和Java 8之間增加了對ZIP64的支持之后，我想現在解碼器已更改為使用long變量，這很合理，因為同一解碼器可用於處理舊的ZIP和ZIP64文件。 然后，提取的字節數不再溢出，並且注意到存儲的大小1355916815與實際提取的5650884111字節數不匹配。

除非您需要支持Java 6，（重新）將該文件創建為有效的ZIP64文件應該可以解決該問題。

（ 在Java 7中添加了ZIP64支持 ）