編碼問題很討厭。昨天就碰到了乙個，花了幾個小時才解決。
使用dotnetzip這個庫自動打包資料夾，原來的**是：
var dir = new directoryinfo(@"c:\foo");using (zipfile zip = new zipfile(encoding.utf8))
看上去很正常，也似乎能work，成功打包，用7-zip開啟，裡面的中文資料夾也顯示正常。
但是，如果是用7-zip手工打包的zip，在資源管理器裡雙擊可以看到裡面的資料夾。而這個用**生成的zip，如果打包進去的是中文資料夾，雙擊卻顯示空白。這似乎不成問題，但因為我打包的都是pdg檔案（某電子書格式檔案，不懂的一搜便知），本來直接把zip字尾改成uvz，便可用乙個叫做unicornviewer的軟體閱讀，而這個用**生成的zip，改名後卻用unicornviewer打不開，提示開啟失敗。
英文資料夾可以，中文資料夾不行，似乎很可能是「編碼問題」。
用下面的**檢視zip的屬性：
using (zipfile zip = zipfile.read("foo.zip")))
}}
結果發現，用7-zip打包的檔案，entry的alternateencoding顯示為ibm437，filename屬性顯示為亂碼，比如「世界第一位六冠王趙國榮實戰**」，顯示為「╩└╜τ╡┌╥╗╬╗┴∙╣┌═⌡╒╘╣·╚┘╩╡╒╜╫¿╝¡」。
查了很多資料，除錯了半天，最後終於理解了，原來這是用ibm437去解碼gb2312/gbk編碼的字串的結果。理解了這一點，修改**：
var dir = new directoryinfo(@"c:\foo");byte bytes = encoding.getencoding("gb2312").getbytes(dir.name.tochararray());
string newname = encoding.getencoding("ibm437").getstring(bytes);
using (zipfile zip = new zipfile(encoding.utf8))
測試通過。
以前碰到的編碼問題，多是將亂碼轉成正常顯示的字元，這次卻要故意生成「亂碼」才能工作正常，呵呵。管他呢，反正it just works。
Python爬蟲的乙個編碼問題
今天在爬取 博時楊銳 這個網頁的時候，程式報錯 unicodeencodeerror ascii codec can t encode characters in position 32 34 ordinal not in range 128 我以為這是程式編碼的問題。結果根據報錯的 尋找到的結果發...
golang 乙個複雜的中文編碼問題
今天在網上遇到乙個問題，覺得挺有意思，就幫人解答了。在編碼為latin1的mysql資料庫中插入中文資料，由另乙個系統將latin1編碼的字串轉碼為gbk後作為簡訊內容發出。import golang.org x text encoding charmap golang.org x text enc...
乙個關於Unicode字元編碼的奇怪問題
有乙個學員問了乙個關於unicode字元編碼的奇怪問題。問題如下 string strchina 中國 1 直接把每個字元中的內容對應著的整數列印出來，顯示的結果就是這個字元的unicode碼，則下面的 for int i 0 i 列印出的結果是 4e2d 56fd 2 下面的 byte buf s...