Python編碼為什麼那麼蛋疼?

一旦走上了編程之路，要是你不把編碼題目搞明白，那麼它將像幽靈一樣平常膠葛你整個職業生活，種種靈異變亂會相繼而來，揮之不去。只有充分發揮步伐員去世磕到底的精力你才有大概徹底開脫編碼題目帶來的煩末路，我第一次遇到編碼題目是寫JavaWeb相干的項目，一串字元從欣賞器遊離到應用步伐代碼中，翻江倒海迷戀到資料庫中，隨時隨地都有大概踩到編碼的地雷。第二次遇到編碼題目便是學Python的時間，在爬取網頁數據時，編碼題目又出現了，當時我的心情是奔潰的，用時下最ing的一句話便是：「我當時就懵逼了」。為了搞清字元編碼，你和我得從謀略機的劈頭開始，謀略機中的全部數據，不論是筆墨、圖片、視頻、還是音頻文件，本質上終極都是根據雷同01010101的數字情勢存儲的。你和我是榮幸的，你和我也是不幸的，榮幸的是期間付與了你和我都有機遇打仗謀略機，不幸的是，謀略機不是你和我國人發明的，以是謀略機的標準得按美帝國人的風俗來計劃，那麼最開始謀略機是通過什麼樣的方法來表現字元的呢？這要從謀略機編碼的生長史提及。

ASCII

EASCII(ISO/8859-1)

然而謀略機漸漸地遍及到其他西歐地區時，他們發明另有很多西歐所特有的字元是ASCII編碼表中沒有的，於是其後出現了可擴展的ASCII叫EASCII，顧名思義，它是在ASCII的底子上擴展而來，把原來的7位擴充到8位，它完全兼容ASCII，擴展出來的標記包括表格標記、謀略標記、希臘字母和特別的拉丁標記。然而EASCII期間是一個紊亂的期間，大家沒有同一標準，他們各自把最高位根據本身的標準實現了本身的一套字元編碼標準，比較聞名的就有CP437，CP437是Windows體系中利用的字元編碼，如下圖：

別的一種被遍及利用的EASCII另有ISO/8859-1(Latin-1)，它是國際標準化構造（ISO）及國際電工委員會（IEC）連合訂定的一系列8位元字符集的標準，ISO/8859-1隻承繼了CP437字元編碼的128-159之間的字元，以是它是從160開始定義的，不幸的是這些浩繁的ASCII擴充字集之間互不兼容。

GBK

隨著期間的進步，謀略機開始遍及到千家萬戶，比爾蓋茨讓每個人私家桌面都有一台電腦的空想得以實現。但是謀略機進入中國不得不面對的一個題目便是字元編碼，固然咱們國度的漢字是人類利用頻率最多的筆墨，漢字博大博識，常見的漢字就有成千上萬，這已經大大高出了ASCII編碼所能表現的字元範疇了，縱然是EASCII也顯得人浮於事，於是智慧的中國人本身弄了一套編碼叫GB2312，又稱GB0，1981由中國國度標準總局頒布。GB2312編碼共收錄了6763個漢字，同時他還兼容ASCII，GB2312的出現，根本饜足了漢字的謀略機處理懲罰必要，它所收錄的漢字已經包圍中國大陸99.75%的利用頻率，不過GB2312還是不克不及100%饜足中國漢字的需求，對一些有數的字和繁體字GB2312沒法處理懲罰，其後就在GB2312的底子上創建了一種叫GBK的編碼，GBK不但收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等重要的少數民族筆墨。同樣GBK也是兼容ASCII編碼的，對付英筆墨符用1個位元組來表現，漢字用兩個位元組來標識。

