在Python語言中，Uincode字符串處理一直是一個容易讓人迷惑的問題。許多Python愛好者經(jīng)常因為搞不清Unicode、UTF-8還有其它許許多多的編碼之間的區(qū)別而大傷腦筋。筆者曾經(jīng)也是這“傷腦筋一族”的成員，但經(jīng)過半年多的努力，現(xiàn)在終于初步弄清楚其中的一些關(guān)系?，F(xiàn)將其整理如下，與各位同仁同享。同時也希望能借這篇短文拋磚引玉，吸引更多真正的高手加入進(jìn)來，共同完善我們的Python中文環(huán)境。

本文所提到的各種觀點，一部分是查閱資料所得，還有一部分是筆者利用已有各種編碼數(shù)據(jù)用“猜測加驗證”法得到。筆者自問才疏學(xué)淺，其中怕是藏有不少錯誤。各位看官中不乏高手，如果有哪一位發(fā)現(xiàn)其中哪里有錯，萬望各位高人不吝賜教。筆者自己丟丑事小，觀點錯誤誤了別人事大，因此各位大可不必顧忌筆者的面子問題。

第一節(jié)　文字編碼和Unicode標(biāo)準(zhǔn)

要解釋Unicode字符串就必須先從什么是Unicode編碼開始說起。眾所周知，文本顯示一直是計算機顯示功能必須解決的基本問題。而計算機并不識字，它實際上是把文本看做是一串“圖片”，每張“圖片”對應(yīng)一個字符。每個計算機程序在顯示文本時，必須借助一個記錄這個文字“圖片”如何顯示的“圖片”集合，從中找到每一個字符對應(yīng)“圖片”的數(shù)據(jù)，并依樣畫葫蘆地把這個字“畫”到屏幕上。這個“圖片”就被稱為“字?！?，而記錄字模顯示數(shù)據(jù)的集合就被稱為“字符集”。為方便程序查找，每個字符的字模數(shù)據(jù)在字符集中必須是有序排列的，而且每個字符都會被分配一個獨一無二的ID，這個ID就是字符的編碼。而在計算機進(jìn)行字符數(shù)據(jù)處理時，總是用這個編碼代表它表示的那個字符。因此，一個字符集就規(guī)定了一組計算機能夠處理的字符數(shù)據(jù)。顯然，不同國家指定的字符集大小不同，相應(yīng)的字符編碼也不同。

在計算機歷史上，最為廣泛使用的標(biāo)準(zhǔn)化字符集當(dāng)首推ASCII字符集。它實際上是美國制訂的標(biāo)準(zhǔn)，針對北美用戶開發(fā)。它使用7個二進(jìn)制位編碼，可以表示128個字符。這個字符集最終被ISO組織正式采納為國際標(biāo)準(zhǔn)，并且大量應(yīng)用在各種計算機體系上?，F(xiàn)如今，所有PC機的BIOS中都內(nèi)含了ASCII字符集的字模，其深入人心可見一斑。

但是，當(dāng)計算機在各個國家大規(guī)模普及時，ASCII編碼的局限性就暴露出來了：它的字符空間實在有限，無法容納更多的字符，可是絕大多數(shù)語言需要使用的字符數(shù)目都遠(yuǎn)不止128個。為了能正確處理本國文字，各個國家官方或民間紛紛開始了設(shè)計本國文字編碼集的工作，并且最終涌現(xiàn)出許許多多針對各個國家文字的字符編碼，如針對西歐字符的ISO-8859-1編碼，針對簡體中文的GB系列編碼，還有針對日文的SHIFT-JIS編碼等等。同時，為了保證各個新的字符集能夠兼容原本的ASCII文本，大多數(shù)字符集不約而同地都將ASCII字符作為自己前128個字符，并使其編碼與ASCII編碼一一對應(yīng)。

