2. 程式人生 > >關於Java解壓檔案的一些坑及經驗分享

關於Java解壓檔案的一些坑及經驗分享

阿新 • • 發佈：2019-02-09

就在本週， 測試人員找到我說現上的需求文件(zip格式的)無法預覽了， 讓我幫忙看看怎麼回事。 
這個功能也並不是我做的， 於是我便先看看線上日誌有沒有什麼錯誤，果不其然， 後臺果然報錯了。 
此處輸入圖片的描述

java.lang.IllegalArgumentException:MALFORMED
   at java.util.zip.ZipCoder.toString(ZipCoder.toString:58)
   ...
  • 1
  • 2
  • 3

異常大致是這樣，前臺無法預覽需求文件的原因是該zip檔案解壓失敗了。 
首先網上查了下這個異常的原因， 都說是因為編碼的問題， 要求將UTF-8改成GBK就可以了。 
然後定位程式碼， 看到有一個方法：unzip()

public static void unzip(File zipFile, String descDir) {
    try {
        File pathFile = new File(descDir);
        if (!pathFile.exists()) {
            pathFile.mkdirs();
        }
        ZipFile zip = getZipFile(zipFile);
        for (Enumeration entries = zip.entries(); entries.hasMoreElements(); ) {
            ZipEntry entry = (ZipEntry) entries.nextElement();
            String zipEntryName = entry.getName();
            if
 
 (StringUtils.isNotBlank(pre)) {
                zipEntryName = zipEntryName.substring(pre.length());
            }
            InputStream in = zip.getInputStream(entry);
            String outPath = (descDir + "/" + zipEntryName).replaceAll("\\*", "/");
            ;
            //判斷路徑是否存在,不存在則建立檔案路徑
            File file = new
 
 File(outPath.substring(0, outPath.lastIndexOf('/')));
            if (!file.exists()) {
                file.mkdirs();
            }
            //判斷檔案全路徑是否為資料夾,如果是上面已經上傳,不需要解壓
            if (new File(outPath).isDirectory()) {
                continue;
            }
            //輸出檔案路徑資訊
            LOG.info("解壓檔案的當前路徑為:{}", outPath);
            OutputStream out = new FileOutputStream(outPath);
            IOUtils.copy(in, out);
            in.close();
            out.close();
        }
        zip.close();
        LOG.info("******************解壓完畢********************");

    } catch (Exception e) {
        LOG.error("[unzip] 解壓zip檔案出錯", e);
    }
}