Unicode對付如那邊理懲罰中國人本身的筆墨你和我可以另立山頭，根據你和我本身的需求訂定一套編碼範例，但是謀略機不止是美國人和中國人用啊，另有歐洲、亞洲其他國度的筆墨諸如日文、韓文全天下各地的筆墨加起來預計也有好幾十萬，這已經大大高出了ASCII碼乃至GBK所能表現的範疇了，何況人家為什麼用採取你GBK標準呢？云云巨大的字元庫原形用什麼方法來表現好呢？於是同一同盟國際構造提出了Unicode編碼，Unicode的學名是"UniversalMultiple-OctetCodedCharacterSet"，簡稱為UCS。Unicode有兩種格局：UCS-2和UCS-4。UCS-2便是用兩個位元組編碼，一共16個比特位，如許理論上最多可以表現65536個字元，不過要表現全天下全部的字元表現65536個數字還遠遠不過，由於光漢字就有近10萬個，因此Unicode4.0範例定義了一組附加的字元編碼，UCS-4便是用4個位元組（實際上只用了31位，最高位必須為0）。理論上完全可以涵蓋統統語言所用的標記。天下上任何一個字元都可以用一個Unicode編碼來表現，一旦字元的Unicode編碼確定下來後，就不會再變化了。但是Unicode有肯定的範圍性，一個Unicode字元在網路上傳輸大概終極存儲起來的時間，並不見得每個字元都必要兩個位元組，比如一字元「A「，用一個位元組就可以表現的字元，偏偏還要用兩個位元組，顯然太浪費空間了。第二題目是，一個Unicode字元生存到謀略機內里時便是一串01數字，那麼謀略機怎麼知道一個2位元組的Unicode字元是表現一個2位元組的字元呢，還是表現兩個1位元組的字元呢，要是你不事先報告謀略機，那麼謀略機也會懵逼了。Unicode只是規定怎樣編碼，並沒有規定怎樣傳輸、生存這個編碼。比方「漢」字的Unicode編碼是6C49，我可以用4個ascii數字來傳輸、生存這個編碼；也可以用utf-8編碼的3個連續的位元組E6B189來表現它。關鍵在於通訊兩邊都要承認。因此Unicode編碼有差別的實現方法，比如：UTF-8、UTF-16等等。這裡的Unicode就像英語一樣，做為國與國之間交換天下通用的標準，每個國度有本身的語言，他們把標準的英文文檔翻譯成本身國度的筆墨，這是實現方法，就像utf-8。

UTF-8UTF-8（UnicodeTransformationFormat）作為Unicode的一種實現方法，遍及應用於互聯網，它是一種變長的字元編碼，可以根據詳細環境用1-4個位元組來表現一個字元。比如英筆墨符這些本來就可以用ASCII碼錶現的字元用UTF-8表現時就只必要一個位元組的空間，和ASCII是一樣的。對付多位元組（n個位元組）的字元，第一個位元組的前n為都設為1，第n+1位設為0，背面位元組的前兩位都設為10。剩下的二進位位全部用該字元的unicode碼添補。

中文好unicode0101100101111101編碼規矩1110xxxx10xxxxxx10xxxxxx--------------------------utf-8111001011010010110111101--------------------------16進位utf-8e5a5bd

PYTHON字元編碼如今總算把理論述完了。再來說說Python中的編碼題目。Python的誕生時間比Unicode要早很多，Python的默認編碼是ASCII

importsyssys.getdefaultencoding()"ascii"以是在Python源代碼文件中要是不表現地指定編碼的話，將出現語法錯誤

#test.pyprint"你好"上面是test.py腳本，運行pythontest.py就會包如下錯誤：

為了在源代碼中支持非ASCII字元，必須在源文件的第一行大概第二行表現地指定編碼格局：

#coding=utf-8大概是：

#!/usr/bin/python#-*-coding:utf-8-*-在python中和字元串相干的數據範例,分別是str、unicode兩種，他們都是basestring的子類，可見str與unicode是兩種差別範例的字元串東西。

