字符集编码基础(翻译)

SourceURL: 

字符集编码基础

--理解字符集编码和传统编码

 

为了更好的理解处理多语言、多文字的文本数据，我们有必要开始了解一下字符编码的基础知识。处理文本的系统包括了一系列的过程：创建和编辑文本、文本展示、排序、布局，包括行尾的折行等。字符编码是所有这些过程的基础。

计算机系统现在使用了大量的字符编码规范，其中最重要的就是Unicode，了解Unicode也有助于我们理解其他编码规范，以及他们和Unicode的关系。本文中，我会介绍所有编码规范的基本概念，同时简述一些重要的传统编码规范及其重要性。

 

内容大纲：

1. 将文本变成数字

2. 数字的含义：字符属性

3. 工业标准传统编码

4. 工业标准 vs. 定制化编码

5. 字符集编码模型

5.1. 抽象字符清单

5.2. 已编码字符集

5.3. 字符编码规则

5.4. 字符编码方案

5.5. 字符编码模型（总结）

6. 了解你使用的标准

7. 附录（术语解释）

8. 参考资料

 

1. 将文本变成数字

    编码表示信息，或者声音、甚至手势的序列。书写语言，其实是人类的文字单元、声音、手势的一种继承，通过图形化的符号进行表示。是指以某种形式表达信息。人类语言本身就是一种编码系统，通过它，使用特定顺序的单元

 

在计算机系统中，我们使用字符序列将书写语言中的图形或文本元素进行编码，我们在软件系统中使用这些文本化信息表示书写的文本。然后，我们在计算机中使用一系列二进制数（计算机只能理解二进制数）对这些字符序列进行再编码。字符集编码（或者字符编码）就是完成这样的功能的系统。

    任何字符集编码都包括两方面内容：字符的集合和使用计算机表示这些字符的方法。当然，ASCII标准可以胜任，但并不是唯一的选择。根据计算机中存储的数字，可以解释为不同的含义，这取决于预先约定的假设。

 

Figure 1. Data interpreted according to selected codepage

 

我将在后面的篇幅中详细解释字符集和编码系统的关系。现在，我将使用术语codepage(代码页)来表示与一个特定字符集和相应的编码，术语codepoint表示针对一个单一字符的编码表示。这些只是临时性的约定，我们将在附录中重新回顾这些术语。

2. 数字的含义：字符属性

     当我们谈起“解释”，或者表述单元的含义，其实正是编码的“逆过程”。例如，当我们拼写“cat”这个英语单词的时候，假设使用ASCII编码，那么数字97表示拉丁字母"a"。对于用户来说，这些数字表示他们在书写时使用的文本元素。用户通常会从书写语言的角度考虑这些事情。

 

    但是计算机并不理解书写语言。对计算机来说，这些只是数字而已。程序员的工作就是，让用户以为计算机能够以书写语言的方式来工作（就像用户那样）。文本处理程序就是设计为完成这项工作的，例如，当调整页面布局的时候，针对单词的排序和折行的处理就是按照用户的书写习惯来进行的。

 

    因此，字符集编码有另一个重要的方面，正如我们看到的，字符集中的每个字符，都被分配了若干数字来表示。另外，每个字符都具有各种不同的属性，同时与其他字符存在联系，这些属性和联系都是影响软件处理方式的重要因素。

 

    例如，再来看ASCII码，区间65-90和97-122是用来表示英文大写和小写字母的，这些都是组成单词的字符。任何能够支持ASCII码的软件都必须尽量避免在单词中间折行。再比如，44表示逗号，是用于单词末尾的标点符号，文字处理软件通常不会在逗号和它跟随的单词字符中间折行，而是在逗号之后折行。还有，这些软件也可以设计为了解特定字符之间的关系，例如大写A和小写a之间的关系。

 

    需要注意的是，所有这些属性和关系在各种不同的编码标准之间可能都是不同的。例如，在ASCII中，65代表A，97表示小写a，但是在IBM的EBCDIC标准中，65未定义，97表示“/”，A用193表示，a用129表示。

 

    另外，有些属性和关系，可能不仅仅因为编码不同而不同，在同一个编码中也可能存在差别。例如，排序和大小写映射关系，在不同语言中可能不同。例如，当针对ASCII编码进行排序时，如果是英语，顺序是这样的：cg，ch，ci，但是，如果是西班牙语，则是：cz，ch，da。 

 