這樣一來，各國文字的顯示問題是解決了，可是又帶來一個新的問題：亂碼。不同國家、地區(qū)使用的字符集通常沒有統(tǒng)一的規(guī)范進(jìn)行約束，因此各個字符集編碼往往互不兼容。同一個字在兩個不同的字符集中編碼一般不同；而同一個編碼在不同的字符集中對應(yīng)的字符也不一樣。一段用編碼A編寫的文本在一個只支持編碼B的系統(tǒng)上往往會被顯示成一堆亂七八糟的字符。更糟糕的是，不同字符集使用的編碼長度往往也不相同，那些只能處理單字節(jié)編碼的程序在遇到雙字節(jié)甚至是多字節(jié)編碼的文本時，往往因為不能正確處理而產(chǎn)生了臭名昭著的“半個字”問題。這使得本已經(jīng)混亂不堪的局面更是亂成了一團粥。

為了一勞永逸地解決這些問題，業(yè)界許多大公司和組織聯(lián)合提出了一個標(biāo)準(zhǔn)，這就是Unicode。Unicode實際上是一種新的字符編碼體系。它對字符集中的每個字符用兩個字節(jié)長的ID號進(jìn)行編碼，從而規(guī)定出一個可容納多達(dá)65536個字符的編碼空間，并且將現(xiàn)今國際上各國編碼中的常用字盡數(shù)收入罄中。由于在設(shè)計編碼時有了周全的考慮，Unicode很好地解決了其它字符集在進(jìn)行數(shù)據(jù)交流時的亂碼和“半個字”問題。同時，Unicode的設(shè)計者充分考慮到現(xiàn)今大量字模數(shù)據(jù)使用的仍是各國制訂的各種編碼這一現(xiàn)實，提出了“將Unicode作為內(nèi)部編碼”的設(shè)計理念。也就是說，字符顯示程序依然使用原先的編碼和代碼，而應(yīng)用程序的內(nèi)部邏輯使用的將是Unicode。當(dāng)要進(jìn)行文字顯示時，程序總是將Unicode編碼的字符串轉(zhuǎn)換成原本的編碼進(jìn)行顯示。這樣，大家就不必為了使用Unicode而重新設(shè)計字模數(shù)據(jù)體系了。同時，為了與各國已經(jīng)制訂的編碼相區(qū)別，Unicode的設(shè)計者將Unicode稱為“寬字符編碼”（wide characters encodings），而各國制訂的編碼習(xí)慣上被稱為“多字節(jié)編碼”（multi bypes encodings）。時至今日，Unicode體系又引入了四字節(jié)的擴展編碼，并且逐漸與與UCS-4，也就是ISO10646編碼規(guī)范合流，希望有朝一日能夠用ISO10646體系統(tǒng)一全世界所有的文字編碼。

Unicode體系甫一出世便被大家寄予厚望，并被迅速接受為ISO認(rèn)可的國際標(biāo)準(zhǔn)。但是，Unicode在推廣過程中卻遭到了首先是歐美用戶的反對。他們反對的理由非常簡單：歐美用戶原本使用的編碼都是單字節(jié)長的，雙字節(jié)的Unicode處理引擎無法處理原本的單字節(jié)數(shù)據(jù)；而如果要把現(xiàn)有的單字節(jié)文本全部轉(zhuǎn)換成Unicode，工作量就太大了。再說，如果所有的單字節(jié)編碼文本都被轉(zhuǎn)換成雙字節(jié)的Unicode編碼，他們所有的文本數(shù)據(jù)占用的空間都會變成原來的兩倍，而且所有的處理程序都要被重新編寫。這個開銷他們無法接受。

雖然Unicode是國際認(rèn)可的標(biāo)準(zhǔn)，但是標(biāo)準(zhǔn)化組織不可能不考慮歐美用戶這個最大的計算機使用群體的要求。于是在各方磋商之下，一個Unicode的變種版本產(chǎn)生了，這就是UTF-8。UTF-8是一個多字節(jié)的編碼體系，它的編碼規(guī)則如下：

1、UTF-8編碼分為四個區(qū)：

