File Roller/Unzip 解壓中文 Zip 檔名亂碼

2020-06-16 17:45:43

其實這個問題自從給家父換用 Fedora 後便遇到了，似乎總是有那麼一兩個人喜歡使用 zip 格式壓縮下無論是多麼小的檔案。兩三個 GNOME 版本更新卻仍然如此，實在奇怪。於是這次坐下來查了查，才發覺這是一個大坑。

接下來的內容可以說是在下根據網上查詢一些資料的驗證/解決方案。沒什麼技術含量，隨便哪個思維正常的 SA 都會做。記錄下來，只是因為搜尋引擎給出中文結果都已經不生效了！

**** 問題重現

很簡單，在一台 Win 系統的裝置上建立一個以中文命名的空白檔案，然後用 7-zip 或者其他任意壓縮工具壓縮城 zip 格式。

將生成的檔案複製到 Linux 系統下，嘗試開啟。

至少在 Fedora 23 上，無論使用 GNOME 桌面的 File-Roller 或者終端的 unzip 結果都是亂碼的。

**** 錯誤嘗試

放狐搜尋出來的結果前幾個：

這個當年的隱藏引數在 6.0 版本中已經完全沒有了

不少文章提出使用這個方式 convmv -f gbk -t utf8 -r MY_DIR

實際上 convmv 會匯報檔名已經是 UTF-8 的了，不會做任何操作。

這樣的結果不奇怪，畢竟 Win 也早經過了 XP 時代，中文 Linux 也預設 UTF-8 很久了。

無論是使用 7za 還是 7z，亂碼依舊

放鴨搜尋出來的結果倒是很有趣：

根據記錄，這個 Bug 最早匯報於 2005 年的 file-roller 2.14 版本。 40 個長長的評論中提到了在終端使用 unar 臨時解決方案和為何 unar 現在沒被當作處理 zip 檔案的首選方案。

嗯，當然 unar 可以處理這個問題，好歹是 FSF 當年認定的 rar v3 解壓的完美開源解決方案。

其間還提到了 unzip 6.10 版本和 libnatspec 庫已經解決了這個問題。很遺憾，經過在下快速的嘗試，單純使用 unzip 官方提供的 6.10 Beta 原始碼配合 libnatspec 並不能解決該問題。況且更重要的是 unzip 6.10 的正式發布遙遙無期。

很顯然這個問題延伸到了 Mate，在其 Issue Tracker 上有開發者指出了這個其實是 zip 建立軟體的問題，若是在 UTF-8 的 Linux 系統上用 p7zip 建立 zip 則不會有類似問題。在一番激烈的討論之後，什麼方案也沒有，沒有，沒有……

**** 結論：坑仍在

目前，對於所有不幸收到包含非 ASC-II 編碼檔名的 zip 文件的 Linux 使用者來講，在終端使用 unar 恐怕是最快最便捷的臨時解決方案了。其他的中文搜尋結果給出的方案，都不可行。