3. 工业标准传统编码

    编码的重要性基于两个原因：其一，给软件开发人员提供了一个文本解析的开发原则，其二，使得在用户之间交换数据成为可能。

 

    ASCII编码是最早的编码标准之一，对于US English是个最小化集合。但是它对British English的支持并不完整，然而，对于English的出版来说是足够了。在ASCII产生后，很快就产生了大量新标准。这些新标准的主要来源是标准化协会组织和独立的软件开发商。

 

    软件开发商经常开发编码标准来迎合特定市场环境下的特定产品。例如，IBM为DOS开发了Codepage 437，以ASCII为基础添加了British English和主要的欧洲语言所需要的字符，也添加了一些图形化字符，比如画线字符，用于在DOS环境下创建用户界面元素。同时，也存在其他DOS的Codepage来迎合其他语言的的其他市场。例如Codepage 852是用于东欧语言的处理，使用latin语系，CodePage 855用于俄语和其他东欧语言，使用西里尔语系。

 

    同时，其他公司也在创造其他编码标准以满足他们产品和客户的需求。在出版业，有一些特殊的编码需求，即便是针对英语，ASCII和IBM codepage 437都不能全部满足（为了解决高质量排版的需求）。这些编码标准通常都是内部使用的，并不会得到广泛使用。大多数其他的编码标准都是来源于硬件厂商，通常是主机开发商。例如，即便是在IBM内部，生产主机的部门也在开发他们自己的与DOS不同的codepage。

 

    在PC厂商中，苹果创建了与IBM和微软不同的标准来满足Macintosh产品线的特定图形化界面。同样，当微软开始开发windows时，图形化环境的需求同样促使了他们开发新的codepage。例如，codepage1252，别名是western/Latin1或ANSI。

 

    有时，某个公司开发的编码会随着他们的软件产品的推广而被广泛应用，从而成为实际上的一种工业标准。例如，由于DOS的重要性，IBM codepage437被大多数平台支持。事实上，虽然windows使用了一个更新的codepage，仍然在较深层次支持DOS，从而提供较好的DOS兼容性。与之相似，BIg5标准其实只是台湾5个厂商开发的，但是由于它得到了很多其他厂商的支持，从而变成了繁体中文的事实标准，甚至比台湾的国际标准使用更加广泛。

 

    另一个编码标准的主要来源是国家或国际标准化组织。一个国家标准可以借鉴厂商的标准并将其提升为国家标准，也可以创建一个全新的编码标准，与任何已知的标准都不相同。在某种情况下，一个国家标准也可以被采纳为国际标准。还是举ASCII的例子，其实最开始是美国的国家标准（ANSI X3.4 1968），后来被ISO采纳，成为了ISO 646：IRV.。在其他情况下，编码标准也可能直接在国际层面产生，例如ISO 8859。

 

    大多数的传统编码标准 使用8bit（1byte）处理单元进行每个字符的编码，但并不是所有的硬件架构都是用8bit的字节，不同架构使用不同的字节长度，范围通常从6bit 到36bit。对于PC而言，可以简单的认为所有字符编码标准都是用8bit格式。

 

    但是也有例外，有些编码标准使用不止一个8bit字节。例如，微软的中文编码、日文、韩文，都采用双字节编码，使用单字节和双字节的混合编码来表示一个字符。例如，在codepage 950中，繁体中文，0x73表示拉丁文的小写s，但是在双字节编码中，以0x73结尾可能代表一个不同的字符，例如，0xA4 0x73表示繁体中文的“山”字，这些内容将在Sectioin5.3中进行详细阐述。

 

    当然，对于所有这些不同的编码标准而言，无疑在很多情况下，一个给定的标准会提供一些其他标准不支持的特定字符。没有任何一个传统的编码标准是全面的。在很多情况下不同的编码标准支持同样的字符集但是并不兼容。这些问题都在Unicode中得到了解决。但是即便软件开发人员设计了一个使用Unicode的产品，传统的标准也不能被忽视。这是因为，仍然会有大量历史数据使用传统的编码标准，同时也有相当多的软件实现使用了传统的编码标准。

 

    在结束关于这些工业标准编码标准的讨论之前，有必要解释一下windows的codepage和ANSI。当windows的开发过程中，美国国家标准化组织正在起草一个后来被称之为ISO 8859-1“latin 1"的标准。微软基于ANSI提议开发了codepage 1252 (西欧语言)，并且开始称之为“ANSI Codepage”。codepage1252在iso8859-1之前开发完成了，然而这两个标准并不完全相同，1252是iso8859-1的超集。

 

    后来，在windows95开发过程中，微软开始使用ANSI的口气描述windows codepage，用以对抗Unicode。因此，在windows上下文中，术语“ANSI文本”或“ANSI codepage”应该被解释成，该文本使用传统8bit windows codepage编码，而不是Unicode。Unicode也的确不应该被理解为Windows Codepage。

 