一區(qū)為單字節(jié)編碼，

編碼格式為：0xxxxxxx；
對應(yīng)Unicode：0x0000 - 0x007f

二區(qū)為雙字節(jié)編碼，

編碼格式為：110xxxxx 10xxxxxx；

對應(yīng)Unicode：0x0080 - 0x07ff

三區(qū)為三字節(jié)編碼，

編碼格式為：1110xxxx 10xxxxxxx 10xxxxxx

對應(yīng)Unicode：0x0800 - 0xffff

四區(qū)為四字節(jié)編碼，

編碼格式為：11110xxx 10xxxxxxx 10xxxxxx 10xxxxxx

對應(yīng)Unicode：0x00010000 - 0x0001ffff

五區(qū)為五字節(jié)編碼，

編碼格式為：111110xx 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx

對應(yīng)Unicode：0x00200000 - 0x03ffffff

六區(qū)為六字節(jié)編碼，

編碼格式為：111110x 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx 10xxxxxxx

對應(yīng)Unicode：0x04000000 - 0x7fffffff

其中，一、二、三區(qū)對應(yīng)Unicode的雙字節(jié)編碼區(qū)，而四區(qū)則針對Unicode的四字節(jié)擴展部分（按照該定義，UTF-8還有五區(qū)和六區(qū)，但筆者并未在GNU glibc庫中發(fā)現(xiàn)，不知為何）；

2、各個區(qū)按照一、二、三、四、五、六順序排列，其對應(yīng)位置上的字符與Unicode保持相同；

3、不可顯示的Unicode字符編碼為0字節(jié)，換言之，它們沒有被收入UTF-8（這是筆者從GNU C庫注釋中得到的說法，可能與實際情況不符）；

按照UTF-8編碼規(guī)則我們不難發(fā)現(xiàn)，其一區(qū)的128個編碼實際上就是ASCII編碼。所以UTF-8的處理引擎可以直接處理ASCII文本。但是，UTF-8對ASCII編碼的兼容是以犧牲其它編碼為代價的。比如，原本中、日、韓三國文字基本上都是雙字節(jié)編碼，但它們在Unicode編碼中的位置對應(yīng)到UTF-8中的三區(qū)，每一個字符編碼要三個字節(jié)長。換句話說，如果我們把所有現(xiàn)有的中、日、韓三國編碼的非ASCII字符文本數(shù)據(jù)轉(zhuǎn)換成UTF-8編碼，則其大小都會變成原來的1.5倍。

雖然筆者個人認(rèn)為UTF-8的編碼方式顯得有些不夠公平，但它畢竟解決了ASCII文本到Unicode世界的過渡問題，所以還是贏得了廣泛的認(rèn)可。典型的例子是XML和Java：XML文本的默認(rèn)編碼就是UTF-8，而Java源代碼實際上就可以用UTF-8字符編寫（JBuilder的用戶應(yīng)該有印象）。另外還有開源軟件世界中大名鼎鼎的GTK 2.0，它使用UTF-8字符作為內(nèi)部編碼。

說了這么多，似乎話題有些扯遠(yuǎn)了，許多Python愛好者可能已經(jīng)開始著急：“這和Python有什么關(guān)系呢？”好的，現(xiàn)在我們就把視線轉(zhuǎn)到Python的世界來。

第二節(jié)　Python的Unicode編碼系統(tǒng)

為了正確處理多語言文本，Python在2.0版后引入了Unicode字符串。從那時起，Python語言中的字符串就分為兩種：一種是2.0版之前就已經(jīng)使用很久的傳統(tǒng)Python字符串，一種則是新的Unicode字符串。在Python語言中，我們使用unicode()內(nèi)建函數(shù)對一個傳統(tǒng)Python字符串進(jìn)行“解碼”，得到一個Unicode字符串，然后又通過Unicode字符串的encode()方法對這個Unicode字符串進(jìn)行“編碼”，將其“編碼”成為傳統(tǒng)Python字符串以上內(nèi)容想必每一個Python用戶都是爛熟于胸了。但是你可知道，Python的Unicode字符串并不是真正意義上的“Unicode編碼的字符串”，而是遵循一種自己特有的規(guī)則。這個規(guī)則的內(nèi)容簡單得很：

