自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

帶你深入理解Python字符編碼

開發(fā) 后端
不論你是有著多年經(jīng)驗(yàn)的 Python 老司機(jī)還是剛?cè)腴T Python 不久,你一定遇到過UnicodeEncodeError、UnicodeDecodeError 錯誤,每當(dāng)遇到錯誤我們就拿著 encode、decode 函數(shù)翻來覆去的轉(zhuǎn)換,有時(shí)試著試著問題就解決了,有時(shí)候怎么試都沒轍,只有借用 Google 大神幫忙。

不論你是有著多年經(jīng)驗(yàn)的 Python 老司機(jī)還是剛?cè)腴T Python 不久,你一定遇到過UnicodeEncodeError、UnicodeDecodeError 錯誤,每當(dāng)遇到錯誤我們就拿著 encode、decode 函數(shù)翻來覆去的轉(zhuǎn)換,有時(shí)試著試著問題就解決了,有時(shí)候怎么試都沒轍,只有借用 Google 大神幫忙,但似乎很少去關(guān)心問題的本質(zhì)是什么,下次遇到類似的問題重蹈覆轍,那么你有沒有想過一次性徹底把 Python 字符編碼給搞懂呢?

完全理解字符編碼 與 Python 的淵源前,我們有必要把一些基礎(chǔ)概念弄清楚,雖然有些概念我們每天都在接觸甚至在使用它,但并不一定真正理解它。比如:字節(jié)、字符、字符集、字符碼、字符編碼。

字節(jié)

字節(jié)(Byte)是計(jì)算機(jī)中數(shù)據(jù)存儲的基本單元,一字節(jié)等于一個8位的比特,計(jì)算機(jī)中的所有數(shù)據(jù),不論是保存在磁盤文件上的還是網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)(文字、圖片、視頻、音頻文件)都是由字節(jié)組成的。

字符

你正在閱讀的這篇文章就是由很多個字符(Character)構(gòu)成的,字符一個信息單位,它是各種文字和符號的統(tǒng)稱,比如一個英文字母是一個字符,一個漢字是一個字符,一個標(biāo)點(diǎn)符號也是一個字符。

字符集

字符集(Character Set)就是某個范圍內(nèi)字符的集合,不同的字符集規(guī)定了字符的個數(shù),比如 ASCII 字符集總共有128個字符,包含了英文字母、阿拉伯?dāng)?shù)字、標(biāo)點(diǎn)符號和控制符。而 GB2312 字符集定義了7445個字符,包含了絕大部分漢字字符。

字符碼

字符碼(Code Point)指的是字符集中每個字符的數(shù)字編號,例如 ASCII 字符集用 0-127 連續(xù)的128個數(shù)字分別表示128個字符,例如 "A" 的字符碼編號就是65。

字符編碼

字符編碼(Character Encoding)是將字符集中的字符碼映射為字節(jié)流的一種具體實(shí)現(xiàn)方案,常見的字符編碼有 ASCII 編碼、UTF-8 編碼、GBK 編碼等。某種意義上來說,字符集與字符編碼有種對應(yīng)關(guān)系,例如 ASCII 字符集對應(yīng) 有 ASCII 編碼。ASCII 字符編碼規(guī)定使用單字節(jié)中低位的7個比特去編碼所有的字符。例如"A" 的編號是65,用單字節(jié)表示就是0×41,因此寫入存儲設(shè)備的時(shí)候就是b'01000001'。

編碼、解碼

編碼的過程是將字符轉(zhuǎn)換成字節(jié)流,解碼的過程是將字節(jié)流解析為字符。


理解了這些基本的術(shù)語概念后,我們就可以開始討論計(jì)算機(jī)的字符編碼的演進(jìn)過程了。

從 ASCII 碼說起

