本模块定义标准 Python 编码解码器 （编码器和解码器） 的基类，并提供对内部管理的编解码器和错误处理查找过程的 Python 编解码器注册表的访问。
它定义了以下函数：
使用注册名为encoding的编解码器编码obj。默认编码是'ascii'。
错误可能会给以设置所需的错误处理方案。默认错误处理程序是'严格'意味着编码错误引发ValueError （或多个编解码器特定的子类，如UnicodeEncodeError）。有关编解码器错误处理的详细信息，请参阅编解码器基类。
在 2.4 版本新。
使用注册名为encoding的解码器解码obj。默认编码是'ascii'。
错误可能会给以设置所需的错误处理方案。默认错误处理程序是'严格'意味着解码错误引发ValueError （或多个编解码器特定的子类，如UnicodeDecodeError）。有关编解码器错误处理的详细信息，请参阅编解码器基类。
在 2.4 版本新。
注册编码解码器查找函数。查找函数接受一个参数——全小写字母的编码名称，并返回一个CodecInfo对象，该对象具有以下属性：
不同的函数或类含有下列参数：
编码和解码： 这些必须的函数或方法具有相同的接口encode()/decode()方法的编码解码器实例 （请参阅编解码器接口）。函数/方法预计将在无国籍的模式下工作。
incrementalencoder和incrementaldecoder： 它们必须是工厂函数提供以下接口：
factory(errors='strict')
工厂函数必须返回对象提供基类，这些类IncrementalEncoder和IncrementalDecoder，分别定义的接口。增量编码解码器能保持状态。
streamreader和streamwriter： 它们必须是工厂函数提供以下接口：
factory(stream, errors='strict')
工厂函数必须返回对象提供基类，这些类StreamReader和StreamWriter，分别定义的接口。流的编解码器能保持状态。
可能值为错误
以及任何其他的错误处理通过register_error()定义的名称。
万一一个搜索功能找不到给定的编码，它应该返回无。
在Python编码注册器里查找编码器信息，并返回一个CodecInfo对象，如上面定义。
编码首先在注册表的缓存中查找。如果未找到，扫描该列表注册的搜索功能。如果找不到CodecInfo对象，则引发LookupError 。否则为CodecInfo对象存储在缓存中并返回给调用者。
为了简化对各种编码解码器的访问，模块提供了这些额外的功能，使用lookup()编码解码器查找：
查找给定编码的编解码器，并返回其编码器函数。
无法找到的编码的情况下，提出了LookupError 。
查找给定编码解码器并返回它的解码器的功能。
无法找到的编码的情况下，提出了LookupError 。
查找给定编码的编解码器，并返回其增量编码器类或工厂函数。
无法找到的编码或编码解码器不支持增量编码器的情况下，提出了LookupError 。
新版本 2.5 中的。
查找给定编码的编解码器，并返回其增量的解码器类或工厂函数。
无法找到的编码或编码解码器不支持增量的解码器的情况下，提出了LookupError 。
新版本 2.5 中的。
查找给定编码的编解码器，并返回其 StreamReader 类或工厂函数。
无法找到的编码的情况下，提出了LookupError 。
查找给定编码的编解码器，并返回其 StreamWriter 类或工厂函数。
无法找到的编码的情况下，提出了LookupError 。
注册错误处理函数error_handler名称的名称。在编码和解码出错的情况下，当作为错误参数指定名称，将调用error_handler 。
编码error_handler将调用一个UnicodeEncodeError实例，其中包含有关错误的位置信息。错误处理程序必须提高这或一个不同的异常或返回一个元组替换为输入和编码应位置的 unencodable 部分。编码器将编码替换，并继续编码，原来的输入，在指定的位置。负位置值将被视为相对于输入字符串的结尾。如果没有绑定的最终位置将引发IndexError 。
解码和翻译作品类似，除了UnicodeDecodeError或UnicodeTranslateError将传递给处理程序和替换从错误处理程序将直接投入产出。
返回根据名称名称以前注册的错误处理程序。
找不到该处理程序的情况下，提出了LookupError 。
实施严格的错误处理： 每个编码或解码错误引发的UnicodeError。
实现替换错误处理： 格式错误的数据被替换为合适的替换字符如'?'在 bytestrings 和'' Unicode 字符串中。
实现忽略错误处理： 忽略格式不正确的数据和编码或解码持续而不必另行通知。
实现的xmlcharrefreplace错误处理 （用于编码只）： unencodable 的字符被替换为适当的 XML 字符引用。
实现的backslashreplace错误处理 （用于编码只）： unencodable 的字符被替换为带有反斜杠转义序列。
为了简化编码的文件或流处理，该模块还定义了这些实用功能：
打开经过编码的文件，使用给定的模式并返回提供透明的编码解码的包的版本。默认文件模式是'r'的意思在只读模式下打开该文件。
注
包装的版本将只接受的编解码器，即大多数内置解码器的 Unicode 对象定义的对象格式。输出也是编解码器依赖，并通常会以及 Unicode。
注
在二进制模式中，总是打开文件，即使指定了没有二进制模式。这样做的目的是为了避免由于使用 8 位值的编码的数据丢失。这意味着，没有自动转换的''在阅读和写作上完成。
编码指定要用于该文件的编码。
错误可能会给出了定义的错误处理。它默认为'严格'导致ValueError筹集以防出现编码错误。
缓冲已内置open ()函数相同的含义。默认的缓冲线。
返回包装提供了透明的编码翻译的文件的版本。
根据给定输入编码解释字符串写入到包裹文件并将其然后作为使用输出编码的字符串写入原始文件。中间的编码通常将 Unicode，但取决于指定的编码解码器。
如果不给定输出，它默认为输入。
错误可能会给出了定义的错误处理。它默认为'严格'，这将导致ValueError筹集出现编码错误的情况下。
使用增量式光电编码器迭代编码所提供的投入可迭代。此函数是一个生成器。错误（以及任何其他关键字参数） 传递到增量编码器。
新版本 2.5 中的。
使用增量的解码器进行迭代解码所提供的投入可迭代。此函数是一个生成器。错误（以及任何其他关键字参数） 传递到增量的解码器。
新版本 2.5 中的。
本模块还提供下列常量的读取和写入平台依赖文件非常有用：
这些常量定义各种编码的 Unicode 字节顺序标记 (BOM) utf-16 以及 UTF 32 数据流中用于表示字节流或文件中和在 utf-8 用作 Unicode 签名的顺序。 BOM_UTF16是BOM_UTF16_BE或BOM_UTF16_LE取决于平台的本机字节顺序， BOM是BOM_UTF16， BOM_LE ， BOM_UTF16_LE和BOM_BE的BOM_UTF16_BE的一个别名。其他代表的物料清单中 UTF 8 以及 utf-32 编码。
编解码器模块定义了一套的基类，这些类定义的接口，也可以用来轻松地编写您自己使用的编解码器在 Python 中。
每个编解码器已定义四个接口，以使它可用作编解码器在 Python 中： 无国籍的编码器，无国籍的解码器、 流读取器和流编写器。流读取器和作家通常会重用无国籍的编码器/解码器来实现文件的协议。
编解码器类定义的接口无国籍的解码器。
为了简化和标准化的错误处理， encode()和decode()的方法可以实现不同的错误处理方案通过提供错误字符串参数。以下字符串值是定义和实现的所有标准的 Python 编码解码器：
| Value | Meaning |
|---|---|
| 'strict' | Raise UnicodeError (or a subclass); this is the default. |
| 'ignore' | Ignore the character and continue with the next. |
| 'replace' | Replace with a suitable replacement character; Python will use the official U+FFFD REPLACEMENT CHARACTER for the built-in Unicode codecs on decoding and ‘?’ on encoding. |
| 'xmlcharrefreplace' | Replace with the appropriate XML character reference (only for encoding). |
| 'backslashreplace' | Replace with backslashed escape sequences (only for encoding). |
通过register_error()，可以扩展的允许值的集合。
编解码器类定义这些方法，还定义函数接口的无国籍的编码器和解码器：
编码对象的输入，并返回一个元组 （输出对象，消耗的长度）。编解码器并不只局限在 Unicode 上下文中，使用 Unicode，则编码将 Unicode 对象转换为使用特定的字符集编码一个普通字符串 （例如，使用 cp1252或iso 8859-1）。
错误定义错误处理申请。它默认为'严格'处理。
该方法不可能在编解码器实例中存储状态。为要保持状态，以使编码解码效率高的编解码器使用StreamCodec 。
编码器必须能够处理零长度的输入，并返回一个输出的对象类型的空对象，在这种情况。
解码对象的输入，并返回一个元组 （输出对象，消耗的长度）。在 Unicode 中，解码格式的字符串，使用一个特定的字符编码将编码设置为 Unicode 对象的转换。
输入必须是一个对象，提供bf_getreadbuf缓冲槽。Python 字符串、 缓冲区对象和内存映射文件是提供此插槽对象的例子。
错误定义错误处理申请。它默认为'严格'处理。
该方法不可能在编解码器实例中存储状态。为要保持状态，以使编码解码效率高的编解码器使用StreamCodec 。
解码器必须能够处理零长度的输入，并返回一个输出的对象类型的空对象，在这种情况。
IncrementalEncoder和IncrementalDecoder类提供用于增量编码和解码的基本界面。解码输入不做了一个无国籍的编码器/解码器函数调用，但有多个电话到encode()/decode()方法的增量编码器/解码器。增量编码器/解码器在方法调用期间跟踪的编码解码过程。
对encode()的调用的联接的输出 /decode()方法是相同的因为如果所有单项投入连在一起，这种投入是编码解码与无国籍的编码器/解码器。
新版本 2.5 中的。
IncrementalEncoder类用于编码中多个步骤的输入。它定义了每个增量编码器必须定义要符合 Python 编解码器注册表的以下方法。
一个IncrementalEncoder实例的构造函数。
所有的增量式编码器必须提供此构造函数接口。他们可以自由地添加附加的关键字参数，但只有在此处定义并使用 Python 编解码器注册表。
IncrementalEncoder可以实现不同的错误处理方案通过提供错误关键字参数。这些参数进行预定义：
错误参数将分配到具有相同名称的属性。分配给此属性，就可以切换不同的错误处理策略在IncrementalEncoder对象的生存期期间。
可以使用register_error()扩展的错误参数允许的值集。
将编码器重置为初始状态。
IncrementalDecoder类用于解码中多个步骤的输入。它定义了每个增量的解码器必须定义要符合 Python 编解码器注册表的以下方法。
一个IncrementalDecoder实例的构造函数。
所有增量解码器必须提供此构造函数接口。他们可以自由地添加附加的关键字参数，但只有在此处定义并使用 Python 编解码器注册表。
IncrementalDecoder可以实现不同的错误处理方案通过提供错误关键字参数。这些参数进行预定义：
错误参数将分配到具有相同名称的属性。分配给此属性，就可以切换不同的错误处理策略在IncrementalDecoder对象的生存期期间。
可以使用register_error()扩展的错误参数允许的值集。
对对象（考虑到解码器的当前状态） 进行解码，并返回所产生的解码的对象。如果这是最后一次调用decode() 最终一定是真的 （缺省值为 false）。如果最后是真的解码器必须完全解码输入，并必须刷新所有缓冲区。如果这不是可能的 （例如，因为不完整的字节序列末尾输入） 它必须启动错误处理就像在无国籍的情况下 （这可能会引发一个异常）。
将解码器重置为初始状态。
StreamWriter和StreamReader类提供通用的工作接口，可以用于实现新的编码子很容易。请参阅encodings.utf_8为例，如何做到这一点。
StreamWriter类是一个编解码器的子类，并定义了以下的方法，每个流的作家必须定义要与书记 Python 编解码器兼容。
一个StreamWriter实例的构造函数。
所有写入流必须提供此构造函数接口。他们可以自由地添加附加的关键字参数，但只有在此处定义并使用 Python 编解码器注册表。
流必须开放供写入二进制数据的文件类似对象。
StreamWriter可以实现不同的错误处理方案通过提供错误关键字参数。这些参数进行预定义：
错误参数将分配到具有相同名称的属性。分配给此属性，就可以切换不同的错误处理策略在StreamWriter对象的生存期期间。
可以使用register_error()扩展的错误参数允许的值集。
写入到流编码的对象的内容。
刷新和重置来保持状态使用的编解码器缓冲区。
调用此方法，应确保对输出数据投入允许附加的新的最新数据而无需重新扫描要恢复状态的整个流的干净状态。
除了上述方法， StreamWriter必须也继承的所有其他方法和属性从基础流。
StreamReader类子类的编解码器，并定义了以下的方法，每个流读取器必须定义要与书记 Python 编解码器兼容。
StreamReader实例构造函数。
所有流读者必须都提供此构造函数接口。他们可以自由地添加附加的关键字参数，但只有在此处定义并使用 Python 编解码器注册表。
流必须开放供读取 （二进制） 数据的文件类似对象。
StreamReader可以实现不同的错误处理方案通过提供错误关键字参数。定义了这些参数：
错误参数将分配到具有相同名称的属性。分配给此属性，就可以切换不同的错误处理策略StreamReader对象的生存期内。
可以使用register_error()扩展的错误参数允许的值集。
流中的数据进行解码，并返回生成的对象。
字符指示要从流中读取的字符数。 read ()将永远不会返回更多字符的字符，但它可能会返回较少，如果没有足够的字符可用。
大小表示要解码的目的从流中读取字节的近似的最大数目。解码器可以修改此设置为适当。默认值为-1 指示读取和解码尽可能多地。大小被为了防止不得不对一步到位的巨大文件进行解码。
一道防线指示以后线上有解码错误足以只返回第一行。
该方法应使用贪婪的阅读的策略，意味着它应该阅读尽可能多的数据被允许在定义中的编码和给定的尺寸，例如如果可选编码结局或状态标记在该流上可用，这些也应该读。
2.4 版本中的更改：添加的字符参数。
版本 2.4.2 中的更改：一道防线参数添加。
从输入流中读取一行并返回已解码的数据。
大小，如果给出，是作为大小参数传递给流的read ()方法。
如果keepends为 false 将从返回的行中去除行尾。
2.4 版本中的更改：keepends参数添加。
读取所有行上输入可用流并将它们作为行的列表返回。
行尾使用的编解码器的解码方法实现的并被列入列表条目，如果keepends为 true。
sizehint，如果给出，是作为大小参数传递给流的read ()方法。
重置来保持状态使用的编解码器缓冲区。
请注意没有流重新定位应该发生。这种方法主要是为了能够从解码错误中恢复。
除了上述方法， StreamReader必须也继承的所有其他方法和属性从基础流。
接下来两个基类是为了方便起见。他们不需要的编解码器的注册表，但可能提供有用的实践。
StreamReaderWriter允许包的流的工作在两个读取和写入模式。
设计是这样一个可以使用lookup()函数返回工厂函数来构造实例。
创建一个StreamReaderWriter实例。流必须是一个类似文件的对象。读者和作家必须工厂函数或类提供StreamReader和StreamWriter接口和错误处理在相同的方式定义为流的读者和作家。
StreamReaderWriter实例定义组合的StreamReader和StreamWriter类的接口。从基础流，他们继承所有其他方法和属性。
StreamRecoder提供的前端-后端编码处理不同的编码环境时有时是有用的数据视图。
设计是这样一个可以使用lookup()函数返回工厂函数来构造实例。
创建一个StreamRecoder实例实现的双向转换： 前端 （ read ()和write ()输出输入） 而读者和作家的工作，在后端 （读取和写入到流）进行编码和解码工作。
您可以使用这些对象做透明直接 recodings 从如拉丁语 1 到 UTF-8 的来回。
流必须是一个类似文件的对象。
编解码器接口必须遵循编码、解码。读者，作家必须工厂函数或类分别提供StreamReader和StreamWriter接口的对象。
前端翻译、读者和作家的后端翻译需要进行编码和解码。所使用的中间格式是由两个集的编解码器，例如确定 Unicode 编码解码器将使用 Unicode 作为中间体的编码。
错误处理是以同样的方式界定为流的读者和作家。
StreamRecoder实例定义组合的StreamReader和StreamWriter类的接口。从基础流，他们继承所有其他方法和属性。
Unicode 字符串作为序列代码点 （要精确作为Py_UNICODE数组） 的内部存储。根据的方式编译 Python （要么通过— — 启用 unicode = ucs2或— — 启用 unicode = ucs4，与前者是默认值） Py_UNICODE是任何一种 16 位或 32 位的数据类型。一旦在 CPU 和内存使用 Unicode 对象，CPU 的字节排序方式和这些阵列作为字节的存储方式成为一个问题。将 unicode 对象转换为字节序列称为编码，重新创建从字节序列的 unicode 对象被称为解码。有许多不同的方法，为这种转变可以做的事 （这些方法也称为编码）。最简单的方法是将映射代码点 0-255 到字节0x0-0xff。这意味着无法对一个包含代码点以上U + 00FF的 unicode 对象进行编码，用这种方法 （即所谓' 拉丁语-1'或"iso-8859-1"）。 unicode.encode()将提高UnicodeEncodeError ，看起来像这样： UnicodeEncodeError： ' 拉丁语-1' 编解码器无法编码字符 u 'ሴ' 在位置 3： 序号不在 range(256)。
还有另一组的选择所有的 unicode 代码点的不同子集和如何将这些代码点映射到字节0x0-0xff的编码 （所谓的 charmap 编码）。来看看如何做到这一点只需打开如encodings/cp1252.py （这是一种编码，主要在 Windows 上使用）。那里是显示你哪个字符映射到哪个字节值与 256 个字符的字符串常数。
所有的这些编码只可以编码在 unicode 中定义的 1114112 代码点 256。简单、 直接的方式，可以将存储每个 Unicode 代码点，是作为四个连续的字节存储每个代码点。有两种可能性： 在大端或小端字节序顺序存储字节数。这两个编码分别称为UTF 32 将和UTF-32-LE 。他们的缺点是如果你用UTF 32 是在一个小的 endian 机器上你都要换上编码和解码的字节。 UTF 32避免了这个问题： 字节为单位） 将永远在自然的字节排序方式。当这些字节读取 CPU 与不同字节排序方式时，字节为单位） 的就有虽然换。能够检测的utf-16或UTF 32字节序列的字节排序方式，还有所谓的物料清单 ("字节顺序标记"）。这是U + FEFF的 Unicode 字符。这种性格可以前置到每个utf-16或UTF 32字节序列。字节交换版本的这种性格 (0xfffe 开头） 是一个非法的字符，Unicode 文本可能不会出现。所以当utf-16或UTF 32字节序列的第一个字符显示为U + FFFE字节不得不换上解码。不幸的是字符U + FEFF曾作为零宽度无断空间的第二个目的： 有没有宽度，并且不允许使用一个单词要拆分的字符。例如，它可以用于给结扎算法的提示。以 Unicode 4.0 操作系统使用U + FEFF作为零宽度无断空间已弃用 (与U + 2060年（词细木工） 假设这个角色）。然而 Unicode 软件还必须能够处理U + FEFF这两种角色： 作为物料清单，它是设备，以确定已编码的字节的存储布局，煦一旦成 Unicode 字符串 ； 已解码的字节序列它是一个零宽度无断空间将解码像任何其他的普通字符。
还有另一种编码，能够完整范围的 Unicode 字符编码： UTF-8。UTF-8 是一种 8 位编码，这意味着没有与 utf-8 字节顺序的问题。每个字节的 utf-8 字节序列由两部分组成： 标记位 （最高有效位） 和有效载荷位。标记位为零到四1位后面0的位序列。Unicode 字符被编码为像这样 （带有 x 有效载荷位，当连接给 Unicode 字符）：
| Range | Encoding |
|---|---|
| U-00000000 ... U-0000007F | 0xxxxxxx |
| U-00000080 ... U-000007FF | 110xxxxx 10xxxxxx |
| U-00000800 ... U-0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
| U-00010000 ... U-0010FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
Unicode 字符的最低有效位是最右边的 x 位。
为 UTF-8 是 8 位编码没有 BOM 是必需的已解码的 Unicode 字符串中的任何U + FEFF字符 （即使它是第一个字符） 被视为一个零宽度无中断的空间。
Without external information it’s impossible to reliably determine which encoding was used for encoding a Unicode 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 2.5 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 DIAERESISRIGHT-POINTING DOUBLE ANGLE QUOTATION MARKINVERTED QUESTION MARK
iso 8859-1），这增加了utf-8-康美编码可以正确地猜测从字节序列的概率。这里不使用物料清单必须能够确定用于生成的字节序列的字节顺序，但作为签名，有助于在猜测的编码。编码 utf-8-康美编解码器将写入到 0xef 之间、 0xbb、 0xbf作为第三个字节文件。在解码utf-8-sig将跳过那些三个字节如果它们显示为文件中的第三个字节。UTF-8，在物料清单的使用是气馁和通常应该避免。
Python 带有大量的编解码器内置，要么实施作为 C 函数或词典作为映射表。下表列出了由几个常见的别名，并为其编码可能使用的语言的名称的编码解码器。别名的列表既的语言的列表就是要详尽无遗。请注意只有大小写不同的或使用连字符而不是下划线的拼写替代办法也是有效的别名 ；因此，如' utf-8'是一个有效的别名'utf_8'的编解码器。
很多字符集支持相同的语言。他们各不相同，在单独的字符 （例如是否欧元符号支持与否），并分配到代码位置的字符。对于欧洲的语言特别是以下变形通常存在：
| Codec | Aliases | Languages |
|---|---|---|
| ascii | 646, us-ascii | English |
| big5 | big5-tw, csbig5 | Traditional Chinese |
| big5hkscs | big5-hkscs, hkscs | Traditional Chinese |
| cp037 | IBM037, IBM039 | English |
| cp424 | EBCDIC-CP-HE, IBM424 | Hebrew |
| cp437 | 437, IBM437 | English |
| cp500 | EBCDIC-CP-BE, EBCDIC-CP-CH, IBM500 | Western Europe |
| cp720 | Arabic | |
| cp737 | Greek | |
| cp775 | IBM775 | Baltic languages |
| cp850 | 850, IBM850 | Western Europe |
| cp852 | 852, IBM852 | Central and Eastern Europe |
| cp855 | 855, IBM855 | Bulgarian, Byelorussian, Macedonian, Russian, Serbian |
| cp856 | Hebrew | |
| cp857 | 857, IBM857 | Turkish |
| cp858 | 858, IBM858 | Western Europe |
| cp860 | 860, IBM860 | Portuguese |
| cp861 | 861, CP-IS, IBM861 | Icelandic |
| cp862 | 862, IBM862 | Hebrew |
| cp863 | 863, IBM863 | Canadian |
| cp864 | IBM864 | Arabic |
| cp865 | 865, IBM865 | Danish, Norwegian |
| cp866 | 866, IBM866 | Russian |
| cp869 | 869, CP-GR, IBM869 | Greek |
| cp874 | Thai | |
| cp875 | Greek | |
| cp932 | 932, ms932, mskanji, ms-kanji | Japanese |
| cp949 | 949, ms949, uhc | Korean |
| cp950 | 950, ms950 | Traditional Chinese |
| cp1006 | Urdu | |
| cp1026 | ibm1026 | Turkish |
| cp1140 | ibm1140 | Western Europe |
| cp1250 | windows-1250 | Central and Eastern Europe |
| cp1251 | windows-1251 | Bulgarian, Byelorussian, Macedonian, Russian, Serbian |
| cp1252 | windows-1252 | Western Europe |
| cp1253 | windows-1253 | Greek |
| cp1254 | windows-1254 | Turkish |
| cp1255 | windows-1255 | Hebrew |
| cp1256 | windows-1256 | Arabic |
| cp1257 | windows-1257 | Baltic languages |
| cp1258 | windows-1258 | Vietnamese |
| euc_jp | eucjp, ujis, u-jis | Japanese |
| euc_jis_2004 | jisx0213, eucjis2004 | Japanese |
| euc_jisx0213 | eucjisx0213 | Japanese |
| euc_kr | euckr, korean, ksc5601, ks_c-5601, ks_c-5601-1987, ksx1001, ks_x-1001 | Korean |
| gb2312 | chinese, csiso58gb231280, euc- cn, euccn, eucgb2312-cn, gb2312-1980, gb2312-80, iso- ir-58 | Simplified Chinese |
| gbk | 936, cp936, ms936 | Unified Chinese |
| gb18030 | gb18030-2000 | Unified Chinese |
| hz | hzgb, hz-gb, hz-gb-2312 | Simplified Chinese |
| iso2022_jp | csiso2022jp, iso2022jp, iso-2022-jp | Japanese |
| iso2022_jp_1 | iso2022jp-1, iso-2022-jp-1 | Japanese |
| iso2022_jp_2 | iso2022jp-2, iso-2022-jp-2 | Japanese, Korean, Simplified Chinese, Western Europe, Greek |
| iso2022_jp_2004 | iso2022jp-2004, iso-2022-jp-2004 | Japanese |
| iso2022_jp_3 | iso2022jp-3, iso-2022-jp-3 | Japanese |
| iso2022_jp_ext | iso2022jp-ext, iso-2022-jp-ext | Japanese |
| iso2022_kr | csiso2022kr, iso2022kr, iso-2022-kr | Korean |
| latin_1 | iso-8859-1, iso8859-1, 8859, cp819, latin, latin1, L1 | West Europe |
| iso8859_2 | iso-8859-2, latin2, L2 | Central and Eastern Europe |
| iso8859_3 | iso-8859-3, latin3, L3 | Esperanto, Maltese |
| iso8859_4 | iso-8859-4, latin4, L4 | Baltic languages |
| iso8859_5 | iso-8859-5, cyrillic | Bulgarian, Byelorussian, Macedonian, Russian, Serbian |
| iso8859_6 | iso-8859-6, arabic | Arabic |
| iso8859_7 | iso-8859-7, greek, greek8 | Greek |
| iso8859_8 | iso-8859-8, hebrew | Hebrew |
| iso8859_9 | iso-8859-9, latin5, L5 | Turkish |
| iso8859_10 | iso-8859-10, latin6, L6 | Nordic languages |
| iso8859_13 | iso-8859-13, latin7, L7 | Baltic languages |
| iso8859_14 | iso-8859-14, latin8, L8 | Celtic languages |
| iso8859_15 | iso-8859-15, latin9, L9 | Western Europe |
| iso8859_16 | iso-8859-16, latin10, L10 | South-Eastern Europe |
| johab | cp1361, ms1361 | Korean |
| koi8_r | Russian | |
| koi8_u | Ukrainian | |
| mac_cyrillic | maccyrillic | Bulgarian, Byelorussian, Macedonian, Russian, Serbian |
| mac_greek | macgreek | Greek |
| mac_iceland | maciceland | Icelandic |
| mac_latin2 | maclatin2, maccentraleurope | Central and Eastern Europe |
| mac_roman | macroman | Western Europe |
| mac_turkish | macturkish | Turkish |
| ptcp154 | csptcp154, pt154, cp154, cyrillic-asian | Kazakh |
| shift_jis | csshiftjis, shiftjis, sjis, s_jis | Japanese |
| shift_jis_2004 | shiftjis2004, sjis_2004, sjis2004 | Japanese |
| shift_jisx0213 | shiftjisx0213, sjisx0213, s_jisx0213 | Japanese |
| utf_32 | U32, utf32 | all languages |
| utf_32_be | UTF-32BE | all languages |
| utf_32_le | UTF-32LE | all languages |
| utf_16 | U16, utf16 | all languages |
| utf_16_be | UTF-16BE | all languages (BMP only) |
| utf_16_le | UTF-16LE | all languages (BMP only) |
| utf_7 | U7, unicode-1-1-utf-7 | all languages |
| utf_8 | U8, UTF, utf8 | all languages |
| utf_8_sig | all languages |
大量的预定义的编码解码器是特定于 Python 是一种，所以他们的编解码器名字有外 Python 没有意义。这些都是基于预期的输入和输出类型 （请注意尽管文本编码是最常见的使用情况，为编解码器，基础的编解码器支持任意数据转换，而不是只是文本编码） 以下的表格中列出。对于不对称的编解码器，所述的目的描述编码方向。
下列编码解码器提供 unicode str 编码[1]和 str unicode 解码[2]，类似于 Unicode 文本编码。
| Codec | Aliases | Purpose |
|---|---|---|
| idna | Implements RFC 3490, see also encodings.idna | |
| mbcs | dbcs | Windows only: Encode operand according to the ANSI codepage (CP_ACP) |
| palmos | Encoding of PalmOS 3.5 | |
| punycode | Implements RFC 3492 | |
| raw_unicode_escape | Produce a string that is suitable as raw Unicode literal in Python source code | |
| rot_13 | rot13 | Returns the Caesar-cypher encryption of the operand |
| undefined | Raise an exception for all conversions. Can be used as the system encoding if no automatic coercion between byte and Unicode strings is desired. | |
| unicode_escape | Produce a string that is suitable as Unicode literal in Python source code | |
| unicode_internal | Return the internal representation of the operand |
新 2.3 版： Idna和punycode编码。
下列编码解码器提供了 str 对 str 编码和解码[2]。
| Codec | Aliases | Purpose | Encoder/decoder |
|---|---|---|---|
| base64_codec | base64, base-64 | Convert operand to MIME base64 (the result always includes a trailing '\n') | base64.b64encode(), base64.b64decode() |
| bz2_codec | bz2 | Compress the operand using bz2 | bz2.compress(), bz2.decompress() |
| hex_codec | hex | Convert operand to hexadecimal representation, with two digits per byte | base64.b16encode(), base64.b16decode() |
| quopri_codec | quopri, quoted-printable, quotedprintable | Convert operand to MIME quoted printable | quopri.encodestring(), quopri.decodestring() |
| string_escape | Produce a string that is suitable as string literal in Python source code | ||
| uu_codec | uu | Convert the operand using uuencode | uu.encode(), uu.decode() |
| zlib_codec | zip, zlib | Compress the operand using gzip | zlib.compress(), zlib.decompress() |
| [1] | str objects are also accepted as input in place of unicode objects. They are implicitly converted to unicode by decoding them using the default encoding. If this conversion fails, it may lead to encoding operations raising UnicodeDecodeError. |
| [2] | (1, 2) unicode objects are also accepted as input in place of str objects.They are implicitly converted to str by encoding them using the default encoding. If this conversion fails, it may lead to decoding operations raising UnicodeEncodeError. |
新版本 2.3。
这个模块实现了 RFC 3490 (国际化域名在应用程序中） 和 RFC 3492 (Nameprep: A Stringprep 配置文件为国际化域名名称 （IDN））。它是基于punycode编码和stringprep。
这些 Rfc 一起定义的协议，支持非 ASCII 字符的域名。域名包含非 ASCII 字符 （如www.Alliancefrançaise.nu） 转换成 ASCII 兼容编码 (ACE，如www.xn--alliancefranaise-npb.nu）。在所有的地方，在那里任意字符不允许的协议，例如 DNS 查询，HTTP主机字段等等然后使用 ACE 形式的域的名称。这种转换被进行中的应用 ；用户如果可能看不见： 应用程序应透明地转换 Unicode 域标签为 IDNA 丝，并将转换回 Unicode 之前向用户提交他们的 ACE 标签。
Python 支持这种转换在几个方面： idna编解码器可以之间执行转换 Unicode 和 ACE，将输入的字符串分割成基于在3.1 节(1) 条中定义的分隔符字符的标签 RFC 3490和视需要将每个标签转换为 ACE 和相反将输入的字节字符串分隔为基于.分离器和转换成 unicode 发现任何 ACE 标签的标签。此外，套接字模块透明地转换为 Unicode 主机名 ACE，以便应用程序不需要关心转换主机名称本身，当他们将它们传递到套接字模块。在此种情况下，模块包含主机名称作为函数参数，如httplib和ftplib，接受 Unicode 主机名称 （httplib然后还透明地将发送 IDNA 主机名主机字段中如果它在所有发送该字段）。
当接收主机名称从导线 （如反向名称查找），没有自动转换为 Unicode 执行： 想要向用户显示这些主机名的应用程序应该向 Unicode 解码它们。
模块encodings.idna还实现了 nameprep 程序，对主机名，并统一相似字符区分大小写属性的国际域名，执行某些正火。如果需要，可以直接使用 nameprep 函数。
返回标签的 nameprepped 版本。执行当前假定查询字符串，所以AllowUnassigned是真的。
新版本 2.5 中的。
这个模块实现了 UTF-8 编码解码器的 variant 类型： 对编码 utf-8 编码物料清单将预置到 UTF-8 编码的字节。状态编码器这只是一次 （在首次向字节流的形式写入）。为解码可选的 utf-8 编码的 BOM 数据的开头将被跳过。