1、ASCII字符的Python Unicode編碼與它們的ASCII編碼相同。也就是說，Python的Unicode字符串中ASCII文本仍然是單字節(jié)長度編碼；

2、ASCII字符以外的字符，其編碼就是Unicode標(biāo)準(zhǔn)編碼的雙字節(jié)（或四字節(jié)）編碼。（筆者猜想，之所以Python社群要制訂如此古怪的標(biāo)準(zhǔn)，可能是想保證ASCII字符串的通用性吧）

通常在Python應(yīng)用中，Unicode字符串都是作為內(nèi)部處理時使用，而終端顯示工作則由傳統(tǒng)的Python字符串完成（實際上，Python的print語句根本無法打印出雙字節(jié)的Unicode編碼字符）。在Python語言中，傳統(tǒng)Python字符串就是所謂的“多字節(jié)編碼”字符串，用于表示各種被“編碼”成為具體字符集編碼的字符串（比如GB、BIG5、KOI8-R、JIS、ISO-8859-1，當(dāng)然也有UTF-8）；而Python Unicode字符串則是“寬字符編碼”字符串，表示從具體字符集編碼中“解碼”出來的Unicode數(shù)據(jù)。所以通常情況下，一個需要用到Unicode編碼的Python應(yīng)用往往會以如下方式處理字符串?dāng)?shù)據(jù)：

def foo(string, encoding = "gb2312"):
# 1. convert multi-byte string to wide character string
u_string = unicode(string, encoding)

# 2. do something
...

# 3. convert wide character string to printable multi-byte string
return u_string.encode(encoding)

我們可以舉出一個例子：經(jīng)常在Red Hat Linux環(huán)境中使用PyGTK2進(jìn)行XWindow編程的Python同道可能早就發(fā)現(xiàn)過這樣的情況：如果我們直接寫出如下語句：

import pygtk
pygtk.require('2.0')
import gtk

main = gtk.Window() # create a window
main.set_title("你好") # NOTICE!

這樣的語句在執(zhí)行時會在終端上出現(xiàn)這樣的警告：

Error converting from UTF-8 to 'GB18030': 轉(zhuǎn)換輸入中出現(xiàn)無效字符序列

并且程序窗口標(biāo)題不會被置為“你好”；但如果用戶安裝了中文的codec，并將上文的最后一句改為：

u_string = unicode('你好','gb2312')
main.set_title(u_string)

則程序窗口標(biāo)題將會被正確地設(shè)置為“你好”。這是為什么呢？

原因很簡單。gtk.Window.set_title()方法總是將自己接收的標(biāo)題字符串看做是一個Unicode字符串。PyGTK系統(tǒng)在接收到用戶的main.set_title()這一請求時，將得到的字符串在某處做了如下處理：

class Window(gtk.Widget):
...
def set_title(self, title_unicode_string):
...
# NOTICE! unicode -> multi-byte utf-8
real_title_string = title_unicode_string.encode('utf-8')
...
# pass read_title_string to GTK2 C API to draw the title
...

我們看到，字符串title_unicode_string在程序內(nèi)部被“編碼”成了一個新的字符串：real_title_string。顯然，這個real_title_string是一個傳統(tǒng)Python字符串，而它的編碼用的是UTF-8。在上一節(jié)中筆者曾經(jīng)提到過，GTK2的內(nèi)部使用的字符串都是按UTF-8編碼的，所以，GTK2核心系統(tǒng)在接收到real_title_string后可以正確顯示出標(biāo)題來。

