一篇文章徹底弄懂Python字元編碼

1. 字元編碼簡介

1.1. ASCII

ASCII(American Standard Code for Information Interchange)，是一種單位元組的編碼。計算機世界裡一開始只有英文，而單位元組可以表示256個不同的字元，可以表示所有的英文字元和許多的控制符號。不過ASCII只用到了其中的一半（x80以下），這也是MBCS得以實現的基礎。

1.2. MBCS

然而計算機世界裡很快就有了其他語言，單位元組的ASCII已無法滿足需求。後來每個語言就制定了一套自己的編碼，由於單位元組能表示的字元太少，而且同時也需要與ASCII編碼保持相容，所以這些編碼紛紛使用了多位元組來表示字元，如GBxxx、BIGxxx等等，他們的規則是，如果第一個位元組是x80以下，則仍然表示ASCII字元；而如果是x80以上，則跟下一個位元組一起（共兩個位元組）表示一個字元，然後跳過下一個位元組，繼續往下判斷。

這裡，IBM發明了一個叫Code Page的概念，將這些編碼都收入囊中並分配頁碼，GBK是第936頁，也就是CP936。所以，也可以使用CP936表示GBK。

MBCS(Multi-Byte Character Set)是這些編碼的統稱。目前為止大家都是用了雙位元組，所以有時候也叫做DBCS(Double-Byte Character Set)。必須明確的是，MBCS並不是某一種特定的編碼，Windows里根據你設定的區域不同，MBCS指代不同的編碼，而Linux裡無法使用MBCS作為編碼。在Windows中你看不到MBCS這幾個字元，因為微軟為了更加洋氣，使用了ANSI來嚇唬人，記事本的另存為對話方塊裡編碼ANSI就是MBCS。同時，在簡體中文Windows預設的區域設定裡，指代GBK。

1.3. Unicode

後來，有人開始覺得太多編碼導致世界變得過於複雜了，讓人腦袋疼，於是大家坐在一起拍腦袋想出來一個方法：所有語言的字元都用同一種字元集來表示，這就是Unicode。

最初的Unicode標準UCS-2使用兩個位元組表示一個字元，所以你常常可以聽到Unicode使用兩個位元組表示一個字元的說法。但過了不久有人覺得256*256太少了，還是不夠用，於是出現了UCS-4標準，它使用4個位元組表示一個字元，不過我們用的最多的仍然是UCS-2。

UCS(Unicode Character Set)還僅僅是字元對應碼位的一張表而已，比如"漢"這個字的碼位是6C49。字元具體如何傳輸和儲存則是由UTF(UCS Transformation Format)來負責。

一開始這事很簡單，直接使用UCS的碼位來儲存，這就是UTF-16，比如，"漢"直接使用x6Cx49儲存(UTF-16-BE)，或是倒過來使用x49x6C儲存(UTF-16-LE)。但用著用著美國人覺得自己吃了大虧，以前英文字母只需要一個位元組就能儲存了，現在大鍋飯一吃變成了兩個位元組，空間消耗大了一倍……於是UTF-8橫空出世。

UTF-8是一種很彆扭的編碼，具體表現在他是變長的，並且相容ASCII，ASCII字元使用1位元組表示。然而這裡省了的必定是從別的地方摳出來的，你肯定也聽說過UTF-8裡中文字元使用3個位元組來儲存吧？4個位元組儲存的字元更是在淚奔……（具體UCS-2是怎麼變成UTF-8的請自行搜尋）

另外值得一提的是BOM(Byte Order Mark)。我們在儲存檔案時，檔案使用的編碼並沒有儲存，開啟時則需要我們記住原先儲存時使用的編碼並使用這個編碼開啟，這樣一來就產生了許多麻煩。（你可能想說記事本開啟檔案時並沒有讓選編碼？不妨先開啟記事本再使用檔案 -> 開啟看看）而UTF則引入了BOM來表示自身編碼，如果一開始讀入的幾個位元組是其中之一，則代表接下來要讀取的文字使用的編碼是相應的編碼：