4. 工业标准 vs. 定制化编码

    正确理解工业编码标准和特定软件产品之间的关系是非常重要的。任何商业软件产品在设计时，都存在字符编码标准的约定。所有文本处理都是以其中一个编码标准作为前提进行约定（即同时只能有一个字符编码标准生效）。这里有一个数据方面的重要问题：如果数据本身不能标记其自身的编码方式，或者数据错误的标记了自身的编码方式，数据的展示和处理都可能导致无法预料的结果。这个问题在WEB上尤为明显，有些作者创建了HTML的内容，但是忘记了需要指定相应的编码方式用于展示。

 

    一个很重要的问题是，如果你的软件使用了一个并不支持的字符集，就可能出现问题。对于语言学家和语言工作者来说，他们经常使用一些小众语言，这种情况就更加明显。出现这种情况的原因是，软件厂商在设计产品的时候，都是假定了一个特定的市场范围，那些小众的需求通常是会被忽略的。从软件厂商的角度来看，这也不能说不公平，他们只能支持他们能够考虑到的或者可预期的情况，也就是某种特定的标准。

 

    我们都知道，当可用的软件都无法支持语言学家们使用的书写系统时，他们必须创造自己的解决方案。他们定义自己的字符集和编码，并“破解”相应的字体，这样他们才能正确的查看数据，他们创造专用的输入法来支持特定字符集的数据输入。从他们的角度来看，这样的实践是很有意义的事情。不能不说这些自己创造解决方案的人是很有才华的，这些解决方案包括了一系列专门的工具，例如SIL Encore font system/Tavultesoft keyman 3.2。当然，也有不那么完美的一面，即便语言学家们定义了一个专用的codepage，他们使用的软件也通常是基于某种现存工业标准编码之上的，并不能完全脱离现有的编码标准。

 

    例如，有人在win98 US版上使用WORD的时候，使用了一个“破解”的字体，基于一个专用的codepage，如下图所示：

 

Figure 2. A custom-defined codepage

    我们都知道WORD有一个特性是可以自动进行大小写转换。但是WORD是如何知道该如何进行这种转换呢？它是利用了字符的语义特性，针对windows codepage 1252通常是这样的，如下图所示：

 

Figure 3. A standard codepage (Windows codepage 1252)

 

当用户输入0xE0到0xEF之间的字符时，WORD将从0xC0到0xCF之间选择字符进行相应的大小写转换。

 

    对于语言学家来说，这样的转换并不是件好事。使用定制化codepage的人经常会因此抱怨微软，抱怨软件自作聪明的做了太多事情，以至于把数据搞乱。但我们必须知道，尽管如此，软件厂商还是必须基于这些标准来设计软件。这种自动化的转换，是一种能让绝大多数用户从中受益的特性。幸运的是，对于使用上图中定制化codepage的用户，微软提供了一个选项来关闭这项功能。

 

即便如此，还是有一系列问题是无法避免的，例如：

n 软件中可能利用特定的字符用于特殊的展示目的，例如，WORD中使用0xB0作为不间断空格，当切换到“显示不可见字符”模式可以看到。如果使用了“破解”字体，将会展示错误的字符。

n 在特定上下文中，软件可能会自动改变货币符号，例如，0xA3或0xA5

n 很多应用有一种“自动补齐”的特性(例如括号)，当使用“破解”字体时，可能会导致不希望看到的结果

n 字符0xAD是一个软连接字符。有些软件可能只有当他出现在行中最后一个字符时才会显示。例如，在macromedia的freehand软件就是这样处理。