那么，如果用戶輸入的標(biāo)題是ASCII字符串（比如：“hello world”），又當(dāng)如何？我們回想一下Python Unicode字符串的定義規(guī)則就不難發(fā)現(xiàn)，如果用戶的輸入是ASCII字符串，則對其進(jìn)行重編碼得到的就是其自身。也就是說，如果title_unicode_string的值是ASCII字符串，則real_title_string與title_unicode_string的值將完全一致。而一個ASCII字符串也就是一個UTF-8字符串，把它傳遞給GTK2系統(tǒng)不會有任何問題。

以上我們舉的例子是關(guān)于Linux下的PyGTK2的，但類似的問題不僅出現(xiàn)在PyGTK中。除了PyGTK之外，現(xiàn)今各種Python綁定的圖形包，如PyQT、Tkinter等，多多少少都會遇到與Unicode處理有關(guān)的問題。

現(xiàn)在我們弄清了Python的Unicode字符串編碼機制，但是我們最想知道的問題還是沒有解決：我們?nèi)绾尾拍茏孭ython支持用Unicode處理中文呢？這個問題我們將在下一節(jié)說明。

第三節(jié)　如何讓Python的Unicode字符串支持中文

看完這一節(jié)的標(biāo)題，有一些Python同道們可能會有些不以為然：“為什么一定要用Unicode處理中文呢？我們平時用傳統(tǒng)Python字符串處理得不是也不錯嗎？”的確，其實在一般情況下像字符串連接、子串匹配等操作用傳統(tǒng)Python字符串也就足夠了。但是，如果涉及到一些高級的字符串操作，比如包含多國文字的正則表達(dá)式匹配、文本編輯、表達(dá)式分析等等，這些大量混雜了單字節(jié)和多字節(jié)文本的操作如果用傳統(tǒng)字符串處理就非常麻煩了。再說，傳統(tǒng)字符串始終無法解決那該死的“半個字”問題。而如果我們可以使用Unicode，則這些問題都可以迎刃而解。所以，我們必須正視并設(shè)法解決中文Unicode的處理問題。

由上一節(jié)的介紹我們知道，如果要想利用Python的Unicode機制處理字符串，只要能夠擁有一個能夠把多字節(jié)的中文編碼（包括GB編碼系列和BIG5系列）和Unicode編碼進(jìn)行雙向轉(zhuǎn)換的編碼／解碼模塊就可以了。按照Python的術(shù)語，這樣的編碼／解碼模塊被稱為codec。于是接下來的問題就變成了：我們該如何編寫這樣一個codec？

如果Python的Unicode機制是硬編碼在Python核心中的話，那么給Python添加一個新的codec就將是一項艱苦卓絕的工作了。幸虧Python的設(shè)計者們沒有那么傻，他們提供了一個擴充性極佳的機制，可以非常方便地為Python添加新的codecs。

Python的Unicode處理模塊有三個最重要的組成部分：一是codecs.py文件，二是encodings目錄，三是aliases.py文件。前兩者都位于Python系統(tǒng)庫的安裝目錄之中（如果是Win32發(fā)行版，就在$PYTHON_HOME/lib/目錄下；如果是Red Hat Linux，就在/usr/lib/python-version/目錄下，其它系統(tǒng)可以照此尋找），而最后一個則位于encodings目錄下。接下來，我們分別對這三者加以說明。

先來看看codecs.py文件。這個文件定義了一個標(biāo)準(zhǔn)的Codec模塊應(yīng)有的接口。其具體內(nèi)容大家可以在自己的Python發(fā)行版中找到，在此不再贅述。按照codecs.py文件的定義，一個完整的codec應(yīng)該至少擁有三個類和一個標(biāo)準(zhǔn)函數(shù)：

1、Codec類

用途：

用于將用戶傳入的緩沖區(qū)數(shù)據(jù)（一個buffer）作為一個傳統(tǒng)Python字符串，并將

其“解碼”為對應(yīng)的Unicode字符串。一個完整的Codec類定義必須提供Codec.decode()和

Codec.encode()兩個方法：

