codecs --- 編解碼器注冊(cè)和相關(guān)基類?

編解碼器基類?

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

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

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

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

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

標(biāo)準(zhǔn)編碼?

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

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

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

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

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

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

Python 專屬的編碼格式?

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

encodings.idna --- 應(yīng)用程序中的國(guó)際化域名?

此模塊實(shí)現(xiàn)了 RFC 3490 (應(yīng)用程序中的國(guó)際化域名) 和 RFC 3492 (Nameprep: 用于國(guó)際化域名 (IDN) 的 Stringprep 配置文件)。 它是在 punycode 編碼格式和 stringprep 的基礎(chǔ)上構(gòu)建的。

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ì)被轉(zhuǎn)換為兼容 ASCII 的編碼格式 (簡(jiǎn)稱 ACE，例如 www.xn--alliancefranaise-npb.nu)。 隨后此域名的 ACE 形式可以用于所有由于特定協(xié)議而不允許使用任意字符的場(chǎng)合，例如 DNS 查詢，HTTP Host 字段等等。 此轉(zhuǎn)換是在應(yīng)用中進(jìn)行的；如有可能將對(duì)用戶可見：應(yīng)用應(yīng)當(dāng)透明地將 Unicode 域名標(biāo)簽轉(zhuǎn)換為線上的 IDNA，并在 ACE 標(biāo)簽被呈現(xiàn)給用戶之前將其轉(zhuǎn)換回 Unicode。

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

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

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

encodings.idna.nameprep(label)?

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

encodings.idna.ToASCII(label)?

將標(biāo)簽轉(zhuǎn)換為 ASCII，規(guī)則定義見 RFC 3490。 UseSTD3ASCIIRules 預(yù)設(shè)為假值。

encodings.idna.ToUnicode(label)?

將標(biāo)簽轉(zhuǎn)換為 Unicode，規(guī)則定義見 RFC 3490。

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

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

Availability: 僅Windows可用

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

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