說到字符編碼,要從計(jì)算機(jī)的誕生開始講起,計(jì)算機(jī)發(fā)明于美國,在英語世界里,常用字符非常有限,26個字母(大小寫)、10個數(shù)字、標(biāo)點(diǎn)符號、控制符,這些字符在計(jì)算機(jī)中用一個字節(jié)的存儲空間來表示綽綽有余,因?yàn)橐粋€字節(jié)相當(dāng)于8個比特位,8個比特位可以表示256個符號。于是美國國家標(biāo)準(zhǔn)協(xié)會ANSI制定了一套字符編碼的標(biāo)準(zhǔn)叫 ASCII(American Standard Code for Information Interchange),每個字符都對應(yīng)唯一的一個數(shù)字,比如字符 "A" 對應(yīng)數(shù)字是65,"B" 對應(yīng) 66,以此類推。最早 ASCII 只定義了128個字符編碼,包括96個文字和32個控制符號,一共128個字符只需要一個字節(jié)的7位就能表示所有的字符,因此 ASCII 只使用了一個字節(jié)的后7位,剩下最高位1比特被用作一些通訊系統(tǒng)的奇偶校驗(yàn)。下圖就是 ASCII 碼字符編碼的十進(jìn)制、二進(jìn)制和字符的對應(yīng)關(guān)系表

ascii

擴(kuò)展的 ASCII:EASCII(ISO/8859-1)

然而計(jì)算機(jī)慢慢地普及到其他西歐地區(qū)時(shí),發(fā)現(xiàn)還有很多西歐字符是 ASCII 字符集中沒有的,顯然 ASCII 已經(jīng)沒法滿足人們的需求了,好在 ASCII 字符只用了字節(jié)的7位 0×00~0x7F 共128個字符,于是他們在 ASCII 的基礎(chǔ)上把原來的7位擴(kuò)充到8位,把0×80-0xFF這后面的128個數(shù)字利用起來,叫 EASCII ,它完全兼容ASCII,擴(kuò)展出來的符號包括表格符號、計(jì)算符號、希臘字母和特殊的拉丁符號。然而 EASCII 時(shí)代是一個混亂的時(shí)代,各個廠家都有自己的想法,大家沒有統(tǒng)一標(biāo)準(zhǔn),他們各自把最高位按照自己的標(biāo)準(zhǔn)實(shí)現(xiàn)了自己的一套字符編碼標(biāo)準(zhǔn),比較著名的就有 CP437, CP437 是 始祖IBM PC、MS-DOS使用的字符編碼,如下圖:

 

眾多的 ASCII 擴(kuò)充字符集之間互不兼容,這樣導(dǎo)致人們無法正常交流,例如200在CP437字符集表示的字符是 È ,在 ISO/8859-1 字符集里面顯示的就是 ╚,于是國際標(biāo)準(zhǔn)化組織(ISO)及國際電工委員會(IEC)聯(lián)合制定的一系列8位字符集的標(biāo)準(zhǔn)ISO/8859-1(Latin-1),它繼承了 CP437 字符編碼的128-159之間的字符,所以它是從160開始定義的,ISO-8859-1在 CP437 的基礎(chǔ)上重新定義了 160~255之間的字符。
iso8859-1

多字節(jié)字符編碼 GBK

ASCII 字符編碼是單字節(jié)編碼,計(jì)算機(jī)進(jìn)入中國后面臨的一個問題是如何處理漢字,對于拉丁語系國家來說通過擴(kuò)展最高位,單字節(jié)表示所有的字符已經(jīng)綽綽有余,但是對于亞洲國家來說一個字節(jié)就顯得捉襟見肘了。于是中國人自己弄了一套叫 GB2312的雙字節(jié)字符編碼,又稱GB0,1981 由中國國家標(biāo)準(zhǔn)總局發(fā)布。GB2312 編碼共收錄了6763個漢字,同時(shí)他還兼容 ASCII,GB 2312的出現(xiàn),基本滿足了漢字的計(jì)算機(jī)處理需要,它所收錄的漢字已經(jīng)覆蓋中國大陸99.75%的使用頻率,不過 GB2312 還是不能100%滿足中國漢字的需求,對一些罕見的字和繁體字 GB2312 沒法處理,后來就在GB2312的基礎(chǔ)上創(chuàng)建了一種叫 GBK 的編碼,GBK 不僅收錄了27484個漢字,同時(shí)還收錄了藏文、蒙文、維吾爾文等主要的少數(shù)民族文字。同樣 GBK 也是兼容 ASCII 編碼的,對于英文字符用1個字節(jié)來表示,漢字用兩個字節(jié)來標(biāo)識。