n 软件可能会将一些非组词的字符赋予一些特殊的含义，比如很多软件中的换行和编辑操作，例如使用CTRL+箭头的组合进行移动。

n 软件可能会将数据进行编码转换，在使用定制化codepage交换数据的时候，会出现错误，例如在windows和mac之间。

n  有些软件会将特定字符进行自动翻译，例如，当保存为文本文件时，有些版本的WORD会将copyright符号©，转换成等价的ASCII表示，（？）。当使用定制化编码字体时，这种自动翻译会产生垃圾数据。

n 在codepage1252中没有定义的codepoints，例如0x8F，在某些平台可以工作，有些则不可以。

 

    所有这些问题，都是在使用定制化编码字体时会引发的一些异常情况。避免出现这种问题的一种方法是，软件不要根据codepage进行场景假设，或者说，应该只允许最终用户对codepoint进行语义上的解释。当然，这种方法在商业软件中也是很危险的，毕竟用户可能会把事情搞乱。所以，这种方法实际上只在给语言学家使用的软件中才会用到。

 

    另一个避免这些问题的方法是，使用“符号编码”的字体。这些windows上的“符号编码”字体使用一个特殊的编码段，当在文本中使用这些字符时，应用程序无法知道这些字符实际上是什么，这样就可以自定义一些默认的行为。但是这也会导致一些软件自身的问题，例如，在WORD 97中，当字体改变成一个“符号编码”字体时，换行操作会发生巨大改变。

 

    以上的两种方法其实都不能解决使用定制化编码的根本问题，即，数据归档和数据交换：当数据脱离了定制化字体，就是无用的。由于数据本身和数据的含义是分离的，因此数据本身就缺少健壮性，这在归档时会是一个很严重的问题。即便到了现在，阅读穿孔卡片或者纸带，都比阅读缺少字符和编码定义的字节流要容易。通常，这种文档都只由一种字体组成。

 

    基于特定字体的依赖性问题，引发了关于数据交换的大量激烈争论：你不得不在发送一份文档的时候，附带一份字体，或者确认接收人已经安装了相关字体。WEB就是一个很好的例子。人们通常会通过使用adobe acrobat（pdf）文件格式来避免这一问题（PDF文件中可以包含字体），但是在某种情况下，包括web，这样做有一定的局限性。如果数据是要发给一个出版商，而出版商必须要编辑这些数据并对文档排版，acrobat就不是一个很好的选择了。对出版商来说，这个问题是很尖锐的，因为他们获取文档的来源很多，如果这样做，就必须维护大量的私有字体库。更进一步说，如果他们不得不使用这些字体，由于需要进行大量数据核对工作，实际上阻碍了他们在设计方面发挥他们的特长。

 

    这些困难变得越来越复杂了，因为定制化的codepage目前正有激增的趋势。当不同用户使用了相同语言和相同的书写系统，但是创建了互不兼容的codepage时，例如，对于古希伯来文存在大量的定制化codepage。我们设想一下，一个希伯来研究机构的期刊编辑，每天都收到大量使用不同codepage的手稿，他肯定会崩溃掉。最合理的方法是让大家都遵从包含所有这些字符的统一编码，Unicode的出现使这些成为可能，它囊括了目前世界上存在的所有字符集。

 

5. 字符集编码模型

    在结束字符编码基础和传统编码的讨论之前，我会详细解释字符集、编码的完整模型。早些时候我说过，一个字符集编码包括了至少两方面的组成，一个字符的集合，和一个使用计算机编码表示的系统。更加完整的模型其实也是必要的，包括4个不同层次的表示：

1）抽象字符清单；

2）已编码字符集；

3）字符编码规则；

4）字符编码方案；

    对大多数人来说，比较容易混淆的是2）和3），即已编码字符集和字符编码规则。对于很多大家常用的字符编码来说，这两者的区别并不重要，包括定制化codepage，但是，对于一些工业标准或Unicode来说，这非常重要的。值得注意的是，codepage和codepoint通常都有不同的含义。在这一部分，我会提供两者的详细解释，因为他们都在Unicode标准中定义和使用了。对于这些术语的讨论也会放在section7部分。

 