basestring//strunicode對付同一個漢字「好」，用str表現時，它對應的便是utf-8編碼的"xe5xa5xbd"，而用unicode表現時，他對應的標記便是u"u597d"，與u"好"是等同的。必要補充一點的是，str範例的字元其詳細的編碼格局是UTF-8還是GBK，還是其他格局，根據操縱體系相干。比如在Windows體系中，cmd下令行中表現的：

#windows終端a="好"type(a)type"str"a"xbaxc3"而在Linux體系的下令行中表現的是：

#linux終端a="好"type(a)type"str"a"xe5xa5xbd"b=u"好"type(b)type"unicode"bu"u597d"不論是Python3x、Java還是其他編程語言，Unicode編碼都成為語言的默認編碼格局，而數據末了生存到介質中的時間，差別的介質可有效差別的方法，有些人喜好用UTF-8，有些人喜好用GBK，這都無所謂，只要平台同一的編碼範例，詳細怎麼實現並不體貼。

str與unicode的轉換那麼在Python中str和unicode之間是怎樣轉換的呢？這兩種範例的字元串範例之間的轉換便是靠這兩個要領decode和encode。

#從str範例轉換到unicodes.decode(encoding)=====type"str"totype"unicode"#從unicode轉換到stru.encode(encoding)=====type"unicode"totype"str"c=b.encode("utf-8")type(c)type"str"c"xe5xa5xbd"d=c.decode("utf-8")type(d)type"unicode"du"u597d"這個"xe5xa5xbd"便是unicodeu"好"通過函數encode編碼得到的UTF-8編碼的str範例的字元串。反之亦然，str範例的c通過函數decode解碼成unicode字元串d。

str(s)與unicode(s)str(s)和unicode(s)是兩個工廠要領，分別返回str字元串東西和unicode字元串東西，str(s)是s.encode(『ascii』)的簡寫。實行：

s3=u"你好"s3u"u4f60u597d"str(s3)Traceback(mostrecentcalllast):File"stdin",line1,inmoduleUnicodeEncodeError:"ascii"codeccan"tencodecharactersinposition0-1:ordinalnotinrange(128)上面s3是unicode範例的字元串，str(s3)相稱於是實行s3.encode(『ascii』)由於「你好」兩個漢字不克不及用ascii碼來表現，以是就報錯了，指定精確的編碼：s3.encode(『gbk』)大概s3.encode("utf-8")就不會出現這個題目了。雷同的unicode有同樣的錯誤：

s4="你好"unicode(s4)Traceback(mostrecentcalllast):File"stdin",line1,inmoduleUnicodeDecodeError:"ascii"codeccan"tdecodebyte0xc4inposition0:ordinalnotinrange(128)unicode(s4)等效於s4.decode(『ascii』)，因此要精確的轉換就要精確指定其編碼s4.decode(『gbk』)大概s4.decode("utf-8")。

亂碼全部出現亂碼的緣故起因都可以歸結為字元顛末差別編碼解碼在編碼的進程中利用的編碼格局不同等，比如：

#encoding:utf-8a="好"a"xe5xa5xbd"b=a.decode("utf-8")bu"u597d"c=b.encode("gbk")c"xbaxc3"printc??utf-8編碼的字元『好』佔用3個位元組，解碼成Unicode後，要是再用gbk來解碼後，只有2個位元組的長度了，末了出現了亂碼的題目，因此防備亂碼的最好方法便是始終對峙利用同一種編碼格局對字元舉行編碼和解碼操縱。

其他本領對付如unicode情勢的字元串（str範例)：

s="idpythonu003d215903184u0026indexu003d0u0026stu003d52u0026sid』轉換成真正的unicode必要利用：

s.decode("unicode-escape")測試：

s="idu003d215903184u0026indexu003d0u0026stu003d52u0026sidu003d95000u0026i"print(type(s))type"str"s=s.decode("unicode-escape")su"id=215903184index=0st=52sid=95000i"print(type(s))type"unicode"以上代碼和見解都是基於Python2.x。

參考：