Python Unicode編碼

標籤：介面   核心編程   檔案   串處理   經理   詳細   結果   修複   padding   

提示

事實上，只要遵守以下規則，可以規避90%由於Unicode字串處理引起的bug，剩下的10%通過python的庫和模組能夠解決。

• 程式中出現字串時一定要加個首碼u。

• 不要用str()函數，用unicode()代替。

• 不要用過時的string模組——如果傳給它的是非ASCII字元，它會把一切搞砸。

• 不到必須時不要在你的程式裡面解碼unicode字元。只在你要寫入檔案或資料庫或者網路時，才調用encode()函數；相應地，只在你需要把資料讀回來的時候才調用decode()函數。

從現實中得來的教訓

失誤#1：你必須在一個極有限的時間內寫出一個大型的應用，而且需要其他語言的支援，但是產品經理並沒有明確定義這一點。你並沒有考慮Unicode的相容，知道項目快要結束……這時候再添加Unicode的支援幾乎不太可能，不是嗎？

結果#1：沒能預測到終端使用者對其他語言介面的需求，在整合他們用的面向其他語種的應用時又沒有使用Unicode支援。更新整個系統即讓人覺得枯燥，又浪費時間。

失誤#2：在源碼中到處使用string模組或者str()和chr()函數。

結果#2：通過全域的尋找替換把str()和chr()替換成unicode()和unichr(),但是這樣一來很可能就不能再用pickle模組，要用的話只能把所有要pickle處理的資料存成二進位形式，這樣一來就必須修改資料庫的結構，而修改資料庫結構意味著全部推到重來。

失誤#3：不能確定所有輔助系統都完全地支援Unicode。

結果#3：不得不去為那些系統打補丁，而其中有些系統可能你根本就沒有源碼。修複對Unicode支援的bug可能會降低代碼的可靠性，而且非常有可能引入新的bug。

總結：使應用程式完全支援Unicode，相容其它的語言本身就是一個工程。它需要詳細的考慮、計劃。所有涉及的軟體、系統都需要檢查，包括python的標準庫和其他將要用到的第三方擴充模組。你甚至有可能需要組建一個經驗豐富的團隊來專門負責國際化（I18N）問題。

節選自《python核心編程（第二版）》P130、P131

Python Unicode編碼