Codec.decode(input, errors = "strict")

用于將輸入的數(shù)據(jù)看做是傳統(tǒng)Python字符串，并將其“解碼”，轉(zhuǎn)換成對應(yīng)的Unicode字符串。

參數(shù)：

input：輸入的buffer（可以是字符串，也可以是任何可以轉(zhuǎn)換成字符串表示的對象）

errors：發(fā)生轉(zhuǎn)換錯誤時的處理選擇?？蛇x擇如下三種取值：

strict（默認(rèn)值）：如果發(fā)生錯誤，則拋出UnicodeError異常；

replace：如果發(fā)生錯誤，則選取一個默認(rèn)的Unicode編碼代替之；

ignore：如果發(fā)生錯誤，則忽略這個字符，并繼續(xù)分析余下的字符。

返回值：

一個常數(shù)列表（tuple）：首元素為轉(zhuǎn)換后的Unicode字符串，尾元素為輸入數(shù)據(jù)的長度。

Codec.encode(input, errors = "strict")

用于將輸入的數(shù)據(jù)看做是Unicode字符串，并將其“編碼”，轉(zhuǎn)換成對應(yīng)的傳統(tǒng)Python字符串。

參數(shù)：

input：輸入的buffer（通常就是Unicode字符串）

errors：發(fā)生轉(zhuǎn)換錯誤時的處理選擇。取值規(guī)則與Codec.decode()方法相同。

返回值：

一個常數(shù)列表（tuple）：首元素為轉(zhuǎn)換后的傳統(tǒng)Python字符串，尾元素為輸入數(shù)據(jù)的長度。

2、StreamReader類（通常應(yīng)該繼承自Codec類）

用于分析文件輸入流。提供所有對文件對象的讀取操作，如readline()方法等。

3、StreamWriter類（通常應(yīng)該繼承自Codec類）

用于分析文件輸出流。提供所有對文件對象的寫入操作，如writeline()方法等。

5、getregentry()函數(shù)

即“GET REGistry ENTRY”之意，用于獲取各個Codec文件中定義的四個關(guān)鍵函數(shù)。其函數(shù)體統(tǒng)一為：

def getregentry():
return tuple(Codec().encode,Codec().decode,StreamReader,StreamWriter)

在以上提到的所有四個類中，實際上只有Codec類和getregentry()函數(shù)是必須提供的。必須提供前者是因為它是實際提供轉(zhuǎn)換操作的模塊；而后者則是Python系統(tǒng)獲得Codec定義的標(biāo)準(zhǔn)接口，所以必須存在。至于StreamReader和StreamWriter，理論上應(yīng)該可以通過繼承codecs.py中的StreamReader和StreamWriter類，并使用它們的默認(rèn)實現(xiàn)。當(dāng)然，也有許多codec中將這兩個類進(jìn)行了改寫，以實現(xiàn)一些特殊的定制功能。

接下來我們再說說encodings目錄。顧名思義，encodings目錄就是Python系統(tǒng)默認(rèn)的存放所有已經(jīng)安裝的codec的地方。我們可以在這里找到所有Python發(fā)行版自帶的codecs。習(xí)慣上，每一個新的codec都會將自己安裝在這里。需要注意的是，Python系統(tǒng)其實并不要求所有的codec都必須安裝于此。用戶可以將新的codec放在任何自己喜歡的位置，只要Python系統(tǒng)的搜索路徑可以找得到就行。

僅僅將自己寫的codec安裝在Python能夠找到的路徑中還不夠。要想讓Python系統(tǒng)能找到對應(yīng)的codec，還必須在Python中對其進(jìn)行注冊。要想注冊一個新的codec，就必須用到encodings目錄下的aliases.py文件。這個文件中只定義了一個哈希表aliases，它的每個鍵對應(yīng)著每一個codec在使用時的名稱，也就是unicode()內(nèi)建函數(shù)的第二個參數(shù)值；而每個鍵對應(yīng)的值則是一個字符串，它是這個codec對應(yīng)的那個處理文件的模塊名。比如，Python默認(rèn)的解析UTF-8的codec是utf_8.py，它存放在encodings子目錄下，則aliases哈希表中就有一項表示其對應(yīng)關(guān)系：

