Python中有兩種字符串，分別是一般的字符串（每個字符用8 bits表示）和Unicode字符串（每個字符用一個或者多個字節表示），它們可以相互轉換。關于Unicode，Joel Spolsky 在 The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) 中有生動的說明，Jason Orendorff 在 Unicode for programmers 有著更為全面的描述，在此我就不再多說什么了。來看下面的代碼：
運行上述代碼，Python會給出下面的錯誤提示
說是遇到非ASCII字符了，并讓我們參考pep-0263。PEP-0263（Python Enhancement Proposal）上面說得很清楚了，Python也意識到了國際化問題，并提出了解決方案。根據提案上面的要求，我們有如下代碼
程序運行的結果如下：
我們可以看到，通過引入編碼聲明，我們可以正常地在使用中文了，而且在code 1和2中，控制臺也能正確的把中文打印出來。但是，很明顯，上面的代碼也反映出了不少的問題： 1、code 1 和 2在使用print時采用了不同的方式，1是直接print，而2在print之前先進行編碼 2、code 1 和 2中在同樣的字符串查找同一個字符“我”，得出的結果不一樣（分別是5和3） 3、code 3 中直接打印unicode字符串 y時出現錯誤（這也是為什么code 2中要先進行編碼的原因）
為什么？為什么？我們可以先在腦海中模擬一下我們使用Python的流程：首先，我們先用編輯器編寫好源代碼，保存成文件。如果源代碼中有編碼聲明而且用的編輯器支持該語法，那么該文件就以相應的編碼方式保存在磁盤中。注意：編碼聲明和源文件的編碼不一定是一致的，你完全可以在編碼聲明中聲明編碼為UTF-8，但是用GB2312來保存源文件。當然，我們不可能自尋煩惱，故意寫錯，而且好的IDE也能強制保證兩者的一致性，但是，如果我們用記事本或者EditPlus等編輯器來編寫代碼的話，一不小心就會出現這種問題的。 得到一個.py文件后，我們就可以運行它了，這是，我們就把代碼交給Python解析器來完成解析工作。解析器讀入文件時，先解析文件中的編碼聲明，我們假設文件的編碼為gb2312，那么先將文件中的內容由gb2312轉換成Unicode，然后再把這些Unicode轉換為UTF-8格式的字節串。完成這一步驟后，解析器把這些UTF-8字節串分段，解析。如果遇到使用Unicode字符串，那么就使用相應的UTF-8字節串創建Unicode字符串，如果程序中使用的是一般的字符串，那么解析器先將UTF-8字節串通過Unicode轉換成相應編碼（這里就是gb2312編碼）的字節串，并用其創建一般的字符串對象。也就是說，Unicode字符串跟一般字符串在內存中的存放格式是不一樣的，前者使用UTF-8的格式，后者使用GB2312格式。 好了，內存中的字符串存放格式我們知道了，下面我們要了解print的工作方式。print其實只是負責把內存中相應的字節串交給操作系統，讓操作系統相應的程序（譬如cmd窗口）進行顯示。這里有兩種情況： 1、若字符串是一般的字符串，那么print只需把內存中相應的字節串推送給操作系統。如例子中的code 1。 2、如果字符串是Unicode字符串，那么print在推送之前先進行相應的encode：我們可以顯示使用Unicode的encode方法使用合適的編碼方式來編碼（例子中code 2），否則Python使用默認的編碼方式進行編碼，也就是ASCII（例子中的code 3）。當然ASCII是不可能正確編碼中文的，因此Python報錯。 至此，上面的三個問題我們已經可以解析第一和第三個了。至于第二個問題，因為Python中有兩種字符串，一般字符串和Unicode字符串，兩者都有各自的字符處理方法。對于前者，方法是以字節的方式進行的，而且在GB2312中，每個漢字占用兩個字節，因此得到的結果是5；對于后者，也就是Unicode字符串，所有字符都是統一看待的，因此得到3。 雖然上面只提到了控制臺程序的中文問題，但是文件讀寫以及網絡傳輸中出現的中文問題在原理上都是類似的。Unicode的出現可以很大程度上解決軟件的國際化問題，同時Python為Unicode提供了極為良好的支持，因此，我建議大家在編寫Python的程序時，都統一使用Unicode方式。保存文件時使用UTF-8的編碼方式。How to Use UTF-8 with Python有詳細的描述。
Powered by: C++博客 Copyright © Hero
