python編碼問題大終結

 

1、瞭解字符編碼的知識儲備

　　1. 文本編輯器存取文件的原理（nodepad++，pycharm，word）

　　　　 打開編輯器就打開了啓動了一個進程，是在內存中的，因此在編輯器編寫的內容也都是存放與內存中的，斷電後數據丟失，於是須要保存到硬盤上，點擊保存按鈕，就從內存中把數據刷到了硬盤上。在這一點上，咱們編寫一個py文件（沒有執行），跟編寫其餘文件沒有任何區別，都只是在編寫一堆字符而已。

　　　　即:在沒有點擊保存時,咱們所寫的內容都是寫入內存。注意這一點，很重要！！當咱們點擊保存，內容才被刷到硬盤。

　　　　上面作了兩件事：寫內容到內存,從內存將內存刷到硬盤。這是兩個過程。

      2. python解釋器執行py文件的原理 ，例如python test.py

　　　　第一階段：python解釋器啓動，此時就至關於啓動了一個文本編輯器

　　　　第二階段：python解釋器至關於文本編輯器，去打開test.py文件，從硬盤上將test.py的文件內容讀入到內存中

　　　　第三階段：python解釋器解釋執行剛剛加載到內存中test.py的代碼

　　　　python解釋器執行py文件分爲兩個步驟:1.將文件讀到內存,2.解釋執行內容。

2、字符編碼簡介

　　要搞清楚字符編碼，首先要解決的問題是：什麼是字符編碼？

　　咱們都知道，計算機要想工做必須通電,也就是說‘電’驅使計算機幹活,而‘電’的特性，就是高低電平(高低平即二進制數1,低電平即二進制數0),也就是說計算機只認識數字(010101).若是咱們想保存數據,首先得將咱們的數據進行一些處理，最終得轉換成010101才能讓計算機識別。

　　因此必須通過一個過程：

　　字符--------（翻譯過程）------->數字 

　　這個過程實際就是一個字符如何對應一個特定數字的標準，這個標準稱之爲字符編碼。

　　那麼問題就來了？做爲一種編碼方案，還得解決兩個問題:

　　　　a.字節是怎麼分組的，如8 bits或16 bits一組，這也被稱做編碼單元。

　　　　b.編碼單元和字符之間的映射關係。例如，在ASCII碼中，十進制65映射到字母A上。

　　ASCII碼是上個世紀最流行的編碼體系之一，至少在西方是這樣。下圖顯示了ASCII碼中編碼單元是怎麼映射到字符上的。

　　

3、字符編碼的發展史

階段一：現代計算機起源於美國，最先誕生也是基於英文考慮的ASCII

　　隨着計算機愈來愈流行，廠商之間的競爭更加激烈，在不一樣的計算機體系間轉換數據變得十分蛋疼，人們厭煩了這種自定義形成的混亂。最終，計算機制造商一塊兒制定了一個標準的方法來描述字符。他們定義使用一個字節的低7位來表示字符，而且製做瞭如上圖所示的對照表來映射七個比特的值到一個字符上。例如，字母A是65，c是99，~是126等等， ASCII碼就這樣誕生了。原始的ASCII標準定義了從0到127 的字符，這樣正好能用七個比特表示。

　　爲何選擇了7個比特而不是8個來表示一個字符呢？我並不關心。可是一個字節是8個比特，這意味着1個比特並無被使用，也就是從128到255的編碼並無被制定ASCII標準的人所規定，這些美國人對世界的其它地方一無所知甚至徹底不關心。其它國家的人趁這個機會開始使用128到255範圍內的編碼來表達本身語言中的字符。例如，144在阿拉伯人的ASCII碼中是گ，而在俄羅斯的ASCII碼中是ђ。ASCII碼的問題在於儘管全部人都在0-127號字符的使用上達成了一致，但對於128-255號字符卻有不少不少不一樣的解釋。你必須告訴計算機使用哪一種風格的ASCII碼才能正確顯示128-255號的字符。

　　總結：ASCII，一個Bytes表明一個字符（英文字符/鍵盤上的全部其餘字符），1Bytes=8bit，8bit能夠表示0-2**8-1種變化，便可以表示256個字符，ASCII最初只用了後七位，127個數字，已經徹底可以表明鍵盤上全部的字符了（英文字符/鍵盤的全部其餘字符），後來爲了將拉丁文也編碼進了ASCII表，將最高位也佔用了。

