Encode::Supported -- Encode 支持的编码
编码名称不区分大小写。名称中的空格会被忽略。此外，一个编码可能有多个别名。每个编码都有一个“规范”名称。“规范”名称是根据以下顺序（有一些例外）从编码名称中选取的。
Perl 社区使用的名称。其中包括“utf8”和“ascii”。与别名不同，规范名称直接到达方法，因此“utf8”等经常使用的单词不需要进行别名查找。
IETF RFC 中定义的 MIME 名称。其中包括所有“iso-”名称。
IANA 注册表中的名称。
定义该名称的组织所使用的名称。
如果从法律上讲规范名称与 Encode 模块的名称不同，则在该名称得到实现时，它们始终别名。因此，您可以安全地通过传递规范名称来判断给定的编码是否已实现。
由于所有别名问题，并且在一般情况下编码具有状态，“Encode”在操作进行时在内部使用编码对象。
从 Perl 5.8.0 开始，至少识别以下编码。请注意，除非另有说明，否则它们全部不区分大小写（通过别名），并且所有空格都替换为“ -”。换句话说，“ISO 8859 1”和“iso-8859-1”是相同的。
编码在几个不同的模块中进行分类和实现，但在大多数情况下，您不必use Encode::XX来使它们可用。Encode.pm 将根据需要自动加载这些模块。
始终可以使用以下编码。
Canonical Aliases Comments & References
----------------------------------------------------------------
ascii US-ascii ISO-646-US [ECMA]
ascii-ctrl Special Encoding
iso-8859-1 latin1 [ISO]
null Special Encoding
utf8 UTF-8 [RFC2279]
----------------------------------------------------------------null和ascii-ctrl很特殊。“null”对所有字符都失败，因此当您将后备模式设置为 PERLQQ、HTMLCREF 或 XMLCREF 时，所有字符都将回退到字符引用。对于“ascii-ctrl”，除了控制字符之外，也是如此。有关后备模式，请参阅Encode。
除了本机 utf8 之外的 Unicode 编码方案受 Encode::Unicode 支持，它将根据需要自动加载。
----------------------------------------------------------------
UCS-2BE UCS-2, iso-10646-1 [IANA, UC]
UCS-2LE [UC]
UTF-16 [UC]
UTF-16BE [UC]
UTF-16LE [UC]
UTF-32 [UC]
UTF-32BE UCS-4 [UC]
UTF-32LE [UC]
UTF-7 [RFC2152]
----------------------------------------------------------------要了解 (UCS-2|UTF-(16|32))(LE|BE)? 之间有何不同，请参阅Encode::Unicode。
UTF-7 是一种特殊的编码，它将 UTF-16BE “重新编码”为 7 位编码。它由 Encode::Unicode::UTF7 单独实现。
Encode::Byte 实现了大多数单字节编码，但符号和 EBCDIC 除外。以下编码基于作为扩展 ASCII 实现的单字节编码。它们中的大多数将 \x80-\xff（上半部分）映射到非 ASCII 字符。
由于有这么多，它们以表格格式呈现，其中包含供应商的语言和相应的编码名称。请注意，该表按 ISO-8859 排序，相应的供应商映射与 ISO 的映射略有不同。有关详细信息，请参阅http://czyborra.com/charsets/iso8859.html。
Lang/Regions ISO/Other Std. DOS Windows Macintosh Others
----------------------------------------------------------------
N. America (ASCII) cp437 AdobeStandardEncoding
cp863 (DOSCanadaF)
W. Europe iso-8859-1 cp850 cp1252 MacRoman nextstep
hp-roman8
cp860 (DOSPortuguese)
Cntrl. Europe iso-8859-2 cp852 cp1250 MacCentralEurRoman
MacCroatian
MacRomanian
MacRumanian
Latin3[1] iso-8859-3
Latin4[2] iso-8859-4
Cyrillics iso-8859-5 cp855 cp1251 MacCyrillic
(See also next section) cp866 MacUkrainian
Arabic iso-8859-6 cp864 cp1256 MacArabic
cp1006 MacFarsi
Greek iso-8859-7 cp737 cp1253 MacGreek
cp869 (DOSGreek2)
Hebrew iso-8859-8 cp862 cp1255 MacHebrew
Turkish iso-8859-9 cp857 cp1254 MacTurkish
Nordics iso-8859-10 cp865
cp861 MacIcelandic
MacSami
Thai iso-8859-11[3] cp874 MacThai
(iso-8859-12 is nonexistent. Reserved for Indics?)
Baltics iso-8859-13 cp775 cp1257
Celtics iso-8859-14
Latin9 [4] iso-8859-15
Latin10 iso-8859-16
Vietnamese viscii cp1258 MacVietnamese
----------------------------------------------------------------
[1] Esperanto, Maltese, and Turkish. Turkish is now on 8859-9.
[2] Baltics. Now on 8859-10, except for Latvian.
[3] TIS 620 + Non-Breaking Space (0xA0 / U+00A0)
[4] Nicknamed Latin0; the Euro sign as well as French and Finnish
letters that are missing from 8859-1 were added.所有 cp* 也可用作 ibm-*, ms-* 和 windows-*。另请参阅http://czyborra.com/charsets/codepages.html。
Macintosh 编码似乎未在 IANA 等实体中注册。“规范”名称在 Encode 中基于 Apple 技术说明 1150。有关详细信息，请参阅 http://developer.apple.com/technotes/tn/tn1150.html。
尽管 ISO-8859 确实有 ISO-8859-5，但 KOI8 系列在网络中更为流行。Encode 附带以下 KOI 字符集。有关血腥细节，请参阅 http://czyborra.com/charsets/cyrillic.html
----------------------------------------------------------------
koi8-f
koi8-r cp878 [RFC1489]
koi8-u [RFC2319]
----------------------------------------------------------------GSM0338 适用于 GSM 手机。尽管它与 ASCII 共享字母数字字符，但控制字符范围和其他部分的映射方式非常不同，主要用于存储希腊字符。还有一些转义序列（以 0x1B 开头）来涵盖例如欧元符号。
这曾经由 Encode::Bytes 处理，但由于所有这些不寻常的规范，Encode 2.20 已将支持转移到 Encode::GSM0338。有关详细信息，请参阅 Encode::GSM0338。
一些特殊情况（如尾随 0x00 字节或单独的 0x1B 字节）未定义明确，并且 decode() 将为其返回一个空字符串。一种可能的解决方法是
$gsm =~ s/\x00\z/\x00\x00/;
$uni = decode("gsm0338", $gsm);
$uni .= "\xA0" if $gsm =~ /\x1B\z/;请注意，GSM0338 的 Encode 实现并未实现将拉丁大写字母重新用作希腊大写字母（例如，0x5A 是 U+005A（拉丁大写字母 Z），而不是 U+0396（希腊大写字母 ZETA）。
GSM0338 也包含在 Encode::Byte 中，即使它不是“扩展 ASCII”编码。
请注意，越南语已在上面列出。另请阅读下面的“编码与字符集”。另请注意，由于大小问题，这些由不同国家的不同模块实现（简体中文映射到“CN”，中国大陆，而繁体中文映射到“TW”，台湾）。请参阅其各自的文档页面。
Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
euc-cn [1] MacChineseSimp
(gbk) cp936 [2]
gb12345-raw { GB12345 without CES }
gb2312-raw { GB2312 without CES }
hz
iso-ir-165
----------------------------------------------------------------
[1] GB2312 is aliased to this. See L<Microsoft-related naming mess>
[2] gbk is aliased to this. See L<Microsoft-related naming mess>Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
euc-jp
shiftjis cp932 macJapanese
7bit-jis
iso-2022-jp [RFC1468]
iso-2022-jp-1 [RFC2237]
jis0201-raw { JIS X 0201 (roman + halfwidth kana) without CES }
jis0208-raw { JIS X 0208 (Kanji + fullwidth kana) without CES }
jis0212-raw { JIS X 0212 (Extended Kanji) without CES }
----------------------------------------------------------------Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
euc-kr MacKorean [RFC1557]
cp949 [1]
iso-2022-kr [RFC1557]
johab [KS X 1001:1998, Annex 3]
ksc5601-raw { KSC5601 without CES }
----------------------------------------------------------------
[1] ks_c_5601-1987, (x-)?windows-949, and uhc are aliased to this.
See below.Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
big5-eten cp950 MacChineseTrad {big5 aliased to big5-eten}
big5-hkscs
----------------------------------------------------------------由于大小问题，以下其他中文编码以 Encode::HanExtra 的名称在 CPAN 上单独分发。
Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
big5ext CMEX's Big5e Extension
big5plus CMEX's Big5+ Extension
cccii Chinese Character Code for Information Interchange
euc-tw EUC (Extended Unix Character)
gb18030 GBK with Traditional Characters
----------------------------------------------------------------由于大小问题，下面其他日语编码在 CPAN 中以 Encode::JIS2K 的名称单独分发。
Standard DOS/Win Macintosh Comment/Reference
----------------------------------------------------------------
euc-jisx0213
shiftjisx0123
iso-2022-jp-3
jis0213-1-raw
jis0213-2-raw
----------------------------------------------------------------有关详细信息，请参阅 perlebcdic。
----------------------------------------------------------------
cp37
cp500
cp875
cp1026
cp1047
posix-bc
----------------------------------------------------------------适用于符号和装饰字符。
----------------------------------------------------------------
symbol
dingbats
MacDingbats
AdobeZdingbat
AdobeSymbol
----------------------------------------------------------------严格来说，RFC 2047 中记录的 MIME 头部编码更像是封装而不是编码。然而，它们在现代世界中得到了必要的支持，因此得到了支持。
----------------------------------------------------------------
MIME-Header [RFC2047]
MIME-B [RFC2047]
MIME-Q [RFC2047]
----------------------------------------------------------------这不是编码的名称，而是一个实用程序，它允许您从给定的嫌疑犯中挑选出最适合数据的编码。有关详细信息，请参阅 Encode::Guess。
以下编码尚未得到支持；有些是因为它们很少使用，有些是因为技术困难。然而，将来它们可能会通过 CPAN 中的外部模块得到支持。
目前不太流行。需要 Unicode 数据库或等效数据库来实现 encode()（因为它同时包含 JIS X 0208/0212、KSC5601 和 GB2312，它们在 Unicode 中的代码点重叠。因此，您需要查找数据库以确定给定的 Unicode 字符应属于哪个字符集）。
不太流行。需要 CNS 11643-1 和 -2，而本模块中没有提供这些编码。CNS 11643 在 Encode::HanExtra 中（通过 euc-tw）得到支持。Audrey Tang 未来可能会在其模块中添加对该编码的支持。
由于缺少映射数据，以下编码不受支持。
'8' - arabic8, greek8, hebrew8, kana8, thai8, and turkish8
'15' - japanese15, korean15, and roi15Anton Tagunov 怀疑其有用性。
Encode 团队没有一个人对希伯来语足够了解（支持 ISO-8859-8、cp1255 和 MacHebrew，原因仅仅是因为在 http://www.unicode.org/ 上有可用的映射）。欢迎投稿。
同上。
同上。
尽管 Jungshik Shin 已报告 Mozilla 支持此编码，但在 5.8.0 之前我们无法添加此编码。未来，它可能会通过一个单独的模块提供。如果您有兴趣帮助我们，请参阅 http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/vps.uf 和 http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/vps.ut。
由于缺少映射数据，以下编码不受支持。
MacArmenian, MacBengali, MacBurmese, MacEthiopic
MacExtArabic, MacGeorgian, MacKannada, MacKhmer
MacLaotian, MacMalayalam, MacMongolian, MacOriya
MacSinhalese, MacTamil, MacTelugu, MacTibetan
MacVietnamese其余已可用的编码基于 http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ 上的供应商映射。
以下映射可在 http://www.unicode.org/ 上获得，但仍不受支持，因为这些编码需要一种算法方法，而目前 enc2xs 不支持这种方法
MacDevanagari
MacGurmukhi
MacGujarati有关详细信息，请参阅 http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/DEVANAGA.TXT 上的Unicode 映射问题和注释：。
我认为此问题不仅存在于 Mac 印度语中，还存在于其他印度语编码中，但上述印度语编码映射是我在 http://www.unicode.org/ 上唯一能找到的。
我们习惯于互换使用术语（字符）编码和字符集。但正如混淆字节和字符的术语很危险，并且需要在需要时区分这些术语一样，我们需要区分编码和字符集。
为了理解这一点，以下是对我们如何让计算机理解我们的字符的描述。
首先，我们从要包含哪些字符开始。我们将此字符集合称为字符库。
然后，我们必须给每个字符一个唯一的 ID，以便您的计算机能够区分“a”和“A”。这个逐项列出的字符库现在是一个字符集。
如果您的计算机可以在不进一步处理的情况下扩展字符集，那么您可以继续使用它。这称为编码字符集 (CCS) 或原始字符编码。在大多数情况下，ASCII 以这种方式使用。
但在许多情况下，特别是多字节 CJK 编码中，您必须进行更多调整。您的网络连接可能不接受任何设置了最高有效位的任何数据，并且您的计算机可能无法判断给定的字节是整个字符还是只有一半。因此，您必须编码字符集才能使用它。
字符编码方案 (CES) 确定如何编码给定的字符集或一组多个字符集。7 位 ISO-2022 是 CES 的一个示例。您可以通过转义序列在字符集之间切换。
从技术上或数学上来说，以逐个字符映射字符的方式编码在这样的 CES 中的字符集可以形成 CCS。EUC 就是这样的一个例子。EUC 的 CES 如下
ASCII 不变映射。
映射由 N 个成员的 94 或 96 次方组成的字符集，通过向每个字节添加 0x80。
您还可以使用 0x8e 和 0x8f 来指示以下字符序列属于另一个字符集。向每个后续字节添加值 0x80。
通过仔细查看编码的字节序列，您可以发现字节序列符合一个唯一数字。从这个意义上说，EUC 是由最多四个 CCS 以上的 CES 生成的 CCS（复杂？）。UTF-8 属于此类别。请参阅 perlUnicode 中的“UTF-8” 以了解 UTF-8 如何将 Unicode 映射到字节序列。
您现在可能已经发现为什么 7 位 ISO-2022 无法包含 CCS。如果您查看字节序列 \x21\x21，您无法判断它是由两个 ! 还是表意空格组成。EUC 将后者映射到 \xA1\xA1，因此您无需区分“!!”和" "。
本节尝试按其在互联网上进行信息交换的适用性对受支持的编码进行分类，并选择最合适的别名在该通信上下文中对它们进行命名。
要（编|解）码标记为 (**) 的编码，您需要 Encode::HanExtra，可从 CPAN 获得。
编码名称
US-ASCII UTF-8 ISO-8859-* KOI8-R
Shift_JIS EUC-JP ISO-2022-JP ISO-2022-JP-1
EUC-KR Big5 GB2312已在 IANA 中注册为首选 MIME 名称，可以在互联网上使用。
Shift_JIS 已被 JIS X 0208:1997 正式化。“与 Microsoft 相关的命名混乱” 提供了详细信息。
GB2312 是 EUC-CN 的 IANA 名称。有关详细信息，请参阅 “与 Microsoft 相关的命名混乱”。
GB_2312-80 原始 编码可作为 gb2312-raw 与 Encode 一起使用。有关详细信息，请参阅 Encode::CN。
EUC-CN
KOI8-U [RFC2319]尚未在 IANA 中注册（截至 2002 年 3 月），但似乎受到主要网络浏览器的支持。EUC-CN 的 IANA 名称是 GB2312。
KS_C_5601-1987被严重滥用。有关详细信息，请参阅 “与 Microsoft 相关的命名混乱”。
KS_C_5601-1987 原始 编码可作为 kcs5601-raw 与 Encode 一起使用。有关详细信息，请参阅 Encode::KR。
UTF-16 UTF-16BE UTF-16LE是 IANA 注册的字符集。有关详细信息，请参阅 [RFC 2781]。Jungshik Shin 报告说，带 BOM 的 UTF-16 被 MS IE 5/6 和 NS 4/6 广泛接受。但是，请注意
您将要使用/与之互操作的任何软件中的UTF-16支持可能比UTF-8支持经过的测试更少
UTF-8编码的数据无缝通过传统的命令管道（cat、more等），而UTF-16编码的数据很可能引起混乱（例如，其零字节）
HTML 浏览器对非ASCII表单数据进行编码的方式是无法用语言描述的。要获得总体印象，请访问 http://www.alanflavell.org.uk/charset/form-i18n.html。虽然对UTF-8编码的页面的表单数据编码已经稳定（至少 IE 5/6、NS 6 和 Opera 6 的行为一致），但请务必期待UTF-16编码的页面出现乐趣（和跨浏览器差异）！
经验法则是，除非您知道自己在做什么，并且除非您真的受益于使用UTF-16，否则使用UTF-8。
ISO-IR-165 [RFC1345]
VISCII
GB 12345
GB 18030 (**) (see links below)
EUC-TW (**)是完全有效的编码，但未在 IANA 注册。在此列出的名称可能是这些编码中最广为人知的名称，并且是推荐的名称。
BIG5PLUS (**)是一个专有名称。
Microsoft 产品误用了以下名称
EUC-KR的 Microsoft 扩展。
正确的名称：CP949、UHC、x-windows-949（Mozilla 使用）。
有关详细信息，请参阅 http://lists.w3.org/Archives/Public/ietf-charsets/2001AprJun/0033.html。
将别名 KS_C_5601-1987 编码为 cp949 以反映这种常见的错误用法。原始 KS_C_5601-1987 编码可用作 kcs5601-raw。
有关详细信息，请参阅 Encode::KR。
EUC-CN的 Microsoft 扩展。
正确的名称：CP936、GBK。
GB2312 已在 IANA 的EUC-CN含义中注册。这在一定程度上修复了这种情况：Microsoft 的GB2312已成为官方GB2312的超集。
将别名 GB2312 编码为 euc-cn，与 IANA 注册完全一致。cp936单独支持。原始 GB_2312-80 编码可用作 gb2312-raw。
有关详细信息，请参阅 Encode::CN。
Big5的 Microsoft 扩展。
专有名称：CP950。
Encode 分别支持 Big5 和 cp950。
Microsoft 对 Shift_JIS 的理解。
然而，JIS 并未认可 Microsoft 的完整标准。官方 Shift_JIS 仅包含 JIS X 0201 和 JIS X 0208 字符集，而 Microsoft 一直使用 Shift_JIS 来编码更广泛的字符库。请参阅 IANA 对 Windows-31J 的注册。
作为历史先例，Microsoft 的变体可能更有权使用该名称，尽管有人可能会反对 Microsoft 不应该一开始就把 JIS 用作名称的一部分。
明确名称：CP932。IANA 名称（Mozilla 也使用，Encode 提供别名）：Windows-31J。
Encode 分别支持 Shift_JIS 和 cp932。
唯一字符的集合。严格意义上的字符集。在此阶段，字符未编号。
以计算机可以直接使用的方式映射的字符集。包括 EUC 在内的许多字符编码都属于此类别。
将字符集映射到字节序列的算法。您不必能够分辨给定的字节序列属于哪个字符集。7 位 ISO-2022 是 CES，但它不能是 CCS。EUC 是既是 CCS 又 CES 的示例。
长期以来一直以编码、CES 的含义使用。
虽然单词组合字符集在 MIME 上下文中自 [RFC 2130] 以来失去了此含义，但字符集缩写保留了此含义。这就是 [RFC 2277] 和 [RFC 2278] 如何祝福字符集
This document uses the term "charset" to mean a set of rules for
mapping from a sequence of octets to a sequence of characters, such
as the combination of a coded character set and a character encoding
scheme; this is also what is used as an identifier in MIME "charset="
parameters, and registered in the IANA charset registry ... (Note
that this is NOT a term used by other standards bodies, such as ISO).
[RFC 2277]扩展 Unix 字符。请参阅 ISO-2022。
一种精心设计为与 ASCII 共存的 CES。有 7 位版本和 8 位版本。
7 位版本通过转义序列切换字符集，因此无法形成 CCS。由于这比 8 位版本在程序中更难处理，因此 7 位版本并不是很流行，除了 iso-2022-jp，这是电子邮件的事实上的标准 CES。
8 位版本可以形成 CCS。EUC 和 ISO-8859 就是两个示例。5.6 之前的 perl 可以将它们用作字符串文字。
通用字符集的缩写。当您只说 UCS 时，它表示Unicode。
ISO/IEC 10646 编码形式：以两个八位字节编码的通用字符集。
一种旨在涵盖全球所有字符集的字符集。各种国家以及行业标准中的许多字符集在某种程度上已成为 Unicode 的子集。
Unicode 转换格式的缩写。确定如何将 Unicode 字符映射到字节序列。
16 位编码中的 UTF。可以是大端或小端。大端版本称为 UTF-16BE（等于 UCS-2 + 代理支持），小端版本称为 UTF-16LE。
Encode、Encode::Byte、Encode::CN、Encode::JP、Encode::KR、Encode::TW、Encode::EBCDIC、Encode::Symbol Encode::MIME::Header、Encode::Guess
欧洲计算机制造商协会 http://www.ecma.ch
ISO-2022)http://www.ecma.ch/ecma1/STAND/ECMA-035.HTM
ISO-2022 的规范可从上述链接获取。
互联网号码分配机构 http://www.iana.org/
http://www.iana.org/assignments/character-sets
Encode 中的大多数规范名称都源自此列表，因此您可以直接应用从邮件和网页的 MIME 头中提取的字符串。
国际标准化组织 http://www.iso.ch/
征求意见稿——还需要我多说吗？ http://www.rfc-editor.org/、http://www.ietf.org/rfc.html、http://www.faqs.org/rfcs/
Unicode 联盟 http://www.unicode.org/
http://www.unicode.org/glossary/
本文档的词汇表基于该网站。
包含大量有用的信息，尤其是 ISO 与供应商映射的详细内容。
http://examples.oreilly.com/cjkvinfo/doc/cjk.inf
有点过时（最后一次更新于 1996 年），但仍然有用。还可以尝试
ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/pdf/GB18030_Summary.pdf
您将找到有关EUC-CN、GBK以及主要有关GB 18030的简要信息。
尤其是其主题 8。
韩语（KS *）标准的综合概述。
大多数提到的 CJK 编码的简要说明包含在 http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html
CJKV Information Processing by Ken LundeCJKV Information Processing 1999 O'Reilly & Associates，ISBN：1-56592-224-7
CJK.inf 的现代继任者。
全面涵盖 CJKV 字符集和编码，以及任何试图在信息处理的所有领域更好地支持 CJKV 语言/脚本的人面临的许多其他问题。
要购买此书，请访问 http://oreilly.com/catalog/9780596514471/ 或您最喜欢的书店。