'utf-8' : 'utf_8', # the module `utf_8' is the codec for UTF-8

同理，如果我們新寫了一個解析‘mycharset'字符集的codec，假設(shè)其編碼文件為mycodec.py，存放在$PYTHON_HOME/lib/site-packages/mycharset/目錄下，則我們就必須在aliases哈希表中加入這么一行：

'mycharset' : 'mycharset.mycodec',

這里不必寫出mycodec.py的全路徑名，因為site-packages目錄通常都在Python系統(tǒng)的搜索路徑之中。

Python解釋器在需要分析Unicode字符串時，會自動加載encodings目錄下的這個aliases.py文件。如果mycharset已經(jīng)在系統(tǒng)中注冊過，則我們就可以像使用其它內(nèi)建的編碼那樣使用我們自己定義的codec了。比如，如果按照上面的方式注冊了mycodec.py，則我們就可以這樣寫：

my_unicode_string = unicode(a_multi_byte_string, 'mycharset')

print my_unicode_string.encode('mycharset')

現(xiàn)在我們可以總結(jié)一下要編寫一個新的codec一共需要那些步驟：

首先，我們需要編寫一個自己的codec編碼／解碼模塊；

其次，我們要把這個模塊文件放在一個Python解釋器可以找到的地方；

最后，我們要在encodings/aliases.py文件中對其進(jìn)行注冊。

從理論上說，有了這三步，我們就可以將自己的codec安裝到系統(tǒng)中去了。不過這樣還不算完，還有一個小問題。有時候，我們出于種種原因，不希望隨便修改自己的系統(tǒng)文件（比如，一個用戶工作在一個集中式的系統(tǒng)中，系統(tǒng)管理員不允許別人對系統(tǒng)文件進(jìn)行修改）。在以上介紹的步驟中，我們需要修改aliases.py文件的內(nèi)容，這是一個系統(tǒng)文件。可如果我們不能修改它，難道我們就不能添加新的codec嗎？不，我們當(dāng)然有辦法。

這個辦法就是：在運行時修改encodings.aliases.aliases哈希表的內(nèi)容。

還是使用上面那個假設(shè)，如果用戶工作系統(tǒng)的管理員不允許用戶把mycodec.py的注冊信息寫入aliases.py，那么我們就可以如此處理：

1、將mycodec.py放在一個目錄下，比如/home/myname/mycharset/目錄；

2、這樣編寫/home/myname/mycharset/__init__.py文件：

import encodings.aliases
# update aliases hash map
encodings.aliases.aliases.update({/
'mycodec' : 'mycharset.mycodec',/
}}

以后每次要使用Python時，我們可以將/home/myname/加入搜索路徑，并且在使用自己的codec時預(yù)先執(zhí)行：

import mycharset # execute the script in mycharset/__init__.py

這樣我們就可以在不改動原有系統(tǒng)文件的情況下使用新的codecs了。另外，如果借助Python的site機制，我們還可以讓這個import工作自動化。如果大家不知道什么是site，就請在自己的Python交互環(huán)境中運行：

import site
print site.__doc__

瀏覽一下site模塊的文檔，即可明白個中技巧。如果大家手頭有Red Hat Linux v8，v9，還可以參考一下Red Hat的Python發(fā)行版中附帶的日文codec，看看它是如何實現(xiàn)自動加載的。也許不少同道可能找不到這個日文的codec在哪里，這里列出如下：

　　Red Hat Linux v8：在/usr/lib/python2.2/site-package/japanese/目錄下；
　　Red Hat Linux v9：在/usr/lib/python2.2/lib-dynload/japanese/目錄下；