5.1. 抽象字符清单

    抽象字符清单（ACR）可以简单理解为无序的字符集合。在一个特定的标准中，清单可能会处于closed状态，意味着它是被修订过的，并且不会再追加了，或者也可能处于open状态，意味着新字符是可以随着时间的发展而增加的。例如，Unicode有一个开放的清单，会周期性的添加条目，目的是使得这个标准更加通用化。

 

    “抽象”的含义包括：首先，他们并不是直接存在于计算机系统中的，事实上，可能在真实世界中他们也不是具体的事物，他们只是概念上的事物，比如记号“f”。另外，也没有必要把“抽象”字符和书写系统对应起来。例如，西班牙字符（ñ）中的“～”波浪符，可以被当作一个单独的字符，这样西班牙语中的这个字符（ñ）就可以用一个字符序列（n、~）来表示。最后，这些抽象符号也不必是一个图形化的对象。例如，一个抽象的字符清单可能会包括“0宽度空格”（zero-width space），这个字符不存在图形化的展示，仅仅是一个控制字符。

 

5.2. 已编码字符集

    模型中的第二个层次是已编码字符集(CCS)。已编码字符集仅仅是从字符清单到唯一数字标识符的映射。一般来说，这些数字标识符指的是整数（在有些标准中是整数对）。

 

    数字标识符的专业术语叫做codepoint，一个抽象字符和它的codepoint组合被称之为已编码字符。值得注意的是，这些codepoint与任何计算机中的表示无关。也就是说，这些codepoint并不是比特（字节），他们仅仅是整数。codepoint的取值范围常常是在标准中被限定了的。在一个编码标准中，有效的codepoint取值范围被称作codespace。在一个标准中，已编码字符的集合被称之为codepage。

 

    在CCS中，与已编码字符相关的任何属性，都需要被明确的定义下来。通常，一个标准会像确定唯一的codepoint一样确定已编码字符的唯一名称，例如“拉丁小写字母A”。实际上，在CCS中，把字符的名称和其他属性都作为已编码字符的定义是非常有意义的。

 

    在描述第三个层次前，我们有必要了解一下工作在CCS层的工业标准。这些标准将字符的集合标准化，也可能包括他们的名称或其他属性，但是并未将他们的计算机表示进行标准化。例如，在远东的几个字符标准，例如GB2312-80(简体中文)，CNS 11643（繁体中文），JIS X 0208(日文)，KS X 1001（韩文）。这些标准是依赖于独立的编码表示，这是模型中下一个层次需要描述的。

 

5.3. 字符编码规则

    第三个层次是字符编码规则(CEF)，从这个层次开始我们才真正开始涉及字符编码的计算机表示。CEF实际上是CCS中的codepoint到一系列固定数据类型序列的映射。这些映射后的值被称作code units。原则上，code unit可以是任意大小的：他们可以是7-bit，8-bit，19-bit，或者其他。最常用的当然是8/16/32 bits。在有些上下文中，应用到一个特定的已编码字符集上的CEF也被称作codepage（详见 section 7的描述）

 

    CCS和CEF之间的映射，即codepoint到code unit的映射并不一定非得是1对1的。在很多情况下，在编码规则中，一个codepoint可以映射多个code unit的序列。这种情况被称为“double-byte” 编码。例如microsoft的932或950编码。一个编码规则也没有必要以固定长度进行映射。例如，codepage 950，罗马字符“s”的编码是ox73，但是Han编码“山”