private static ZipFile getZipFile(File zipFile) throws Exception {
    ZipFile zip = new ZipFile(zipFile, Charset.forName("UTF-8"));
    Enumeration entries = zip.entries();
    while (entries.hasMoreElements()) {
        try {
            entries.nextElement();
            zip.close();
            zip = new ZipFile(zipFile, Charset.forName("UTF-8"));
            return zip;
        } catch (Exception e) {
            zip = new ZipFile(zipFile, Charset.forName("GBK"));
            return zip;
        }
    }
    return zip;
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56

於是便將線上的zip檔案down下來 然後本地除錯下， 發現在第9行中丟擲了異常， 如下程式碼：

ZipEntry entry = (ZipEntry) entries.nextElement();
  • 1

再由最開始的異常日誌找到ZipCoder中的58行:

String toString(byte[] ba, int length) {
    CharsetDecoder cd = decoder().reset();
    int len = (int)(length * cd.maxCharsPerByte());
    char[] ca = new char[len];
    if (len == 0)
        return new String(ca);
    // UTF-8 only for now. Other ArrayDeocder only handles
    // CodingErrorAction.REPLACE mode. ZipCoder uses
    // REPORT mode.
    if (isUTF8 && cd instanceof ArrayDecoder) {
        int clen = ((ArrayDecoder)cd).decode(ba, 0, length, ca);
        if (clen == -1)    // malformed
            throw new IllegalArgumentException("MALFORMED");
        return new String(ca, 0, clen);
    }
    ByteBuffer bb = ByteBuffer.wrap(ba, 0, length);
    CharBuffer cb = CharBuffer.wrap(ca);
    CoderResult cr = cd.decode(bb, cb, true);
    if (!cr.isUnderflow())
        throw new IllegalArgumentException(cr.toString());
    cr = cd.flush(cb);
    if (!cr.isUnderflow())
        throw new IllegalArgumentException(cr.toString());
    return new String(ca, 0, cb.position());
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25

這裡只有UTF-8才會進入if邏輯才會拋錯？果然如網上所說， 將編碼格式改為GBK即可。 
ZipCoder這個類似src.zip包中的， 既然這裡做了check當然會有它的道理， 單純的改為GBK來解決這個bug顯然是不合理的。

於是便要換種思路了， 線上有些zip是仍然可以預覽的。 我將線上的zip檔案解壓後， 在自己電腦重新打個包（我用的是好壓）， 然後又運行了上述程式碼， 竟然解壓成功？？ 這是為什麼？ 於是上網上找了一下， 果然找到了答案：

Windows 壓縮的時候使用的是系統的編碼 GB2312，而 Mac 系統預設的編碼是 UTF-8，於是出現了亂碼。

最後去問了上傳的同事， 他是在Windows下用的winRar上傳的(看來不同的解壓工具還不同)。 
好了， 問題基本定位到了， 這裡就要想著怎麼解決了。 
又是一通找， 終於：

Apache commons-compress 解壓 zip 檔案是件很幸福的事，可以解決 zip 包中檔名有中文時跨平臺的亂碼問題，不管檔案是在 Windows 壓縮的還是在 Mac，Linux 壓縮的，解壓後都沒有再出現亂碼問題了。

看到這裡基本上問題就要解決了， 於是開始使用apache的commons-compress了， 下面直接上程式碼， 程式碼是基於上面程式碼進行改造的： 
首先引入pom檔案：

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-compress</artifactId>
    <version>1.8.1</version>
</dependency>
  • 1
  • 2
  • 3
  • 4
  • 5
public static void main(String[] args) throws Exception{
    String path = "C:\\Users\\Isuzu\\Desktop\\test.zip";
    unzip(new File(path), "D:\\data",);
}

public static void unzip(File zipFile, String descDir) {
    try (ZipArchiveInputStream inputStream = getZipFile(zipFile)) {
        File pathFile = new File(descDir);
        if (!pathFile.exists()) {
            pathFile.mkdirs();
        }
        ZipArchiveEntry entry = null;
        while ((entry = inputStream.getNextZipEntry()) != null) {
            if (entry.isDirectory()) {
                File directory = new File(descDir, entry.getName());
                directory.mkdirs();
            } else {
                OutputStream os = null;
                try {
                    os = new BufferedOutputStream(new FileOutputStream(new File(descDir, entry.getName())));
                    //輸出檔案路徑資訊
                    LOG.info("解壓檔案的當前路徑為:{}", descDir + entry.getName());
                    IOUtils.copy(inputStream, os);
                } finally {
                    IOUtils.closeQuietly(os);
                }
            }
        }
        final File[] files = pathFile.listFiles();
        if (files != null && files.length == 1 && files[0].isDirectory()) {
            // 說明只有一個資料夾
            FileUtils.copyDirectory(files[0], pathFile);
            //免得刪除錯誤， 刪除的檔案必須在/data/demand/目錄下。
            boolean isValid = files[0].getPath().contains("/data/www/");
            if (isValid) {
                FileUtils.forceDelete(files[0]);
            }
        }
        LOG.info("******************解壓完畢********************");

    } catch (Exception e) {
        LOG.error("[unzip] 解壓zip檔案出錯", e);
    }
}

private static ZipArchiveInputStream getZipFile(File zipFile) throws Exception {
    return new ZipArchiveInputStream(new BufferedInputStream(new FileInputStream(zipFile)));
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48

到了這裡就大功告成了， 原先自己遇到這個問題時百度了一圈， 解決方案大都是改編碼格式為GBK， 但那也只是治標不治本的方法， 解壓的坑就講這麼多， 後續有新的坑還會繼續總結出來的。

相關推薦

關於Java解壓檔案的一些坑及經驗分享

就在本週， 測試人員找到我說現上的需求文件(zip格式的)無法預覽了， 讓我幫忙看看怎麼回事。  這個功能也並不是我做的， 於是我便先看看線上日誌有沒有什麼錯誤，果不其然， 後臺果然報錯了。  java.lang.IllegalArgumentException:MAL

java 小工具之--zip包解壓，刪除目錄及文件、

str 備份 odin .get flag source input director 使用 import org.apache.tools.ant.BuildException;import org.apache.tools.ant.Project;import org

java壓縮解壓檔案

記錄一下,公司在伺服器中,需要對檔案進行壓縮,然後給使用者下載故記錄一下: import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOExc

ubuntu壓縮及解壓檔案

1.壓縮zip # zip -r archive_name.zip directory_to_compress 2.tar只是打包並不壓縮，好處就是它只消耗非常少的CPU以及時間去打包檔案 # tar -cvf archive_name.tar directory_to_compress

java 多執行緒上傳解壓檔案

舉個公司專案開發遇到的一個簡單例子，使用者上傳壓縮檔案到伺服器後，要對該壓縮包進行兩個操作，一是將該壓縮包複製到指定目錄，一是將該壓縮包解壓到另一指定目錄，最終響應使用者提示檔案上傳成功。如果壓縮包很大的話，上傳後進行的複製和解壓功能也會佔用很長時間，使用者就會等待很長的

java 解壓zip中文檔案 出現錯誤

java  解壓zip中文檔案 出現錯誤 java.lang.IllegalArgumentException: MALFORMED 解決這個錯誤需要 jdk 1.7及以上版本支援 並在建立ZipFile 時指定中文字符集gbk ZipFile zipFile = new

使用java解壓GZip檔案

Java中有可以直接解壓gzip檔案的輸入流。 /** * 獲取檔名（去掉.gz字尾） * @param path * @return */ public static String getPrefix(String path) {

scala和java解壓zip的檔案，並上傳到hdfs伺服器

之前一直使用的事java開發的，後來學習hadoop，spark以後，需要做一個解壓檔案到伺服器的例子，由於學習scala時間不長，故先用java程式碼寫出來，在改成scala的程式碼，過程中出現了很多問題，我將會在最後說明，請大家注意不要少了包。 環境宣告：windows

win10解壓安裝mysql方法及遇見的問題(缺少MSVCR120.dll檔案、服務無法啟動）

WIN10系統MYSQL的下載與安裝詳細教程第一步：下載MySQL具體過程如下： 1.選擇要下載的型別，64位還是32位：*點選download後就會到下圖的下載介面，這時最顯眼的是sign up,有些人會覺得需要先註冊賬號才能下載，點選圖中紅色的，直接免註冊下載。平時再下載

Java解壓zip檔案(支援中文字元檔案)

昨天接到了一個解壓zip檔案的任務,所以今天在做任務之前，便寫demo試了一下, 部分思路參考自:這裡 貼上程式碼: public void Decompressing2() throws IOException { String pa

java解壓zip檔案例項

package test; import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.InputStream; import java.

[java]使用junrar解壓檔案時，上報解壓進度的具體實現

筆者在公司專案中有一個需要解壓10G的rar的壓縮包的一個需求，那麼我們希望能夠上報整個解壓的進度。google/baidu上均沒有找到合適的辦法。後來看了下junrar的原始碼，發現實現UnrarCallback介面後，可以完成進度的上報監測。 經驗之談就是

java解壓zip、rar（多級檔案）

/**      * 解壓上傳檔案          * @param importZipFilePath      * 上傳檔案地址      * @param importFilePath      * 解壓檔案存放地址      * @param cancel   

使用JAVA解壓加密的中文ZIP壓縮包

sts write trace != 加密 div util lis 資源 近來項目中需要對ZIP壓縮包解壓，然後將解壓後的內容存放到指定的目錄下。 該壓縮包的特性： 使用標準的zip壓縮格式（壓縮算法沒有深入探究） 壓縮包中帶有目錄並且目錄名稱是中文 壓縮時加了密碼

Java 解壓zip壓縮包

ice gin inpu ret zipentry .get get next exce 因為最近項目需要批量上傳文件，而這裏的批量就是將文件壓縮在了一個zip包裏，然後讀取文件進行解析文件裏的內容。 因此需要先對上傳的zip包進行解壓。以下直接提供代碼供參考： 1.第一個

java解壓zip文件至指定文件夾

ava tel exceptio 失敗 ppr mark roc types EDA 前面，筆者講到。如何把文件打包為zip包，那麽反過來怎麽把zip文件包解壓為正常文件呢？把zip包解壓為正常文件包，要比把文件打包為zip簡單一點。因為存在多級文件的壓縮，卻不存在多級文件

Zip4j解壓檔案

使用 zip4j 可以快速對檔案進行解壓縮處理 更多精彩 更多技術部落格，請移步 asing1elife’s blog 官網 zip4j 特性 支援Zip檔案的建立、新增、解壓、更新、移除 可讀寫有密碼保護的Zip檔案

解壓版MYSQL安裝及遇到的錯誤

1 安裝 在 MYSQL官網 進行下載相應的解壓版本，然後放在你所想的目錄下。 解壓內容如下： 然後我們需要去建立一個名為my.ini檔案，注意檔案字尾一定要是.ini結尾，如果檔案字尾隱藏了，可以將其勾選上，如圖： 建立檔案：my.ini。 其內容如下： [cli

php 解壓檔案與壓縮檔案

配置環境變數 然後cmd 輸入 php -m 檢視是否有zip 選項 沒有的話zip功能將無法使用 function zip_file(string $filename) { if (!is_file($filename)) { return false;

Python使用urllib下載檔案以及使用zipfile解壓檔案

首先定義檔案下載路徑，檔名 import os from six.moves import urllib import zipfile DATA_URL = 'https://archive.ics.uci.edu/ml/machine-learning-databases/00240/UCI%