Unicode 的問世

GBK僅僅只是解決了我們自己的問題,但是計(jì)算機(jī)不止是美國人和中國人用啊,還有歐洲、亞洲其他國家的文字諸如日文、韓文全世界各地的文字加起來估計(jì)也有好幾十萬,這已經(jīng)大大超出了ASCII 碼甚至GBK 所能表示的范圍了,雖然各個國家可以制定自己的編碼方案,但是數(shù)據(jù)在不同國家傳輸就會出現(xiàn)各種各樣的亂碼問題。如果只用一種字符編碼就能表示地球甚至火星上任何一個字符時(shí),問題就迎刃而解了。是它,是它,就是它,我們的小英雄,統(tǒng)一聯(lián)盟國際組織提出了Unicode 編碼,Unicode 的學(xué)名是"Universal Multiple-Octet Coded Character Set",簡稱為UCS。它為世界上每一種語言的每一個字符定義了一個唯一的字符碼,Unicode 標(biāo)準(zhǔn)使用十六進(jìn)制數(shù)字表示,數(shù)字前面加上前綴 U+,比如字母『A』的Unicode編碼是 U+0041,漢字『中』的Unicode 編碼是U+4E2D

Unicode有兩種格式:UCS-2和UCS-4。UCS-2就是用兩個字節(jié)編碼,一共16個比特位,這樣理論上最多可以表示65536個字符,不過要表示全世界所有的字符顯示65536個數(shù)字還遠(yuǎn)遠(yuǎn)不過,因?yàn)楣鉂h字就有近10萬個,因此Unicode4.0規(guī)范定義了一組附加的字符編碼,UCS-4就是用4個字節(jié)(實(shí)際上只用了31位,最高位必須為0)。理論上完全可以涵蓋一切語言所用的符號。

Unicode 的局限

但是 Unicode 有一定的局限性,一個 Unicode 字符在網(wǎng)絡(luò)上傳輸或者最終存儲起來的時(shí)候,并不見得每個字符都需要兩個字節(jié),比如字符“A“,用一個字節(jié)就可以表示的字符,偏偏還要用兩個字節(jié),顯然太浪費(fèi)空間了。

第二問題是,一個 Unicode 字符保存到計(jì)算機(jī)里面時(shí)就是一串01數(shù)字,那么計(jì)算機(jī)怎么知道一個2字節(jié)的Unicode字符是表示一個2字節(jié)的字符呢,例如“漢”字的 Unicode 編碼是 U+6C49,我可以用4個ascii數(shù)字來傳輸、保存這個字符;也可以用utf-8編碼的3個連續(xù)的字節(jié)E6 B1 89來表示它。關(guān)鍵在于通信雙方都要認(rèn)可。因此Unicode編碼有不同的實(shí)現(xiàn)方式,比如:UTF-8、UTF-16等等。Unicode就像英語一樣,做為國與國之間交流世界通用的標(biāo)準(zhǔn),每個國家有自己的語言,他們把標(biāo)準(zhǔn)的英文文檔翻譯成自己國家的文字,這是實(shí)現(xiàn)方式,就像utf-8。

具體實(shí)現(xiàn):UTF-8

UTF-8(Unicode Transformation Format)作為 Unicode 的一種實(shí)現(xiàn)方式,廣泛應(yīng)用于互聯(lián)網(wǎng),它是一種變長的字符編碼,可以根據(jù)具體情況用1-4個字節(jié)來表示一個字符。比如英文字符這些原本就可以用 ASCII 碼表示的字符用UTF-8表示時(shí)就只需要一個字節(jié)的空間,和 ASCII 是一樣的。對于多字節(jié)(n個字節(jié))的字符,第一個字節(jié)的前n為都設(shè)為1,第n+1位設(shè)為0,后面字節(jié)的前兩位都設(shè)為10。剩下的二進(jìn)制位全部用該字符的unicode碼填充。