是双字节编码，oxA4  0x73。还有，一个编码也并不一定要限定在2个code units，例如，在EUC-TW 标准中，编码使用1到4个字节长度。然而，有一件事情是很严格的：从给定的codepoint，到code unit的映射必须是唯一的。

 

    一个编码规则可以是无状态的，这就意味着字符中的任意编码，或者它使用的任何序列，在任何时间都是可用的。然而，有些则是状态相关的，包括交替状态，这样在一个给定的状态下，只有字符集的一部分可以被编码，除非状态发生改变。在这种工作方式下，编码规则会指定一个特定的code unit序列来标识状态的改变。一旦在数据中遇到了这样的序列，所有后续的数据将按照特定状态进行解释，直到遇到特殊的code unit序列出现，然后进入另一个不同的状态。

 

    例如，HZ编码就是这样工作的。在默认状态下，字节流是按照ASCII进行解释。它定义了特定的转换序列用于转换成不同的字符集。0x7E 0x7B(在ASCII中是~{ )使得后续的数据进入另一个转换序列或者从下一行的开始，将被解释为GB2312-80字符集（简体中文）。0x7E 0x 7D(在ASCII中是~} )表示改变回ASCII。

 

    有些已编码字符集通常只与一个编码规则相对应。除了远东字符集以外，对于大多数传统字符集而言，codespace都可以使用单字节表示，所以他们的codepoint就很容易一致。因此就没有太大必要去寻找另外的编码规则。在远东的标准中，Big Five字符集（繁体中文）经常使用Big Five编码。

 

    与之类似，有些编码规则也只适用于特定的字符集，例如Big Five编码，或者Unicode的UTF-8编码

 

    从另一方面来说，有些字符集经常使用不同的编码规则，例如，GB2312-80字符集，可以使用GBK编码，ISO 2022编码，或者使用EUC编码。同样，有些编码规则可以应用到不同的字符集上，例如，有一些EUC的变种，可以用在GB2312-80，CNS 11643-1992，JIS X 0208，和其他一些字符集上。

 

    一个编码规则甚至可以同时应用到多个字符集上，ISO 2022标准就是这样出台的。ISO维护了一个可以使用ISO 2022进行编码的字符集列表，并且给每一个特定字符集分配了一个特定的“escape sequence”。.默认情况下，ISO 2022数据被解释为ASCII字符集。当遇到任何一个“escape sequence”时，后续的数据将被解释为特定的字符集，直到遇到一个新的“escape sequence”或者恢复到默认状态。引入ISO 2022就是为了使用一个统一的编码规则潜在支持所有字符集。它使用很多机制来控制数据解释的方法，因此，它是相当复杂的。幸运的是，有一个更好的方法：Unicode。

 

    Unicode使用一个独立的已编码字符集，可以使用三种编码规则进行表示。三种编码规则对应三种数据类型大小：UTF-8使用8-bit的code unit，UTF-16使用16-bit的code unit，UTF-32使用32-bit的code unit.UTF-32可以使用一个单独的code unit表示每一个code point，但是UTF-8和UTF-16则使用一个或多个code unit的序列表示。对于Unicode的详细描述，参见  Whistler and Davis (2000) and in 。

5.4. 字符编码方案

    模型中的最后一个层次是字符编码方案（CES）。随着计算机技术的发展 ，8-bit字节在很多系统中都有非常重要的地位。特别是，在最低的层次，很多系统储存和传输数据都是用8-bit字节。当16-bit或32-bit数据单元被放到8-bit字节上下文中时，数据单元很容易被分割成8-bit 数据块，因为他们的大小是8-bit的整数倍。对于这些数据块的排序方式，存在两种逻辑上的组织形式：little-endian，表示低位字节先行；big-endian，表示高位字节先行。也就是说，对于16-bit和32-bit编码规则，在考虑数据的存储和传输时，很容易产生混淆。字符编码方案正式为了解决这种混淆而产生的。

 

    除了Unicode，16和32 bit编码规则并不常见，虽然也存在。也就是说，在Unicode以外，字节序的问题并不是很典型的。Unicode支持两种字节序，无论是UTF-16还是UTF-32。如果需要更详细的内容，可以参考 Whistler and Davis (2000) and in 

 

5.5. 字符编码模型（总结）

让我们快速回顾一下字符编码模型的4个层次

 

n 在最深层次，我们有一个抽象字符清单，是一个未排序的抽象字符集合。

n 然后是已编码字符集，我们把抽象字符集合与数字的codepoint对应起来形成已编码字符。我们定义了codespace，是这些数字表示的一个范围。

n 一个字符编码规则将一系列的code unit分配给code point，使用特定大小的数据类型，8/16/32 bit整数。

n 在16/32 bit编码规则中，一个字符编码方案解决了可能存在的字节序问题，little-endian或者big-endian。

 

