編解碼器基類(lèi)?

codecs 模塊定義了一系列基類(lèi)用來(lái)定義配合編解碼器對象進(jìn)行工作的接口，并且也可用作定制編解碼器實(shí)現的基礎。

每種編解碼器必須定義四個(gè)接口以便用作 Python 中的編解碼器：無(wú)狀態(tài)編碼器、無(wú)狀態(tài)解碼器、流讀取器和流寫(xiě)入器。 流讀取器和寫(xiě)入器通常會(huì )重用無(wú)狀態(tài)編碼器/解碼器來(lái)實(shí)現文件協(xié)議。 編解碼器作者還需要定義編解碼器將如何處理編碼和解碼錯誤。

>>> 'German ?, ?'.encode(encoding='ascii', errors='backslashreplace')
b'German \\xdf, \\u266c'
>>> 'German ?, ?'.encode(encoding='ascii', errors='xmlcharrefreplace')
b'German ß, ♬'

編碼格式與 Unicode?

Strings are stored internally as sequences of code points in range U+0000--U+10FFFF. (See PEP 393 for more details about the implementation.) Once a string object is used outside of CPU and memory, endianness and how these arrays are stored as bytes become an issue. As with other codecs, serialising a string into a sequence of bytes is known as encoding, and recreating the string from the sequence of bytes is known as decoding. There are a variety of different text serialisation codecs, which are collectivity referred to as text encodings.

最簡(jiǎn)單的文本編碼格式 (稱(chēng)為 'latin-1' 或 'iso-8859-1') 將碼位 0--255 映射為字節值 0x0--0xff，這意味著(zhù)包含 U+00FF 以上碼位的字符串對象無(wú)法使用此編解碼器進(jìn)行編碼。 這樣做將引發(fā) UnicodeEncodeError，其形式類(lèi)似下面這樣（不過(guò)詳細的錯誤信息可能會(huì )有所不同）: UnicodeEncodeError: 'latin-1' codec can't encode character '\u1234' in position 3: ordinal not in range(256)。

還有另外一組編碼格式（所謂的字符映射編碼）會(huì )選擇全部 Unicode 碼位的不同子集并設定如何將這些碼位映射為字節值 0x0--0xff。 要查看這是如何實(shí)現的，只需簡(jiǎn)單地打開(kāi)相應源碼例如 encodings/cp1252.py (這是一個(gè)主要在 Windows 上使用的編碼格式)。 其中會(huì )有一個(gè)包含 256 個(gè)字符的字符串常量，指明每個(gè)字符所映射的字節值。

All of these encodings can only encode 256 of the 1114112 code points defined in Unicode. A simple and straightforward way that can store each Unicode code point, is to store each code point as four consecutive bytes. There are two possibilities: store the bytes in big endian or in little endian order. These two encodings are called UTF-32-BE and UTF-32-LE respectively. Their disadvantage is that if e.g. you use UTF-32-BE on a little endian machine you will always have to swap bytes on encoding and decoding. UTF-32 avoids this problem: bytes will always be in natural endianness. When these bytes are read by a CPU with a different endianness, then bytes have to be swapped though. To be able to detect the endianness of a UTF-16 or UTF-32 byte sequence, there's the so called BOM ("Byte Order Mark"). This is the Unicode character U+FEFF. This character can be prepended to every UTF-16 or UTF-32 byte sequence. The byte swapped version of this character (0xFFFE) is an illegal character that may not appear in a Unicode text. So when the first character in a UTF-16 or UTF-32 byte sequence appears to be a U+FFFE the bytes have to be swapped on decoding. Unfortunately the character U+FEFF had a second purpose as a ZERO WIDTH NO-BREAK SPACE: a character that has no width and doesn't allow a word to be split. It can e.g. be used to give hints to a ligature algorithm. With Unicode 4.0 using U+FEFF as a ZERO WIDTH NO-BREAK SPACE has been deprecated (with U+2060 (WORD JOINER) assuming this role). Nevertheless Unicode software still must be able to handle U+FEFF in both roles: as a BOM it's a device to determine the storage layout of the encoded bytes, and vanishes once the byte sequence has been decoded into a string; as a ZERO WIDTH NO-BREAK SPACE it's a normal character that will be decoded like any other.