BOM_UTF8 'xefxbbxbf'
BOM_UTF16_LE 'xffxfe'
BOM_UTF16_BE 'xfexff'

並不是所有的編輯器都會寫入BOM，但即使沒有BOM，Unicode還是可以讀取的，只是像MBCS的編碼一樣，需要另行指定具體的編碼，否則解碼將會失敗。

你可能聽說過UTF-8不需要BOM，這種說法是不對的，只是絕大多數編輯器在沒有BOM時都是以UTF-8作為預設編碼讀取。即使是儲存時預設使用ANSI(MBCS)的記事本，在讀取檔案時也是先使用UTF-8測試編碼，如果可以成功解碼，則使用UTF-8解碼。記事本這個彆扭的做法造成了一個BUG：如果你新建文字檔案並輸入"奼塧"然後使用ANSI(MBCS)儲存，再開啟就會變成"漢a"，你不妨試試 ：）

2. Python2.x中的編碼問題

2.1. str和unicode

str和unicode都是basestring的子類。嚴格意義上說，str其實是位元組串，它是unicode經過編碼後的位元組組成的序列。對UTF-8編碼的str'漢'使用len()函數時，結果是3，因為實際上，UTF-8編碼的'漢' == 'xE6xB1x89'。

unicode才是真正意義上的字串，對位元組串str使用正確的字元編碼進行解碼後獲得，並且len(u'漢') == 1。

再來看看encode()和decode()兩個basestring的實體方法，理解了str和unicode的區別後，這兩個方法就不會再混淆了：

# coding: UTF-8
 
u = u'漢'
print repr(u) # u'u6c49'
s = u.encode('UTF-8')
print repr(s) # 'xe6xb1x89'
u2 = s.decode('UTF-8')
print repr(u2) # u'u6c49'
 
# 對unicode進行解碼是錯誤的
# s2 = u.decode('UTF-8')
# 同樣，對str進行編碼也是錯誤的
# u2 = s.encode('UTF-8')

需要注意的是，雖然對str呼叫encode()方法是錯誤的，但實際上Python不會丟擲異常，而是返回另外一個相同內容但不同id的str；對unicode呼叫decode()方法也是這樣。很不理解為什麼不把encode()和decode()分別放在unicode和str中而是都放在basestring中，但既然已經這樣了，我們就小心避免犯錯吧。

2.2. 字元編碼宣告

原始碼檔案中，如果有用到非ASCII字元，則需要在檔案頭部進行字元編碼的宣告，如下：

#-*- coding: UTF-8 -*-

實際上Python只檢查#、coding和編碼字串，其他的字元都是為了美觀加上的。另外，Python中可用的字元編碼有很多，並且還有許多別名，還不區分大小寫，比如UTF-8可以寫成u8。參見

另外需要注意的是宣告的編碼必須與檔案實際儲存時用的編碼一致，否則很大機率會出現程式碼解析異常。現在的IDE一般會自動處理這種情況，改變宣告後同時換成宣告的編碼儲存，但文字編輯器控們需要小心 ：）

2.3. 讀寫檔案

內建的open()方法開啟檔案時，read()讀取的是str，讀取後需要使用正確的編碼格式進行decode()。write()寫入時，如果引數是unicode，則需要使用你希望寫入的編碼進行encode()，如果是其他編碼格式的str，則需要先用該str的編碼進行decode()，轉成unicode後再使用寫入的編碼進行encode()。如果直接將unicode作為引數傳入write()方法，Python將先使用原始碼檔案宣告的字元編碼進行編碼然後寫入。

# coding: UTF-8
 
f = open('test.txt')
s = f.read()
f.close()
print type(s) # <type 'str'>
# 已知是GBK編碼，解碼成unicode
u = s.decode('GBK')
 
f = open('test.txt', 'w')
# 編碼成UTF-8編碼的str
s = u.encode('UTF-8')
f.write(s)
f.close()

另外，模組codecs提供了一個open()方法，可以指定一個編碼開啟檔案，使用這個方法開啟的檔案讀取返回的將是unicode。寫入時，如果引數是unicode，則使用open()時指定的編碼進行編碼後寫入；如果是str，則先根據原始碼檔案宣告的字元編碼，解碼成unicode後再進行前述操作。相對內建的open()來說，這個方法比較不容易在編碼上出現問題。