code

以『好』為例,『好』對應(yīng)的 Unicode 是597D,對應(yīng)的區(qū)間是 0000 0800--0000 FFFF,因此它用 UTF-8 表示時(shí)需要用3個字節(jié)來存儲,597D用二進(jìn)制表示是: 0101100101111101,填充到 1110xxxx 10xxxxxx 10xxxxxx 得到 11100101 10100101 10111101,轉(zhuǎn)換成16進(jìn)制是 e5a5bd,因此『好』的 Unicode 碼 U+597D 對應(yīng)的 UTF-8 編碼是 "E5A5BD"。你可以用 Python 代碼來驗(yàn)證:

  1. >>> a = u"好" 
  2. >>> a 
  3. u'\u597d' 
  4. >>> b = a.encode('utf-8'
  5. >>> len(b) 
  6. >>> b 
  7. '\xe5\xa5\xbd' 

現(xiàn)在總算把理論說完了。再來說說 Python 中的編碼問題。Python 的誕生時(shí)間比 Unicode 要早很多,Python2 的默認(rèn)編碼是ASCII,正因?yàn)槿绱?,才?dǎo)致很多的編碼問題。

  1. >>> import sys 
  2. >>> sys.getdefaultencoding() 
  3. 'ascii' 

所以在 Python2 中,源代碼文件必須顯示地指定編碼類型,否則但凡代碼中出現(xiàn)有中文就會報(bào)語法錯誤

  1. # coding=utf-8 
  2. 或者是: 
  3. # -*- coding: utf-8 -*- 

Python2 字符類型

在 python2 中和字符串相關(guān)的數(shù)據(jù)類型有 str 和 unicode 兩種類型,它們繼承自 basestring,而 str 類型的字符串的編碼格式可以是 ascii、utf-8、gbk等任何一種類型。

python-str.png

對于漢字『好』,用 str 表示時(shí),它對應(yīng)的 utf-8 編碼 是'\xe5\xa5\xbd',對應(yīng)的 gbk 編碼是 '\xba\xc3',而用 unicode 表示時(shí),他對應(yīng)的符號就是u'\u597d',與u"好" 是等同的。

str 與 unicode 的轉(zhuǎn)換

在 Python 中 str 和 unicode 之間是如何轉(zhuǎn)換的呢?這兩種類型的字符串之間的轉(zhuǎn)換就是靠decode 和 encode 這兩個函數(shù)。encode 負(fù)責(zé)將unicode 編碼成指定的字符編碼,用于存儲到磁盤或傳輸?shù)骄W(wǎng)絡(luò)中。而 decode 方法是根據(jù)指定的編碼方式解碼后在應(yīng)用程序中使用。

  1.  #從unicode轉(zhuǎn)換到str用 encode 
  2.  
  3. >>> b  = u'好' 
  4. >>> c = b.encode('utf-8'
  5. >>> type(c) 
  6. <type 'str'
  7. >>> c 
  8. '\xe5\xa5\xbd' 
  9.  
  10. #從str類型轉(zhuǎn)換到unicode用decode 
  11.  
  12. >>> d = c.decode('utf-8'
  13. >>> type(d) 
  14. <type 'unicode'
  15. >>> d 
  16. u'\u597d' 

UnicodeXXXError 錯誤的原因

在字符編碼轉(zhuǎn)換操作時(shí),遇到最多的問題就是 UnicodeEncodeError 和 UnicodeDecodeError 錯誤了,這些錯誤的根本原因在于 Python2 默認(rèn)是使用 ascii 編碼進(jìn)行 decode 和 encode 操作,例如:

case 1

  1. >>> s = '你好' 
  2. >>> s.decode() 
  3. Traceback (most recent call last): 
  4.   File "<stdin>", line 1, in <module> 
  5. UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128) 

當(dāng)把 s 轉(zhuǎn)換成 unicode 類型的字符串時(shí),decode 方法默認(rèn)使用 ascii 編碼進(jìn)行解碼,而 ascii 字符集中根本就沒有中文字符『你好』,所以就出現(xiàn)了 UnicodeDecodeError,正確的方式是顯示地指定 UTF-8 字符編碼。

  1. >>> s.decode('utf-8'
  2. u'\u4f60\u597d' 

同樣地道理,對于 encode 操作,把 unicode字符串轉(zhuǎn)換成 str類型的字符串時(shí),默認(rèn)也是使用 ascii 編碼進(jìn)行編碼轉(zhuǎn)換的,而 ascii 字符集找不到中文字符『你好』,于是就出現(xiàn)了UnicodeEncodeError 錯誤。

  1. >>> a = u'你好' 
  2. >>> a.encode() 
  3. Traceback (most recent call last): 
  4.   File "<stdin>", line 1, in <module> 
  5. UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) 

case 2

str 類型與 unicode 類型的字符串混合使用時(shí),str 類型的字符串會隱式地將 str 轉(zhuǎn)換成 unicode字符串,如果 str字符串是中文字符,那么就會出現(xiàn)UnicodeDecodeError 錯誤,因?yàn)?python2 默認(rèn)會使用 ascii 編碼來進(jìn)行 decode 操作。

  1. >>> s = '你好'  # str類型 
  2. >>> y = u'python'  # unicode類型 
  3. >>> s + y    # 隱式轉(zhuǎn)換,即 s.decode('ascii') + u 
  4. Traceback (most recent call last): 
  5.   File "<stdin>", line 1, in <module> 
  6. UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128) 