階段二:爲了知足中文，中國人定製了GBK

　　GBK:2Bytes表明一個字符；爲了知足其餘國家，各個國家紛紛定製了本身的編碼。日本把日文編到Shift_JIS裏，韓國把韓文編到Euc-kr裏

階段三：萬國碼Unicode編碼

　　後來，有人開始以爲太多編碼致使世界變得過於複雜了，讓人腦殼疼，因而你們坐在一塊兒拍腦殼想出來一個方法：全部語言的字符都用同一種字符集來表示，這就是Unicode。

Unicode統一用2Bytes表明一個字符，2**16-1=65535，可表明6萬多個字符，於是兼容萬國語言.但對於通篇都是英文的文原本說，這種編碼方式無疑是多了一倍的存儲空間（英文字母只須要一個字節就足夠,用兩個字節來表示,無疑是浪費空間）.因而產生了UTF-8，對英文字符只用1Bytes表示，對中文字符用3Bytes.UTF-8是一個很是驚豔的概念，它漂亮的實現了對ASCII碼的向後兼容，以保證Unicode能夠被大衆接受。

在UTF-8中，0-127號的字符用1個字節來表示，使用和US-ASCII相同的編碼。這意味着1980年代寫的文檔用UTF-8打開一點問題都沒有。只有128號及以上的字符才用2個，3個或者4個字節來表示。所以，UTF-8被稱做可變長度編碼。因而下面字節流以下：

　　　　0100100001000101010011000100110001001111

　　這個字節流在ASCII和UTF-8中表示相同的字符：HELLO

　　至於其餘的UTF-16，這裏就再也不敘述了。

　　總結一點：unicode：簡單粗暴，全部字符都是2Bytes，優勢是字符----->數字的轉換速度快，缺點是佔用空間大。

　　　　　　　utf-8：精準，對不一樣的字符用不一樣的長度表示，優勢是節省空間，缺點是：字符->數字的轉換速度慢，由於每次都須要計算出字符須要多長的Bytes纔可以準確表示。

　　所以，內存中使用的編碼是unicode，用空間換時間（程序都須要加載到內存才能運行，於是內存應該是儘量的保證快）；硬盤中或者網絡傳輸用utf-8，網絡I/O延遲或磁盤I/O延遲要遠大與utf-8的轉換延遲，並且I/O應該是儘量地節省帶寬，保證數據傳輸的穩定性。

　　全部程序，最終都要加載到內存，程序保存到硬盤不一樣的國家用不一樣的編碼格式，可是到內存中咱們爲了兼容萬國（計算機能夠運行任何國家的程序緣由在於此），統一且固定使用unicode，這就是爲什麼內存固定用unicode的緣由，你可能會說兼容萬國我能夠用utf－8啊，能夠，徹底能夠正常工做，之因此不用確定是unicode比utf－8更高效啊（uicode固定用2個字節編碼，utf－8則須要計算），可是unicode更浪費空間，沒錯，這就是用空間換時間的一種作法，而存放到硬盤，或者網絡傳輸，都須要把unicode轉成utf－8，由於數據的傳輸，追求的是穩定，高效，數據量越小數據傳輸就越靠譜，因而都轉成utf－8格式的，而不是unicode。

 4、字符編碼的使用

　　不論是哪一種類型的文件，只要記住一點：文件以什麼編碼保存的，就以什麼編碼方式打開.

　　下面咱們來看看python中關於編碼出現的問題:

　　若是不在python文件指定頭信息＃-*-coding:utf-8-*-,那就使用默認的python2中默認使用ascii，python3中默認使用utf-8

　　讀取已經加載到內存的代碼（unicode編碼的二進制），而後執行，執行過程當中可能會開闢新的內存空間，好比x="hello"

　　內存的編碼使用unicode，不表明內存中全都是unicode編碼的二進制，在程序執行以前，內存中確實都是unicode編碼的二進制,好比從文件中讀取了一行x="hello",其中的x，等號，引號，地位都同樣，都是普通字符而已，都是以unicode編碼的二進制形式存放與內存中的.可是程序在執行過程當中，會申請內存（與程序代碼所存在的內存是倆個空間），能夠存聽任意編碼格式的數據，好比x="hello",會被python解釋器識別爲字符串，會申請內存空間來存放"hello"，而後讓x指向該內存地址，此時新申請的該內存地址保存也是unicode編碼的hello,若是代碼換成x="hello".encode('utf-8'),那麼新申請的內存空間裏存放的就是utf-8編碼的字符串hello了.

　　