提示：請Red Hat用戶注意site-packages目錄下的japanese.pth文件，結(jié)合site模塊的文檔，相信馬上就能豁然開朗。

結(jié)束語

記得當(dāng)初筆者在Dohao論壇上夸下?？冢骸叭绻梢缘脑?，我可以為大家編寫一個（中文模塊）”，現(xiàn)在回想起來，不禁為自己當(dāng)初的不知天高地厚而汗顏。一個把自己所有的的時間都花在學(xué)習(xí)上，一個學(xué)期只學(xué)七門課程，還落得個兩門課不及格的傻瓜研究生，哪里有什么資格在大家面前如此囂張?，F(xiàn)如今，第二個學(xué)期由于這兩門課的緣故負(fù)擔(dān)陡增（十門課呀?。?，家中老父老母還眼巴巴地等著自己的兒子能給他們掙臉。要想在有限的時間之內(nèi)，既保證學(xué)習(xí)，又保證工作（我要承擔(dān)導(dǎo)師的課程輔導(dǎo)工作，同時還有一個學(xué)校的教學(xué)改革方案需要我在其中挑大梁），已經(jīng)是疲于應(yīng)付，再加上一個中文模塊……唉，請恕筆者分身乏術(shù)，不得不食言。

因此，筆者斗膽，在此和盤托出自己這半年以來的心得，只希望能夠找到一批，不，哪怕是一個也好，只要是對這個項目感興趣的同道中人，能夠接下筆者已經(jīng)整理出來的知識，把一個完整的（至少應(yīng)該包含GB、BIG5、筆者個人認(rèn)為甚至還應(yīng)包括HZ碼）中文模塊編寫出來，貢獻(xiàn)給大家（不論是有償?shù)倪€是無償?shù)模?，那就是我們廣大Python愛好者之福了。另外，Python的發(fā)行版至今尚未包括任何中文支持模塊。既然我等平日深愛Python，如果我們的工作能因此為Python的發(fā)展做出一點貢獻(xiàn)，何樂而不為呢？

附錄　幾個小小提示

1、LUO Jian兄已經(jīng)編寫了一個非常不錯的中文模塊（Dohao上有鏈接，文件名是showfile.zip，這個模塊比我已經(jīng)寫完的草稿版本要快得多），同時支持GB2312和GB18030編碼，可惜不支持BIG5。如果大家有興趣，可以下載這個模塊研究一下；

2、和其它字符集編碼相比，中文模塊有其特殊性，那就是其海量的字符數(shù)目。一些相對較小的字符集還好說，比如GB2312，可以利用哈希表查找。而對于巨大的GB18030編碼，如果簡單地將所有數(shù)據(jù)制成一個特大的編碼對照表，則查詢速度會慢得讓人無法容忍（筆者在編寫模塊時最頭疼的就是這一點）。如果要編寫一個速度上能讓人滿意的codec，就必須考慮設(shè)計某種公式，能夠通過簡單地運算從一種編碼推算出另一種來，或者至少能推算出它的大概范圍。這就要求程序員要能對整個編碼方案做統(tǒng)計，設(shè)法找到規(guī)律。筆者認(rèn)為，這應(yīng)該是編寫中文模塊時的最大難點?；蛟S是數(shù)學(xué)功底實在太差的緣故，筆者費盡心機也未能找出一個規(guī)律來。希望能有數(shù)學(xué)高手不吝賜教；

3、中文編碼分為兩大派系：GB和BIG5。其中GB又分為GB2312、GBK和、GB18030三種編碼，而BIG5也分為BIG5和BIG5-HKSCS兩種（分別對應(yīng)原始的BIG5和香港擴展版本）。雖然同一派系的編碼可以向下兼容，但考慮到其字符數(shù)目龐大，為了加快查找速度，筆者個人認(rèn)為還是將它們分開編碼比較合理。當(dāng)然，如果能夠找到對應(yīng)字符集的轉(zhuǎn)換公式，則這種分離就沒有必要了；

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，同時也希望多多支持腳本之家！