其實這個問題自從給家父換用 Fedora 後便遇到了，似乎總是有那麼一兩個人喜歡使用 zip 格式壓縮下無論是多麼小的文件。兩三個 GNOME 版本更新卻仍然如此，實在奇怪。於是這次坐下來查了查，才發覺這是一個大坑。
接下來的內容可以說是在下根據網上查找一些資料的驗證/解決方案。沒什麼技術含量，隨便哪個思維正常的 SA 都會做。記錄下來，只是因為搜索引擎給出中文結果都已經不生效了！
**** 問題重現
很簡單，在一台 Win 系統的設備上創建一個以中文命名的空白文件，然後用 7-zip 或者其他任意壓縮工具壓縮城 zip 格式。
將生成的文件復制到 Linux 系統下，嘗試打開。
至少在 Fedora 23 上，無論使用 GNOME 桌面的 File-Roller 或者終端的 unzip 結果都是亂碼的。
**** 錯誤嘗試
放狐搜索出來的結果前幾個：
unzip 使用 -O 選項指定編碼這個當年的隱藏參數在 6.0 版本中已經完全沒有了
convmv 轉換編碼不少文章提出使用這個方式 convmv -f gbk -t utf8 -r MY_DIR
實際上 convmv 會匯報文件名已經是 UTF-8 的了，不會做任何操作。
這樣的結果不奇怪，畢竟 Win 也早經過了 XP 時代，中文 Linux 也默認 UTF-8 很久了。
p7zip 解壓 zip 文件無論是使用 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 恐怕是最快最便捷的臨時解決方案了。其他的中文搜索結果給出的方案，都不可行。
