淺談Python編碼

導語

經常看到有人問關於python編碼的問題，但網上關於python編碼的文章大多含糊其辭，有用而無大用，於是想著以個人粗鄙之見聊一聊關於python編碼的問題。

測試系統

Windows版本：

Linux版本：

進入正題

說明：

本文所涉及的所有內容均基於python3。

首先，我們來看看下面這段代碼：

在Windows系統下的運行結果為：

注1：

cp936即gbk。

在Linux系統下的運行結果為：

為什麼系統默認編碼和本地默認編碼不一樣呢(sys:系統，locale:本地)？

這裡我們需要搞清楚系統默認編碼和本地默認編碼的區別：

① 系統默認編碼

這裡的系統不是操作系統，而是python系統，可以認為是python的編譯器，因此系統默認編碼即python編譯器的默認編碼。

② 本地默認編碼

本地指的才是操作系統，因此本地默認編碼即操作系統的默認編碼。

顯然，python編譯器的默認編碼在不同的操作系統中保持一致，操作系統的默認編碼隨操作系統的不同而發生了改變。

注2：

python2和python3編譯器的默認編碼是不同的，分別是ascii和utf-8。

那麼他們各自有什麼用呢？

① 系統默認編碼

當python的編譯器讀取.py文件時，若無編碼聲明，則使用系統默認編碼來解碼.py文件。

注3：

編碼聲明告訴了python編譯器以什麼格式的編碼來解碼.py文件，即它不會改變系統默認編碼和本地默認編碼，也不是用於聲明當前代碼文件的編碼格式的，而是聲明當前代碼文件的解碼方式。換句話說，代碼文件的編碼格式取決於你使用的編輯器，而如何解碼該文件取決於文件頭處的編碼聲明。

一般地，編碼格式應當與解碼格式一致，即編輯器的編碼格式與編碼聲明應當一致，但保持一致並不代表含義相同。

② 本地默認編碼

對於open()函數，若不聲明編碼，則自動使用本地默認編碼：

更進一步。

接下來我們來看一段代碼及其運行結果，然後結合上面的鋪墊來解釋一下為什麼會有這樣的運行結果：

注4：

TIS-620為泰文編碼。

Windows系統下運行結果：

Linux系統下運行結果：

這示例代碼也太逗了吧，還報錯？開個玩笑，顯然，最受人矚目的應當是代碼報錯了吧，亂碼怎麼也比報錯強吧？OK，那我們就先來解釋一下代碼報錯的原因吧：

首先，我用代碼編輯器寫好了上圖中的代碼並保存，其中代碼編輯器使用的編碼格式為utf-8，上圖為證：

即代碼以utf-8的編碼格式保存在代碼文件中。現在運行該代碼文件，根據編碼聲明，編譯器使用gbk來解碼該.py文件，根據終端的列印結果可知：

現在我們需要將test_str寫入磁碟，根據錯誤提示，我們發現以utf-8和gbk編碼格式將其寫入磁碟時，並沒有報錯，但以泰文編碼格式將其寫入磁碟時，卻發生了報錯。

Why？因為泰文里沒有中文字元啊！所以編碼到中文字元時，就提示編碼失敗了！

注5：

position 7代表第八個字元。

現在我們再來看看亂碼問題！為什麼以utf-8編碼格式將變數寫入磁碟時發生了亂碼，而以gbk編碼格式將變數寫入磁碟時卻沒有發生亂碼呢？其中究竟發生了什麼事情？

① 以gbk編碼格式將變數寫入磁碟

編解碼過程如下：

即編譯器使用gbk來解碼utf-8編碼的.py文件之後，又利用gbk編碼格式將獲得的變數寫入的到磁碟文件中，之後打開該磁碟文件，代碼編輯器用utf-8解碼該.py文件後顯示文件內容。顯然，步驟三是步驟二的逆過程，步驟四是步驟一的逆過程，因此，最終結果是不會發生亂碼的。

② 以utf-8編碼格式將變數寫入磁碟

顯然，此處步驟四是步驟三的逆過程，最終的結果顯示亂碼也就在意料之中了。

寫在最後。

① 為什麼經常看到utf-8解碼報錯？

utf-8的定義十分嚴格，英文字元佔一個位元組(高位必須為0)，阿拉伯文佔兩個位元組，中文以及日文佔三個位元組(第一個位元組的高位必須是1110)。而gbk則比較死板，所有字元都佔兩個位元組。

② Unicode是啥？

Unicode只是一個符號集，一個字元對應一個數字(或者說是一個ID)；utf-8則是一種編碼規則，用於實現Unicode的傳輸和存儲。

想進一步了解兩者區別的話，請參考：

https://www.zhihu.com/question/23374078

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

That"s all.

更多

以上內容僅代表個人理解。

如有錯誤，還望指正。

○

○

Charles的皮卡丘

Pikachu~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！