正確地方式是顯示地指定 UTF-8 字符編碼進(jìn)行解碼

  1. >>> s.decode('utf-8') +y 
  2. u'\u4f60\u597dpython' 

亂碼

所有出現(xiàn)亂碼的原因都可以歸結(jié)為字符經(jīng)過不同編碼解碼在編碼的過程中使用的編碼格式不一致,比如:

  1. # encoding: utf-8 
  2.  
  3. >>> a='好' 
  4. >>> a 
  5. '\xe5\xa5\xbd' 
  6. >>> b=a.decode("utf-8"
  7. >>> b 
  8. u'\u597d' 
  9. >>> c=b.encode("gbk"
  10. >>> c 
  11. '\xba\xc3' 
  12. >>> print c 
  13. �� 

utf-8編碼的字符‘好’占用3個字節(jié),解碼成Unicode后,如果再用gbk來解碼后,只有2個字節(jié)的長度了,最后出現(xiàn)了亂碼的問題,因此防止亂碼的最好方式就是始終堅(jiān)持使用同一種編碼格式對字符進(jìn)行編碼和解碼操作。

decode-encode 

責(zé)任編輯:龐桂玉 來源: 51CTO博客
相關(guān)推薦

2020-11-27 08:02:41

Promise

2019-10-11 08:41:35

JVM虛擬機(jī)語言

2017-11-20 11:05:23

數(shù)據(jù)庫MongoDB索引

2025-02-11 00:00:10

Base64編碼二進(jìn)制

2018-11-30 10:00:53

Python字符串編程語言

2021-04-25 10:45:59

Docker架構(gòu)Job

2020-03-18 13:40:03

Spring事數(shù)據(jù)庫代碼

2021-09-08 17:42:45

JVM內(nèi)存模型

2010-06-01 15:25:27

JavaCLASSPATH

2016-12-08 15:36:59

HashMap數(shù)據(jù)結(jié)構(gòu)hash函數(shù)

2020-07-21 08:26:08

SpringSecurity過濾器

2009-11-18 12:38:04

PHP字符串函數(shù)

2021-01-06 14:15:42

線程池Java代碼

2019-07-24 08:49:36

Docker容器鏡像

2024-03-04 15:05:37

2013-09-22 14:57:19

AtWood

2009-09-25 09:14:35

Hibernate日志

2023-10-19 11:12:15

Netty代碼

2021-02-17 11:25:33

前端JavaScriptthis

2020-09-23 10:00:26

Redis數(shù)據(jù)庫命令
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號