關於程式使用非英文系的部份，通常都很難搞。
難搞是在於，沒有想通，怎麼搞都會錯。
我原本以為，我上次參考的文件就解決了所有的事。
結果當然不是。如果是，我也不會寫這篇了。
現在，我搞懂了兩個部份。
第一個是程式使用中文的部份。
仔細地說，是，其他地方產生的中文字串被程式使用的部份。
例如從檔案讀字串，或從使用者輸入的地方讀字串。
這個部份會出錯的地方常見於「輸出亂碼至畫面」、「輸出亂碼到檔案」。
在這種時間，最常使用方法是，「先轉成 unicode」，
可以是utf16，也可以是utf8，只要轉得過去，就可以轉成想要的。
一個經典句如下：
unicode(i.decode('cp950')).encode('cp950')
這就是強迫從 cp950 轉成 unicode，再轉回 cp950。
這樣寫就是當你知道來源編碼及目的編碼時，保證一定不會出問題的寫法。
當然也可以不要這麼費工，例一：知道來源編碼與系統編碼一樣，可以省 decode 那段。
例二：知道目的編碼與系統編碼一樣，可以省 encode 那段。
例三：……
第二個是程式碼內的問題。
我們會在程式碼的地方，宣告某變數是某個中文字串。
在某些語言不會有問題。
但在 python，唯一解決方法，就是在程式碼開頭宣告
# -*- coding: cp950 -*-
我試了很久在程式碼轉來轉去都轉不對。
目前只有這個方法可以解決。
如果有人有其他方法，可以告訴我。
其實以前在搞 linux 的時候，中文的問題還有更多。
像是 NTFS, FAT32 的檔名編碼固定是 unicode，內容又歸內容的編碼。
ext2, ext3 檔名編碼，內容編碼都可以隨便設定，
檔名轉碼要靠 mount 時指定參數來搞定；內容轉碼可以靠 iconv 來處理。
這些之外，還有 kernel 參數要先搞好。
這幾個就搞死一堆人，還曾引發論戰。現在想想還滿搞笑的。
從這個問題，就出現一些未來會面對到的問題。
目前我們用的是 big5 編碼，MS 在自家系統有加強了一點點，自己叫做 cp950。
以後，編碼總是會慢慢地變動，有些文件，有一天會再也看不出內容是什麼。
也許是杞人憂天啦，不過，不要以為現在的文件，十年後還打得開喔。
要趁還有轉換程式的時候，就轉存成流行的格式。
越扯越遠了。
留言列表