6. 了解你使用的标准

    我们看到有非常多的字符集/字符编码的工业标准。我们了解了在软件处理数据过程中，字符语义的重要性，还有定制化编码数据是如何工作的。我们还简单介绍了一下Unicode并且看到它是怎样解决我们正在使用的传统编码中的很多问题。无论我们工作在什么场景下，我们都很可能受到多种字符集或编码标准的影响。他们之间的关系对我们形成了巨大的挑战。

 

    因此，理解影响我们的字符集和编码标准是非常重要的。你需要理解你使用的软件使用到的标准。既包括操作系统也包括应用程序，也可能包括一些不那么明显的应用，例如邮件系统和WEB服务。同样你需要理解你工作的地区经常使用的标准，或者你经常与之交换数据的人使用的标准。特别是，你需要理解这些标准是如何与你使用的字符编码相关联的，特别是如果你依赖于某种定制化的codepage。对于我们大多数人来说，这意味着至少需要理解windows codepage。如果你在美国或者西欧以外的地区工作，一定要确保你理解除了1252 codepage以外的codepage。一个很有用的参考列表是……，如果你使用MAC或者与使用MAC的人交换数据，你需要理解MAC与Windows codepage的区别和联系。

 

    如果你使用高层数据协议工作：email/HTML/XML/RTF或者其他类似协议，那么你需要熟悉在这些的上下文中字符集编码标准如何定义。在Internet上，很多系统，包括邮件系统，使用RFC定义的字符集编码的协议。你需要阅读相关的RFC文档来理解在上下文中使用什么编码标准。在HTML4.0，和后来的XML中，Unicode字符集是经常使用的，但是可能使用不同的编码规则。然而，在HTML和HTTP中，编码规则被称之为 charsets。但这些标识符是基本相同的。

 

在internet和WEB上使用的codepage(charsets)被IANA组织维护，可以参考：

 

.

Microsoft Internet Explorer understands a fairly large number of different codepages used in HTML and HTTP. Some useful information is provided at

. Apple provides some similar information at 

http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConversionManager/TEC1.5/index.html. 

    在win32编程接口和RTF/WORD中，codepage可以被理解为字体变种（font variants），也就是charsets。在这个情况下，charsets给定了数字标识。例如，codepage 1252映射为charset 2，"symbol"编码映射为 charset 0。charset数值在RTF规范中进行定义，尽管并不完整（它并没有告诉你这些是如何与codepage相关联的，尽管你可能可以正常工作）

 

 (search for the second instance of “fcharset”). For RTF， you should also be familiar with the “ansi” and related keywords. See 

.

    信息技术的快速发展推进了Unicode的发展。这是个好消息，因为与传统字符编码相关的细节实在是太难理解了，而且各自孤立。无论你在哪里工作或者使用何种系统，Unicode都将影响到你，而且，非常有可能，已经影响了。任何人实现或者支持文本处理系统，都必须要对Unicode足够熟悉。我有另一篇文章专门介绍Unicode的文章可以帮助大家开始了解这些事情。

 

7. 附录（术语解释）

    在整篇文章中，有两个术语被多次使用：codepoint和codepage，在5.3中，这两个术语在已编码字符集这个层次中被严格定义。

 

    通常，在非正式使用场合，这些术语经常被用于指代字符编码规则，或者CCS和CEF层次的组合。这些术语很容易混淆。严格来说，codepage这个术语最好用于表示一个特定的CCS，但是人们经常把它理解为CCS和CEF的组合。例如，在Microsoft windows中就是这样被使用的。Microsoft “codepage 932”，表示 JIS X 0208：1997字符集和Shift-JIS编码。这也是我在本篇文章前半部分使用的方式。

 

    同样的，一个codepoint应该严格用于已编码字符集中针对一个字符的数字标识符。然而，它经常在非正式场合被用于表示抽象字符和code unit序列的组合，或者仅仅表示一个code unit序列。

 

     非正式的含义可能来源于两种原因。第一，人们总是从自己的实际工作出发去理解和使用术语。这样，他们就倾向于从具体而不是抽象的角度去考虑问题。对于他们来说，关于字符的最具体事情是他们出现在屏幕上的形状和储存在文件中的字节流。这些因素更贴近字符的辨别，这与CCS相关，而字符的表示，则与CEF相关。第二，大多数用户都对非远东的传统文本系统不熟悉，而只有远东文本系统的code unit和codepoint是不同的。在这种情况下，CCS和CEF没有什么区别，所以人们也没有必要进行区分。

 

    然而，在使用东亚标准和Unicode的时候，CCS和CEF的区别就显得非常重要了。因此，对这些标准而言定义不混淆的术语来区分不同层次就有意义了。对于一个已编码字符集而言，正确的术语是codepage和codepoint。当提到一个字符编码标准时，建议的术语是code unit。如果你想要开始学习Unicode标准时，你可能会发现，正确的理解这些术语，有助于更好的学习和使用Unicode.

 

