codecs --- 編解碼器注冊和相關基類?

編解碼器基類?

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

每種編解碼器必須定義四個接口以便用作 Python 中的編解碼器：無狀態(tài)編碼器、無狀態(tài)解碼器、流讀取器和流寫入器。 流讀取器和寫入器通常會重用無狀態(tài)編碼器/解碼器來實現(xiàn)文件協(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.

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

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

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 字符最不重要的一個位就是最右側的二進制位 x。

由于 UTF-8 是一種 8 位編碼格式，因此 BOM 是不必要的，并且已編碼字符串中的任何 U+FEFF 字符（即使是作為第一個字符）都會被視為是 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 編碼格式來說），這提升了根據(jù)字節(jié)序列來正確猜測 utf-8-sig 編碼格式的成功率。 所以在這里 BOM 的作用并不是幫助確定生成字節(jié)序列所使用的字節(jié)順序，而是作為幫助猜測編碼格式的記號。 在進行編碼時 utf-8-sig 編解碼器將把 0xef, 0xbb, 0xbf 作為頭三個字節(jié)寫入文件。 在進行解碼時 utf-8-sig 將跳過這三個字節(jié)，如果它們作為文件的頭三個字節(jié)出現(xiàn)的話。 在 UTF-8 中并不推薦使用 BOM，通常應當避免它們的出現(xiàn)。

標準編碼?

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

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

• 某個 ISO 8859 編碼集

• 某個 Microsoft Windows 編碼頁，通常是派生自某個 8859 編碼集，但會用附加的圖形字符來替換控制字符。

• 某個 IBM EBCDIC 編碼頁

• 某個 IBM PC 編碼頁，通常會兼容 ASCII

Python 專屬的編碼格式?

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

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

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

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

當從線路接收主機名時（例如反向名稱查找），到 Unicode 的轉換不會自動被執(zhí)行：希望向用戶提供此種主機名的應用應當將它們解碼為 Unicode。

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

encodings.idna.nameprep(label)?

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

encodings.idna.ToASCII(label)?

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

encodings.idna.ToUnicode(label)?

將標簽轉換為 Unicode，規(guī)則定義見 RFC 3490。

encodings.mbcs --- Windows ANSI代碼頁?

此模塊實現(xiàn)ANSI代碼頁（CP_ACP）。

Availability: 僅Windows可用

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

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