# coding: GBK
 
import codecs
 
f = codecs.open('test.txt', encoding='UTF-8')
u = f.read()
f.close()
print type(u) # <type 'unicode'>
 
f = codecs.open('test.txt', 'a', encoding='UTF-8')
# 寫入unicode
f.write(u)
 
# 寫入str，自動進行解碼編碼操作
# GBK編碼的str
s = '漢'
print repr(s) # 'xbaxba'
# 這裡會先將GBK編碼的str解碼為unicode再編碼為UTF-8寫入
f.write(s) 
f.close()

2.4. 與編碼相關的方法

sys/locale模組中提供了一些獲取當前環境下的預設編碼的方法。

import sys
import locale
 
def p(f):
    print '%s.%s(): %s' % (f.__module__, f.__name__, f())
 
# 返回當前系統所使用的預設字元編碼
p(sys.getdefaultencoding)
 
# 返回用於轉換Unicode檔名至系統檔名所使用的編碼
p(sys.getfilesystemencoding)
 
# 獲取預設的區域設定並返回元祖(語言, 編碼)
p(locale.getdefaultlocale)
 
# 返回使用者設定的文字資料編碼
# 檔案提到this function only returns a guess
p(locale.getpreferredencoding)
 
# xbaxba是'漢'的GBK編碼
# mbcs是不推薦使用的編碼，這裡僅作測試表明為什麼不應該用
print r"'xbaxba'.decode('mbcs'):", repr('xbaxba'.decode('mbcs'))
 
#在筆者的Windows上的結果(區域設定為中文(簡體, 中國))
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'xbaxba'.decode('mbcs'): u'u6c49'

3.建議

3.1.字元編碼宣告

使用字元編碼宣告，並且同一工程中的所有原始碼檔案使用相同的字元編碼宣告。

這點是一定要做到的。

3.2. 拋棄str，全部使用unicode。

按引號前先按一下u最初做起來確實很不習慣而且經常會忘記再跑回去補，但如果這麼做可以減少90%的編碼問題。如果編碼困擾不嚴重，可以不參考此條。

3.3. 使用codecs.open()替代內建的open()。

如果編碼困擾不嚴重，可以不參考此條。

3.4. 絕對需要避免使用的字元編碼：MBCS/DBCS和UTF-16。

這裡說的MBCS不是指GBK什麼的都不能用，而是不要使用Python里名為'MBCS'的編碼，除非程式完全不移植。

Python中編碼'MBCS'與'DBCS'是同義詞，指當前Windows環境中MBCS指代的編碼。Linux的Python實現中沒有這種編碼，所以一旦移植到Linux一定會出現異常！另外，只要設定的Windows系統區域不同，MBCS指代的編碼也是不一樣的。

分別設定不同的區域執行2.4小節中的程式碼的結果：

#中文(簡體, 中國)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'xbaxba'.decode('mbcs'): u'u6c49'
 
#英語(美國)
#sys.getdefaultencoding(): UTF-8
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'xbaxba'.decode('mbcs'): u'xbaxba'
 
#德語(德國)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'xbaxba'.decode('mbcs'): u'xbaxba'
 
#日語(日本)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp932')
#locale.getpreferredencoding(): cp932
#'xbaxba'.decode('mbcs'): u'uff7auff7a'

可見，更改區域後，使用mbcs解碼得到了不正確的結果，所以，當我們需要使用'GBK'時，應該直接寫'GBK'，不要寫成'MBCS'。

UTF-16同理，雖然絕大多數作業系統中'UTF-16'是'UTF-16-LE'的同義詞，但直接寫'UTF-16-LE'只是多寫3個字元而已，而萬一某個作業系統中'UTF-16'變成了'UTF-16-BE'的同義詞，就會有錯誤的結果。實際上，UTF-16用的相當少，但用到的時候還是需要注意。

到此這篇關於一篇文章徹底弄懂Python字元編碼的文章就介紹到這了,更多相關ython字元編碼內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！