　　瀏覽網頁的時候，服務器會把動態生成的Unicode內容轉換爲UTF-8再傳輸到瀏覽器

　　　　　　

　　若是服務端encode的編碼格式是utf-8， 客戶端內存中收到的也是utf-8編碼的二進制

5、Python2與python3編碼區別

　　1.在python2中有兩種字符串類型str和unicode

　　　str類型

　　　當python解釋器執行到產生字符串的代碼時（例如s='林'），會申請新的內存地址，而後將'林'編碼成文件開頭指定的編碼格式，這已是encode以後的結果了，因此s只能decode。再次encode就會報錯。

#_*_coding:gbk_*_
2 #!/usr/bin/env python
3 
4 x='林'
5 # print x.encode('gbk') #報錯
6 print x.decode('gbk') #結果：林

　　在python2中，str就是編碼後的結果bytes，str=bytes,因此在python2中，unicode字符編碼的結果是str/bytes。

#coding:utf-8
s='林' #在執行時,'林'會被以conding:utf-8的形式保存到新的內存空間中

print repr(s) #'\xe6\x9e\x97' 三個Bytes,證實確實是utf-8
print type(s) #<type 'str'>

s.decode('utf-8')
# s.encode('utf-8') #報錯，s爲編碼後的結果bytes，因此只能decode

　　Unicode類型

　　當python解釋器執行到產生字符串的代碼時（例如s=u'林'），會申請新的內存地址，而後將'林'以unicode的格式存放到新的內存空間中，因此s只能encode，不能decode.

s=u'林'
print repr(s) #u'\u6797'
print type(s) #<type 'unicode'>


# s.decode('utf-8') #報錯，s爲unicode，因此只能encode
s.encode('utf-8') 

　　特別說明:

　　當數據要打印到終端時，要注意一些問題.

　　當程序執行時，好比:x='林';print(x) #這一步是將x指向的那塊新的內存空間（非代碼所在的內存空間）中的內存，打印到終端，而終端仍然是運行於內存中的，因此這打印能夠理解爲從內存打印到內存，即內存->內存，unicode->unicode.對於unicode格式的數據來講，不管怎麼打印，都不會亂碼.python3中的字符串與python2中的u'字符串'，都是unicode，因此不管如何打印都不會亂碼.在windows終端（終端編碼爲gbk，文件編碼爲utf-8，亂碼產生）

#分別驗證在pycharm中和cmd中下述的打印結果
s=u'林' #當程序執行時，'林'會被以unicode形式保存新的內存空間中


#s指向的是unicode，於是能夠編碼成任意格式，都不會報encode錯誤
s1=s.encode('utf-8')
s2=s.encode('gbk')
print s1 #打印正常否？
print s2 #打印正常否


print repr(s) #u'\u6797'
print repr(s1) #'\xe6\x9e\x97' 編碼一個漢字utf-8用3Bytes
print repr(s2) #'\xc1\xd6' 編碼一個漢字gbk用2Bytes

print type(s) #<type 'unicode'>
print type(s1) #<type 'str'>
print type(s2) #<type 'str'>

　　2. 在python3中也有兩種字符串類型str和bytes

　　str類型變爲unicode類型

#coding:utf-8
s='林' #當程序執行時，無需加u，'林'也會被以unicode形式保存新的內存空間中,

#s能夠直接encode成任意編碼格式
s.encode('utf-8')
s.encode('gbk')

print(type(s)) #<class 'str'>

　　bytes類型

#coding:utf-8
s='林' #當程序執行時，無需加u，'林'也會被以unicode形式保存新的內存空間中,

#s能夠直接encode成任意編碼格式
s1=s.encode('utf-8')
s2=s.encode('gbk')



print(s) #林
print(s1) #b'\xe6\x9e\x97' 在python3中，是什麼就打印什麼
print(s2) #b'\xc1\xd6' 同上

print(type(s)) #<class 'str'>
print(type(s1)) #<class 'bytes'>
print(type(s2)) #<class 'bytes'>