我曾經(jīng)在深入淺出java中文問題系列中研究過java的中文問題，現(xiàn)在中文問題已經(jīng)不再羈絆我在java世界中漫游的腳步了。最近，對Python產(chǎn)生了濃厚的興趣，誰知道跟中文問題這個老朋友又一次不期而遇?？磥?，在代碼世界中，中文問題會在很長一段時間里跟我們形影不離。這也難怪，誰讓當(dāng)初發(fā)明計算機(jī)的不是我們中國人呢，否則，現(xiàn)在全世界的計算機(jī)都支持而且必須支持GBK，這樣，寫這樣文章的人就不會是我了，而是大洋彼岸的一個金發(fā)碧眼的程序員，而且標(biāo)題也相應(yīng)改為 “studying the english problem in ‘大蟒‘ ”。。哈哈
YY而已，還是面對現(xiàn)實(shí)問題吧。相對java而言，中文問題在Python中的表現(xiàn)更為激烈。“激烈”的意思不是說更為嚴(yán)重或者說難于解決，只是Python對于decode＆encode錯誤的默認(rèn)處理方式為strict，也就是直接報錯，而java使用replace的方式來處理了，因此java出現(xiàn)中文問題后會打印出很多"??"。此外，Python的默認(rèn)的encoding是ASCII，而java的默認(rèn)encoding跟操作系統(tǒng)的encoding是一致的。在這一點(diǎn)上，我覺得java更為合理，這樣對程序員更為友好，也減少了newbies 開始時的挫折感，是有利于語言的推廣的。但是，Python也有它的道理，畢竟ASCII是唯一的全世界所有平臺都支持的字符集，而且問題始終是問題，始終會出現(xiàn)的，逃避它還不如早點(diǎn)面對它。
好了，說了這么多，該說說Python中中文問題的癥狀了。在這之前，我們先要了解Python中有兩種字符串，分別是一般的字符串（每個字符用8 bits表示）和Unicode字符串（每個字符用一個或者多個字節(jié)表示），它們可以相互轉(zhuǎn)換。關(guān)于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 有著更為全面的描述，在此我就不再多說什么了。來看下面的代碼：
x = u"中文你好"
print s
運(yùn)行上述代碼，Python會給出下面的錯誤提示
說是遇到非ASCII字符了，并讓我們參考pep-0263。PEP-0263（Python Enhancement Proposal）上面說得很清楚了，Python也意識到了國際化問題，并提出了解決方案。根據(jù)提案上面的要求，我們有如下代碼
# -*- coding:gb2312 -*- ＃必須在第一行或者第二行
print "-------------code 1----------------"
a = "中文a我愛你"
print a
print a.find("我")
b = a.replace("愛", "喜歡")
print b
print "--------------code 2----------------"
x = "中文a我愛你"
y = unicode(x, "gb2312")
print y.encode("gb2312")
print y.find(u"我")
z = y.replace(u"愛", u"喜歡")
print z.encode("gb2312")
print "---------------code 3----------------"
print y
程序運(yùn)行的結(jié)果如下：
-------------code 1----------------
中文a我愛你
5
中文a我喜歡你
--------------code 2----------------
中文a我愛你
3
中文a我喜歡你
---------------code 3----------------
Traceback (most recent call last):
File "G:\Downloads\eclipse\workspace\p\src\hello.py", line 16, in <module>
print y
UnicodeEncodeError: ‘a(chǎn)scii‘ codec can‘t encode characters in position 0-1: ordinal not in range(128)
我們可以看到，通過引入編碼聲明，我們可以正常地在使用中文了，而且在code 1和2中，控制臺也能正確的把中文打印出來。但是，很明顯，上面的代碼也反映出了不少的問題：
1、code 1 和 2在使用print時采用了不同的方式，1是直接print，而2在print之前先進(jìn)行編碼
2、code 1 和 2中在同樣的字符串查找同一個字符“我”，得出的結(jié)果不一樣（分別是5和3）
3、code 3 中直接打印unicode字符串 y時出現(xiàn)錯誤（這也是為什么code 2中要先進(jìn)行編碼的原因）
為什么？為什么？我們可以先在腦海中模擬一下我們使用Python的流程：首先，我們先用編輯器編寫好源代碼，保存成文件。如果源代碼中有編碼聲明而且用的編輯器支持該語法，那么該文件就以相應(yīng)的編碼方式保存在磁盤中。注意：編碼聲明和源文件的編碼不一定是一致的，你完全可以在編碼聲明中聲明編碼為UTF-8，但是用GB2312來保存源文件。當(dāng)然，我們不可能自尋煩惱，故意寫錯，而且好的IDE也能強(qiáng)制保證兩者的一致性，但是，如果我們用記事本或者EditPlus等編輯器來編寫代碼的話，一不小心就會出現(xiàn)這種問題的。
得到一個.py文件后，我們就可以運(yùn)行它了，這是，我們就把代碼交給Python解析器來完成解析工作。解析器讀入文件時，先解析文件中的編碼聲明，我們假設(shè)文件的編碼為gb2312，那么先將文件中的內(nèi)容由gb2312轉(zhuǎn)換成Unicode，然后再把這些Unicode轉(zhuǎn)換為UTF-8格式的字節(jié)串。完成這一步驟后，解析器把這些UTF-8字節(jié)串分段，解析。如果遇到使用Unicode字符串，那么就使用相應(yīng)的UTF-8字節(jié)串創(chuàng)建Unicode字符串，如果程序中使用的是一般的字符串，那么解析器先將UTF-8字節(jié)串通過Unicode轉(zhuǎn)換成相應(yīng)編碼（這里就是gb2312編碼）的字節(jié)串，并用其創(chuàng)建一般的字符串對象。也就是說，Unicode字符串跟一般字符串在內(nèi)存中的存放格式是不一樣的，前者使用UTF-8的格式，后者使用GB2312格式。
好了，內(nèi)存中的字符串存放格式我們知道了，下面我們要了解print的工作方式。print其實(shí)只是負(fù)責(zé)把內(nèi)存中相應(yīng)的字節(jié)串交給操作系統(tǒng)，讓操作系統(tǒng)相應(yīng)的程序（譬如cmd窗口）進(jìn)行顯示。這里有兩種情況：
1、若字符串是一般的字符串，那么print只需把內(nèi)存中相應(yīng)的字節(jié)串推送給操作系統(tǒng)。如例子中的code 1。
2、如果字符串是Unicode字符串，那么print在推送之前先進(jìn)行相應(yīng)的encode：我們可以顯示使用Unicode的encode方法使用合適的編碼方式來編碼（例子中code 2），否則Python使用默認(rèn)的編碼方式進(jìn)行編碼，也就是ASCII（例子中的code 3）。當(dāng)然ASCII是不可能正確編碼中文的，因此Python報錯。
至此，上面的三個問題我們已經(jīng)可以解析第一和第三個了。至于第二個問題，因?yàn)镻ython中有兩種字符串，一般字符串和Unicode字符串，兩者都有各自的字符處理方法。對于前者，方法是以字節(jié)的方式進(jìn)行的，而且在GB2312中，每個漢字占用兩個字節(jié)，因此得到的結(jié)果是5；對于后者，也就是Unicode字符串，所有字符都是統(tǒng)一看待的，因此得到3。
雖然上面只提到了控制臺程序的中文問題，但是文件讀寫以及網(wǎng)絡(luò)傳輸中出現(xiàn)的中文問題在原理上都是類似的。Unicode的出現(xiàn)可以很大程度上解決軟件的國際化問題，同時Python為Unicode提供了極為良好的支持，因此，我建議大家在編寫Python的程序時，都統(tǒng)一使用Unicode方式。保存文件時使用UTF-8的編碼方式。How to Use UTF-8 with Python有詳細(xì)的描述，大家可以參考一下。
Python中能導(dǎo)致出現(xiàn)中文問題的地方還很多，譬如文件的讀寫，網(wǎng)絡(luò)數(shù)據(jù)的傳輸?shù)?，希望大家能多多交流，共同解決這些問題。
