徹底搞懂 python 中文亂碼問題

前言

曾幾何時 Python 中文亂碼的問題困擾了我很多很多年，每次出現中文亂碼都要去網上搜尋答案，雖然解決了當時遇到的問題但下次出現亂碼的時候又會懵逼，究其原因還是知其然不知其所以然。現在有的小夥伴為了躲避中文亂碼的問題甚至程式碼中不使用中文，註釋和提示都用英文，我曾經也這樣幹過，但這並不是解決問題，而是逃避問題，今天我們一起徹底解決 Python 中文亂碼的問題。

基礎知識

ASCII

很久很久以前，有一群人，他們決定用8個可以開合的電晶體來組合成不同的狀態，以表示世界上的萬物。他們看到8個開關狀態是好的，於是他們把這稱為”位元組“。再後來，他們又做了一些可以處理這些位元組的機器，機器開動了，可以用位元組來組合出很多狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱為”計算機“。開始計算機只在美國用。八位的位元組一共可以組合出256(2的8次方)種不同的狀態。 他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、印表機遇上約定好的這些位元組被傳過來時，就要做一些約定的動作。遇上0×10, 終端就換行，遇上0×07, 終端就向人們嘟嘟叫，例好遇上0x1b, 印表機就列印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，於是就把這些0×20以下的位元組狀態稱為”控制碼”。他們又把所有的空 格、標點符號、數字、大小寫字母分別用連續的位元組狀態表示，一直編到了第127號，這樣計算機就可以用不同位元組來儲存英語的文字了。大家看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的”Ascii”編碼（American Standard Code for Information Interchange，美國資訊互換標準程式碼）。當時世界上所有的計算機都用同樣的ASCII方案來儲存英文文字。

GB2312

後來，就像建造巴比倫塔一樣，世界各地的都開始使用計算機，但是很多國家用的不是英文，他們的字母裡有許多是ASCII裡沒有的，為了可以在計算機儲存他們的文字，他們決定採用 127號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128 到255這一頁的字符集被稱”擴充套件字符集“。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧！等中國人們得到計算機時，已經沒有可以利用的位元組狀態來表示漢字，況且有6000多個常用漢字需要儲存呢。

但是這難不倒智慧的中國人民，我們不客氣地把那些127號之後的奇異符號們直接取消掉, 規定：一個小於127的字元的意義與原來相同，但兩個大於127的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從0xA1用到 0xF7，後面一個位元組（低位元組）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裡，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裡本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常說的”全形”字元，而原來在127號以下的那些就叫”半形”字元了。 中國人民看到這樣很不錯，於是就把這種漢字方案叫做 “GB2312“。GB2312 是對 ASCII 的中文擴充套件。

GBK

但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裡打出來，特別是某些很會麻煩別人的國家領導人。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。 後來還是不夠用，於是乾脆不再要求低位元組一定是127號之後的內碼，只要第一個位元組是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴充套件字符集裡的內容。結果擴充套件之後的編碼方案被稱為 GBK 標準，GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。 後來少數民族也要用電腦了，於是我們再擴充套件，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。

從此之後，中華民族的文化就可以在計算機時代中傳承了。 中國的程式設計師們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 “DBCS“（Double Byte Charecter Set 雙位元組字符集）。在DBCS系列標準裡，最大的特點是兩位元組長的漢字字元和一位元組長的英文字元並存於同一套編碼方案裡，因此他們寫的程式為了支援中處理，必須要注意字串裡的每一個位元組的值，如果這個值是大於127的，那麼就認為一個雙位元組字符集裡的字元出現了。那時候凡是受過加持，會程式設計的計算機僧侶們都要每天念下面這個咒語數百遍： “一個漢字算兩個英文字元！一個漢字算兩個英文字元……”

因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支援別人的編碼，連大陸和臺灣這樣只相隔了150海里，使用著同一種語言的兄弟地區，也分別採用了不同的 DBCS 編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個”漢字系統”，專門用來處理漢字的顯示、輸入的問題，但是那個臺灣的愚昧封建人士寫的算命程式就必須加裝另一套支援 BIG5 編碼的什麼”倚天漢字系統”才可以用，裝錯了字元系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎麼辦？ 真是計算機的巴比倫塔命題啊！

UNICODE

正在這時，大天使加百列及時出現了，一個叫 ISO（國際標誰化組織）的國際組織決定著手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！他們打算叫它”Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “unicode“。unicode開始制訂時，計算機的儲存器容量極大地發展了，空間再也不成為問題了。於是 ISO 就直接規定必須用兩個位元組，也就是16位來統一表示所有的字元，對於ASCII裡的那些“半形”字元，unicode 包持其原編碼不變，只是將其長度由原來的8位擴充套件為16位，而其他文化和語言的字元則全部重新統一編碼。