8. 参考资料

Dürst， Martin; François Yergeau; Misha Wolf; Asmus Freytag; and Tex Texin; eds. 2001. Character model for the World Wide Web 1.0. W3C working draft 26 January 2001. Cambridge， MA: The World Wide Web Consortium. Published online at

. 

Lunde， Ken. 1999. CJKV information processing. Sebastopol， CA: O’Reilly & Associates.

Whistler， Ken， and Mark Davis. 2000. Unicode technical report #17: character encoding model. Revision 3.2. Cupertino， CA: The Unicode Consortium. Published online at

.

1	Of course， as users， we aren’t even aware of the numbers. We see the numbers interpreted by the computer as glyphs. But the user generally isn’t even aware of the individual glyphs. They think in terms of the inferred writing system.
2	The name “Latin 1” should properly only be applied to the ISO 8859-1 character set standard. The relationship between ISO 8859-1 and Microsoft codepage 1252 is explained below in the text.
3	Information on standards for Far East languages was drawn from Lunde (1999). This is the best single source of information currently available on standards for Chinese， Japanese， Korean and Vietnamese.
4	Exact upper and lower limits are difficult to ascertain because definitions for things like byte and their relationship to code units for representing text start to break down. For example， teletype machines used 5-bit Baudot code， but it is unclear to me if the transmission protocol and other aspects of the system architecture manipulated data in units that were 5-bits in length. The limits are also difficult to ascertain because there are unclear boundaries between things that are relevant in our discussion of text and things that are not. For example， the IBM 360-50 reportedly uses 90-bit words in microcode， but that really is not a valid comparison when talking about text.
5	I can explain at this point that by legacy I mean every standard that preceded Unicode.
6	This table represents a working codepage in use in Côte d’Ivoire.
7	This situation is not to be confused with that of a publisher sending an edited and typeset publication to a service bureau. Acrobat was primarily designed for that specific purpose.
8	This model is described in Whistler and Davis (2000) and also in Dürst et al (2001). The model described in UTR#17 includes a fifth level， known as the transfer encoding syntax. This accounts for the use of special encoding formats used in transmission of text data， such as compression schemes. Transfer encoding syntax is not particularly relevant for our purposes here， and so is not discussed further.
9	It should be noted that the term codepage also gets used in some contexts to refer to the next level in the model， the encoding form. This is discussed further in .
10	EUC-TW refers to the EUC encoding used with the CNS 11643-1992 character set. EUC stands for “Extended Unix Code”. In spite of the name， this encoding is used on other platforms as well.
11	The HZ encoding is used for the GB2312-80 character set and is commonly used for Chinese email and in certain other contexts. It is defined in the Internet recommendation RFC 1843.
12	It is for this reason that the concept of distinguishing codepoints in a coded character set from their encoded representation in an encoding form is new to many people.
13	Even Unicode can be encoded in terms of ISO 2022， though I don’t know why anyone would particularly want to do that.
14	Byte order is not an issue for internal memory representation of data since this is always determined by the specific machine architecture. For example， Intel processors use little-endian representation， while Motorola processors use big-endian representation. Of course， if you are writing software for an Intel processor and need to be able to read data files that are encoded using a big-endian encoding scheme， you will need to add a few lines of code to reorder the bytes—unless you are using a library that handles this for you—before you begin processing the character data. This doesn’t happen automatically.
15	In certain computer industry contexts， particularly in relation to the Internet， a technical proposal is often discussed by publication a documents known as an RFC， meaning “request for comments”. These are generally maintained by a oversight body， such as the Internet Engineering Task Force， and are given numerical identifiers. For example， RFC 2822 ( ) is the current specification for the Internet email message protocol.
16	Development of the Unicode standard began by combining all of the industry standard character sets that existed prior to 1991. As a result， all of the legacy industry standard character sets we have been looking at are by definition subsets of the Unicode character set. As a result， it’s possible to think of the Mac Roman codepage， for example， as an encoding form used to represent a subset of the Unicode character set.

 

Backlinks (20 most popular; affiliated sites and popular search engines removed)