There's another encoding that is able to encode the full range of Unicode characters: UTF-8. UTF-8 is an 8-bit encoding, which means there are no issues with byte order in UTF-8. Each byte in a UTF-8 byte sequence consists of two parts: marker bits (the most significant bits) and payload bits. The marker bits are a sequence of zero to four 1 bits followed by a 0 bit. Unicode characters are encoded like this (with x being payload bits, which when concatenated give the Unicode character):

Unicode 字符最不重要的一個(gè)位就是最右側的二進(jìn)制位 x。

由于 UTF-8 是一種 8 位編碼格式，因此 BOM 是不必要的，并且已編碼字符串中的任何 U+FEFF 字符（即使是作為第一個(gè)字符）都會(huì )被視為是 ZERO WIDTH NO-BREAK SPACE。

Without external information it's impossible to reliably determine which encoding was used for encoding a string. Each charmap encoding can decode any random byte sequence. However that's not possible with UTF-8, as UTF-8 byte sequences have a structure that doesn't allow arbitrary byte sequences. To increase the reliability with which a UTF-8 encoding can be detected, Microsoft invented a variant of UTF-8 (that Python calls "utf-8-sig") for its Notepad program: Before any of the Unicode characters is written to the file, a UTF-8 encoded BOM (which looks like this as a byte sequence: 0xef, 0xbb, 0xbf) is written. As it's rather improbable that any charmap encoded file starts with these byte values (which would e.g. map to

LATIN SMALL LETTER I WITH DIAERESIS

RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

INVERTED QUESTION MARK

對于 iso-8859-1 編碼格式來(lái)說(shuō)），這提升了根據字節序列來(lái)正確猜測 utf-8-sig 編碼格式的成功率。 所以在這里 BOM 的作用并不是幫助確定生成字節序列所使用的字節順序，而是作為幫助猜測編碼格式的記號。 在進(jìn)行編碼時(shí) utf-8-sig 編解碼器將把 0xef, 0xbb, 0xbf 作為頭三個(gè)字節寫(xiě)入文件。 在進(jìn)行解碼時(shí) utf-8-sig 將跳過(guò)這三個(gè)字節，如果它們作為文件的頭三個(gè)字節出現的話(huà)。 在 UTF-8 中并不推薦使用 BOM，通常應當避免它們的出現。

標準編碼?

Python 自帶了許多內置的編解碼器，它們的實(shí)現或者是通過(guò) C 函數，或者是通過(guò)映射表。 以下表格是按名稱(chēng)排序的編解碼器列表，并提供了一些常見(jiàn)別名以及編碼格式通常針對的語(yǔ)言。 別名和語(yǔ)言列表都不是詳盡無(wú)遺的。 請注意僅有大小寫(xiě)區別或使用連字符替代下劃線(xiàn)的拼寫(xiě)形式也都是有效的別名；因此，'utf-8' 是 'utf_8' 編解碼器的有效別名。

許多字符集都支持相同的語(yǔ)言。 它們在個(gè)別字符（例如是否支持 EURO SIGN 等）以及給字符所分配的碼位方面存在差異。 特別是對于歐洲語(yǔ)言來(lái)說(shuō)，通常存在以下幾種變體：

• 某個(gè) ISO 8859 編碼集

• 某個(gè) Microsoft Windows 編碼頁(yè)，通常是派生自某個(gè) 8859 編碼集，但會(huì )用附加的圖形字符來(lái)替換控制字符。

• 某個(gè) IBM EBCDIC 編碼頁(yè)

• 某個(gè) IBM PC 編碼頁(yè)，通常會(huì )兼容 ASCII

Python 專(zhuān)屬的編碼格式?

有一些預定義編解碼器是 Python 專(zhuān)屬的，因此它們在 Python 之外沒(méi)有意義。 這些編解碼器按其所預期的輸入和輸出類(lèi)型在下表中列出（請注意雖然文本編碼是編解碼器最常見(jiàn)的使用場(chǎng)景，但下層的編解碼器架構支持任意數據轉換而不僅是文本編碼）。 對于非對稱(chēng)編解碼器，該列描述的含義是編碼方向。

encodings.idna --- 應用程序中的國際化域名?

此模塊實(shí)現了 RFC 3490 (應用程序中的國際化域名) 和 RFC 3492 (Nameprep: 用于國際化域名 (IDN) 的 Stringprep 配置文件)。 它是在 punycode 編碼格式和 stringprep 的基礎上構建的。

If you need the IDNA 2008 standard from RFC 5891 and RFC 5895, use the third-party idna module.

這些 RFC 共同定義了一個(gè)在域名中支持非 ASCII 字符的協(xié)議。 一個(gè)包含非 ASCII 字符的域名 (例如 www.Alliancefran?aise.nu) 會(huì )被轉換為兼容 ASCII 的編碼格式 (簡(jiǎn)稱(chēng) ACE，例如 www.xn--alliancefranaise-npb.nu)。 隨后此域名的 ACE 形式可以用于所有由于特定協(xié)議而不允許使用任意字符的場(chǎng)合，例如 DNS 查詢(xún)，HTTP Host 字段等等。 此轉換是在應用中進(jìn)行的；如有可能將對用戶(hù)可見(jiàn)：應用應當透明地將 Unicode 域名標簽轉換為線(xiàn)上的 IDNA，并在 ACE 標簽被呈現給用戶(hù)之前將其轉換回 Unicode。

Python 以多種方式支持這種轉換: idna 編解碼器執行 Unicode 和 ACE 之間的轉換，基于在 section 3.1 of RFC 3490 中定義的分隔字符將輸入字符串拆分為標簽，再根據需要將每個(gè)標簽轉換為 ACE，相反地又會(huì )基于 . 分隔符將輸入字節串拆分為標簽，再將找到的任何 ACE 標簽轉換為 Unicode。 此外，socket 模塊可透明地將 Unicode 主機名轉換為 ACE，以便應用在將它們傳給 socket 模塊時(shí)無(wú)須自行轉換主機名。 除此之外，許多包含以主機名作為函數參數的模塊例如 http.client 和 ftplib 都接受 Unicode 主機名（并且 http.client 也會(huì )在 Host 字段中透明地發(fā)送 IDNA 主機名，如果它需要發(fā)送該字段的話(huà)）。

當從線(xiàn)路接收主機名時(shí)（例如反向名稱(chēng)查找），到 Unicode 的轉換不會(huì )自動(dòng)被執行：希望向用戶(hù)提供此種主機名的應用應當將它們解碼為 Unicode。

encodings.idna 模塊還實(shí)現了 nameprep 過(guò)程，該過(guò)程會(huì )對主機名執行特定的規范化操作，以實(shí)現國際域名的大小寫(xiě)不敏感特性與合并相似的字符。 如果有需要可以直接使用 nameprep 函數。

encodings.idna.nameprep(label)?

返回 label 經(jīng)過(guò)名稱(chēng)處理操作的版本。 該實(shí)現目前基于查詢(xún)字符串，因此 AllowUnassigned 為真值。

encodings.idna.ToASCII(label)?

將標簽轉換為 ASCII，規則定義見(jiàn) RFC 3490。 UseSTD3ASCIIRules 預設為假值。

encodings.idna.ToUnicode(label)?

將標簽轉換為 Unicode，規則定義見(jiàn) RFC 3490。

encodings.mbcs --- Windows ANSI代碼頁(yè)?

此模塊實(shí)現ANSI代碼頁(yè)（CP_ACP）。

Availability: 僅Windows可用

encodings.utf_8_sig --- 帶BOM簽名的UTF-8編解碼器?

此模塊實(shí)現了 UTF-8 編解碼器的一個(gè)變種：在編碼時(shí)將把 UTF-8 已編碼 BOM 添加到 UTF-8 編碼字節數據的開(kāi)頭。 對于有狀態(tài)編碼器此操作只執行一次（當首次寫(xiě)入字節流時(shí)）。 在解碼時(shí)將跳過(guò)數據開(kāi)頭作為可選項的 UTF-8 已編碼 BOM。