由於”半形”英文符號只需要用到低8位，所以其高8位永遠是0，因此這種大氣的方案在儲存英文文字時會多浪費一倍的空間。這時候，從舊社會裡走過來的程式設計師開始發現一個奇怪的現象：他們的 strlen 函式靠不住了，一個漢字不再是相當於兩個字元了，而是一個！是的，從 unicode 開始，無論是半形的英文字母，還是全形的漢字，它們都是統一的”一個字元“！同時，也都是統一的”兩個位元組“，請注意”字元”和”位元組”兩個術語的不同，“位元組”是一個8位的物理存貯單元，而“字元”則是一個文化相關的符號。在 unicode 中，一個字元就是兩個位元組。一個漢字算兩個英文字元的時代已經快過去了。

unicode 同樣也不完美，這裡就有兩個的問題，一個是，如何才能區別 unicode 和 ASCII？計算機怎麼知道三個位元組表示一個符號，而不是分別表示三個符號呢？第二個問題是，我們已經知道，英文字母只用一個位元組表示就夠了，如果 unicode 統一規定，每個符號用三個或四個位元組表示，那麼每個英文字母前都必然有二到三個位元組是0，這對於儲存空間來說是極大的浪費，文字檔案的大小會因此大出二三倍，這是難以接受的。

UTF-8

unicode 在很長一段時間內無法推廣，直到網際網路的出現，為解決 unicode 如何在網路上傳輸的問題，於是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF-8就是每次8個位傳輸資料，而 UTF-16 就是每次16個位。UTF-8就是在網際網路上使用最廣的一種 unicode 的實現方式，這是為傳輸而設計的編碼，並使編碼無國界，這樣就可以顯示全世界上所有文化的字元了。UTF-8 最大的一個特點，就是它是一種變長的編碼方式。它可以使用1~4個位元組表示一個符號，根據不同的符號而變化位元組長度，當字元在 ASCII 碼的範圍時，就用一個位元組表示，保留了 ASCII 字元一個位元組的編碼做為它的一部分，注意的是 unicode 一箇中文字元佔2個位元組，而UTF-8一箇中文字元佔3個位元組）。從 unicode 到 uft-8 並不是直接的對應，而是要過一些演算法和規則來轉換。

看到這裡你是徹底懵逼還是恍然大悟，如果是徹底懵逼建議你再多看幾次，溫故而知新，如果恍然大悟的話我們就接著往下看。

中文亂碼例項講解

介紹完了基礎知識，我們來說說 Python 中是如何儲存字元的，先來看一個亂碼的例子。新建一個 demo.py 檔案，檔案儲存格式為utf-8檔案中內容如下。

s = "中文"
print s

在 cmd 中執行 python demo.py，什麼，我只是想列印中文兩個字居然給我報錯，簡直不可理喻啊！

趕緊開啟 python 自帶的 idle 試試看，一點問題都沒有啊，這是為什麼呢？

回頭好好看看 cmd 下報的錯誤Non-ASCII character '\xe4' in file demo.py on line 1, but no encoding declared;，翻譯過來就是 在 demo.py 檔案的第 1 行有非 ASCII 字元 ‘\xe4’，而且沒有宣告編碼，從上面基礎知識可知，ASCII 編碼是不能表示漢字中文的，demo.py 檔案第一行有中文兩個漢字，而 demo.py 檔案儲存格式為utf-8，所以中文兩個漢字在檔案中儲存的時候是以 utf-8編碼儲存的，檢視 demo.py 檔案 16 進位制可以看到中文 儲存的是 \xe4\xb8\xad\xe6\x96\x87。

16 進位制檢視用的是 notepad++ 自帶的 HEX-Editor 外掛，另外函式 repr也能顯示原始字串，如下。

# encoding:utf-8
import sys
print sys.getdefaultencoding()
s = "中文"
print repr(s)

sys.getdefaultencoding()讀取 python 預設編碼是 ASCII，而 ASCII 是不認識 \xe4的，所以會報錯Non-ASCII character '\xe4' in file demo.py on line 1, but no encoding declared;，此時只要在 demo.py 檔案頭加上 # encoding:utf-8就可以了，雖然是註釋，但 python 看到這句話就知道了接下來應該用utf-8編碼了，而 demo.py 儲存時也是utf-8的，所以就正常了。

# encoding:utf-8
s = "中文"
print s

編碼宣告註釋寫成# -*- coding: utf-8 -*-也是可以的，只要滿足正規表示式^[ \t\v]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)就OK。

我們再次在 cmd 下執行 python demo.py 試試看。

啥，啥，啥，說好的顯示中文呢？這不是逗我嗎？去 python idle 下試試看。

為什麼同樣的檔案在 python idle 中卻正常呢？肯定是 cmd 有問題，是的，我也是這樣想的，那我試著在 cmd 下進入 python 互動模式輸出中文看看，我去居然 cmd 下也是可以正常輸出 中文的，相信看到這裡小夥伴們都已經暈了。

