在之前的文章中，我們介紹過編碼格式的發展史：[文章傳送門-todo]。今天我們通過幾個例子，來徹底搞清楚python3中的編碼格式原理，這樣你之後寫python指令碼時碰到編碼問題，才能有章可循。

我們先搞清楚幾個概念：

• 系統預設編碼：指python直譯器預設的編碼格式，在python檔案頭部沒有宣告其他編碼格式時，python3預設的編碼格式是utf-8。
• 本地預設編碼：作業系統預設的編碼，常見的Windows的預設編碼是gbk，Linux的預設編碼是UTF-8。
• python檔案頭部宣告編碼格式：修改的是檔案的預設編碼格式，只是會影響python直譯器讀取python檔案時的編碼格式，並不會改變系統預設編碼和本地預設編碼。

通過python自帶的庫，可以檢視系統預設編碼和本地預設編碼

Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getdefaultencoding()
'utf-8'
>>> import locale
>>> locale.getdefaultlocale()
('zh_CN', 'cp936')
>>>
 

注意，因為我在windows系統的電腦上 進行測試，所以系統預設編碼返回“cp936”, 這是內碼表（是字元編碼集的別名），而936對應的就是gbk。如果你在linux或者mac上執行上面的程式碼，應該會返回utf-8編碼。

其實總結來看，容易出現亂碼的場景，基本都與讀寫程式有關，比如：讀取/寫入某個檔案，或者從網路流中讀取資料等，因為這個過程中涉及到了編碼 和解碼的過程，只要編碼和解碼的編碼格式對應不上，就容易出現亂碼。下面我們舉兩個具體的例子，來驗證下python的編碼原理，幫助你理解這個過程。注意：下面的例子都是在pycharm中寫的。

01預設的編碼格式

我們新建一個encode_demo.py的檔案，其檔案預設的編碼格式是UTF-8（可以從pycharm右下角看到編碼格式），程式碼如下：

"""
    @author: asus
    @time: 2019/11/21
    @function: 驗證編碼格式
"""
import sys, locale


def write_str_default_encode():
    s = "我是一個str"
    print(s)
    print(type(s))
    print(sys.getdefaultencoding())
    print(locale.getdefaultlocale())

    with open("utf_file", "w", encoding="utf-8") as f:
        f.write(s)
    with open("gbk_file", "w", encoding="gbk") as f:
        f.write(s)
    with open("jis_file", "w", encoding="shift-jis") as f:
        f.write(s)


if __name__ == '__main__':
    write_str_default_encode()

我們先來猜測下結果，因為我們沒有宣告編碼格式，所以python直譯器預設用UTF-8去解碼檔案，因為檔案預設編碼格式就是UTF-8，所以字串s可以正常列印。同時以UTF-8編碼格式寫檔案不會出現亂碼，而以gbk和shift-jis（日文編碼）寫檔案會出現亂碼（這裡說明一點，我是用pycharm直接開啟生成的檔案檢視的，編輯器預設編碼是UTF-8，如果在windows上用記事本開啟則其預設編碼跟隨系統是GBK，gbk_file和utf_file均不會出現亂碼，只有jis_file是亂碼），我們執行看下結果：

# 執行結果
我是一個str
<class 'str'>
utf-8
('zh_CN', 'cp936')

# 寫檔案utf_file、gbk_file、jis_file檔案內容分別是：
我是一個str
����һ��str
�䐥�꘢str

和我們猜測的結果一致，下面我們做個改變，在檔案頭部宣告個編碼格式，再來看看效果。

02 python標頭檔案宣告編碼格式

因為上面檔案encode_demo.py的格式是UTF-8，那麼我們就將其變為gbk編碼。同樣的我們先來推測下結果，在pycharm中，在python檔案頭部宣告編碼為gbk後（頭部加上 # coding=gbk ），檔案的編碼格式變成gbk，同時python直譯器會用gbk去解碼encode_demo.py檔案，所以執行結果應該和用UTF-8編碼時一樣。執行結果如下：

# 執行結果
我是一個str
<class 'str'>
utf-8
('zh_CN', 'cp936')

# 寫檔案utf_file、gbk_file、jis_file檔案內容分別是：
我是一個str
����һ��str
�䐥�꘢str

結果確實是一樣的，證明我們推論是正確的。接下來我們再做個嘗試，假如我們將（# coding=gbk）去掉（需要注意，在pycharm中將 # coding=gbk去掉，並不會改變檔案的編碼格式，也就是說encode_demo.py還是gbk編碼），我們再執行一次看結果：

  File "D:/codespace/python/pythonObject/pythonSample/basic/encodeDemo/encode_demo.py", line 4
SyntaxError: Non-UTF-8 code starting with '\xd1' in file D:/codespace/python/pythonObject/pythonSample/basic/encodeDemo/encode_demo.py on line 5, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

執行直接報錯了，我們加個斷點，看看具體的異常資訊：

看錯誤提示是UnicodeDecodeError，python直譯器在對encode_demo.py檔案解碼時，使用預設的UTF-8編碼，但是檔案本身是gbk編碼，所以當碰到有中文沒辦法識別時，就丟擲DecodeError。

03 敲黑板，劃重點

python3中的str和bytes

python3的重要特性之一就是對字串和二進位制流做了嚴格的區分，我們宣告的字串都是str型別，不過Str和bytes是可以相互轉換的：

def str_transfor_bytes():
    s = '我是一個測試Str'
    print(type(s))
    # str 轉bytes
    b = s.encode()
    print(b)
    print(type(b))
    # bytes轉str
    c = b.decode('utf-8')
    print(c)
    print(type(c))


if __name__ == '__main__':
    str_transfor_bytes()

需要注意一點：在呼叫encode()和decode()方法時，如果不傳引數，則會使用python直譯器預設的編碼格式UTF-8（如果不在python標頭檔案宣告編碼格式）。但是如果傳參的話，encode和decode使用的編碼格式要能對應上。

python3預設編碼是UTF-8？還是Unicode？

經常在很多文章裡看到，python3的預設編碼格式是Unicode，但是我在本文中卻一直在說python3的預設編碼格式是UTF-8，那麼哪種說法是正確的呢？其實兩種說法都對，主要得搞清楚Unicode和UTF-8的區別（之前文章有提到）：

• Unicode是一個字符集，說白了就是把各種編碼的對映關係全都整合起來，不過它是不可變長的，全部都以兩個位元組或四個位元組來表示，佔用的記憶體空間比較大。
• UTF-8是Unicode的一種實現方式，主要對 Unicode 碼的資料進行轉換，方便儲存和網路傳輸 。它是可變長編碼，比如對於英文字母，它使用一個位元組就可以表示。

在python3記憶體中使用的字串全都是Unicode碼，當python直譯器解析python檔案時，預設使用UTF-8編碼。

open()方法預設使用本地編碼

在上面的例子中，我們往磁碟寫入檔案時，都指定了編碼格式。如果不指定編碼格式，那麼預設將使用作業系統本地預設的編碼格式，比如：Linux預設是UTF-8，windows預設是GBK。其實這也好理解，因為和磁碟互動，肯定要考慮作業系統的編碼格式。這有區別於encode()和decode()使用的是python直譯器的預設編碼格式，千萬別搞混淆了。

總結

不知道你看完上面的例子後，是否已經徹底理解了python3的編碼原理。不過所有的編碼問題，都逃不過“編碼”和“解碼”兩個過程，當你碰到編碼問題時，先確定原始檔使用的編碼，再確定目標檔案需要的編碼格式，只要能匹配，一般就可以解決編碼的問題。

相關推薦