別急，聽我慢慢分析。其實當在 cmd 或者 idle 中列印字元的時候已經和檔案編碼方式沒有關係了，此時起作用的是輸出環境也就是 cmd 或者 idle 的編碼方式有關，檢視 cmd 的編碼命令是 chcp，返回 936，去網上查詢可知 936 代表 GBK 編碼，這下我們大概知道什麼原因了，demo.py 檔案儲存和編碼宣告都是utf-8，但是 cmd 顯示編碼是 GBK，而將中文的utf-8 編碼 \xe4\xb8\xad\xe6\x96\x87 強制轉換為 GBK 就會亂碼了，GBK 是兩個位元組儲存一箇中文字元，所以 \xe4\xb8\xad\xe6\x96\x87 會解碼成三個字，很不幸這三個字涓枃不是常用字也不是我們想要的字元，所以就認為是亂碼了。為什麼在 cmd 下進入 Python 互動式命令列可以呢，這是因為當在 python 互動式命令列輸入s = "中文"時，中文這兩個漢字其實是以 GBK 編碼儲存的，cmd 預設編碼是 GBK ，不信看s列印\xd6\xd0\xce\xc4，這就是GBK編碼方式儲存，而utf-8編碼方式儲存同樣的中文為\xe4\xb8\xad\xe6\x96\x87。下面告訴大家怎麼解決在 cmd 下執行檔案正確輸出中文問題。

1、demo.py 檔案和編碼宣告都為 GBK

這種方法比較笨，就是把 demo.py 檔案改為 GBK 儲存，而且編碼宣告也是GBK，個人不推薦。

# encoding:gbk
s = "中文"
print s
print repr(s)

2、中文用 unicode 表示

只要在中文前面加上個小u標記，後面的中文就用 unicode 儲存了。

# encoding:utf-8
s = u"中文"
print s
print repr(s)

cmd 下是可以列印 unicode 字元的，如下。

3、把中文強制轉換為GBK或者unicode編碼

強制轉換為unicode編碼，在 Python 中編碼是可以互相轉換的，比如從utf-8轉換為gbk，不同編碼之間不能直接轉換，需要通過unicode字符集中間過渡下，從上面基礎知識可知unicode是一種字符集，不屬於編碼，而utf-8是具體實現unicode思想的一種編碼。utf-8轉換為unicode是一種解碼過程，通過decode可從utf-8解碼成unicode。

# encoding:utf-8
s = "中文"
u = s.decode('utf-8')
print u
print type(u)
print repr(u)

強制轉換為gbk編碼，上一步已經從utf-8轉換為unicode了，從unicode是編碼的過程，通過encode實現。

# encoding:utf-8
s = "中文"
u = s.decode('utf-8')
g = u.encode('gbk')
print g
print type(g)
print repr(g)

總結
windows cmd 視窗下不支援utf-8，想要顯示中文必須轉換為gbk或者unicode，而 Python idle 中這三種編碼都支援。中文亂碼的出現都是由於編碼不一致導致的，儲存的是用utf-8，列印的時候用gbk就會亂碼了，所有要保證不亂碼儘量保持統一，建議全部使用unicode。

decode 解碼

從其它編碼變成unicode叫解碼，解碼用的方法是decode，第一個引數為被解碼的字串原始編碼格式，如果寫錯了也會報錯。比如 s 是utf-8，用gbk去解碼就會報錯。

# encoding:utf-8
s = "中文"
u = s.decode('gbk')
print u
print repr(u)

小提示
在 Python idle 和 cmd 下直接輸入 s = "中文"會以 gbk 編碼的，如果在檔案中輸入 s = "中文"且檔案儲存格式為utf-8，那麼 s 是以utf-8編碼儲存的，有點不一樣曾經踩過坑，及時 Python idle 成功了檔案執行的時候也可能失敗。

encode 編碼

不可以直接從utf-8轉換為gbk，必須經過unicode中間轉換，這點很重要，被編碼的原始字串一定要為unicode，否則會報錯。

raw_input

raw_input 是獲取使用者輸入值的，獲取到的使用者輸入值和當前執行環境編碼有關，比如 cmd 下預設編碼是 gbk，那麼輸入的漢字就是以gbk編碼，而不管 demo.py 檔案編碼格式和編碼宣告。

# encoding:utf-8
s = raw_input("input something: ")
print s
print type(s)
print repr(s)

GBK 編碼一個漢字兩個位元組，UTF-8 一個漢字通常3個位元組。

細心的朋友已經注意了，raw_input的提示語我用的是英文，那改成中文看看，果真出現亂碼了。

# encoding:utf-8
s = raw_input("請輸入中文漢字：")
print s
print type(s)
print repr(s)

怎麼辦呢？把提示字串強制為gbk編碼就好，unicode和utf-8都不可以。

# encoding:utf-8
s = raw_input(u"請輸入中文漢字：".encode('gbk'))
print s
print type(s)
print repr(s)

相等陷阱

“中文”這兩個字串用不同的編碼儲存是不一樣的，utf-8編碼和gbk編碼儲存的“中文”都不一樣。

總結

一口氣說了這麼多，不知道你們看懂沒？想要不亂碼，記住以下5點法則就好。

1. 檔案儲存為utf-8格式，編碼宣告為utf-8，# encoding:utf-8
2. 出現漢字的地方前面加 u
3. 不同編碼之間不能直接轉換，要經過unicode中間跳轉
4. cmd 下不支援utf-8編碼
5. raw_input提示字串只能為gbk編碼