UNICODE与UTF-8的转换详解(一)_android_百度空间

一篇详细的汉字编解码方面的文章。

转载自： http:///KnowledgeActionForReader?action=read&id=104

UNICODE与UTF-8的转换详解

1 编码
在计算机中，各种信息都是以二进制编码的形式存在的，也就是说，不管是文字、图形、声音、动画，还是电影等各种信息，在计算机中都是以０和１组成的二进制代码表示的。为了区分这些信息，人们就为计算机设计了一套识别准则，这也就是计算机编码。例如：英文字母与汉字的的区别，就是英文字母用的是单字节的ASCII码，汉字采用的是双字节的汉字内码。
1.1 基本概念
* 字符：字符是抽象的最小文本单位。它没有固定的形状（可能是一个字形），而且没有值。“A”是一个字符，“”（德国、法国和许多其他欧洲国家通用货币的标志）也是一个字符。
* 字符集：字符集是字符的集合。例如，汉字字符是中国人{zx0}发明的字符，在中文、日文、韩文和越南文的书写中使用。
* 编码字符集：编码字符集是一个字符集，它为每一个字符分配一个{wy}数字。Unicode 标准的核心是一个编码字符集，字母“A”的编码为 004116 和字符“”的编码为 20AC16。Unicode 标准始终使用十六进制数字，而且在书写时在前面加上前缀“U+”，所以“A”的编码书写为“U+0041”。
* 代码点：代码点是指可用于编码字符集的数字。编码字符集定义一个有效的代码点范围，但是并不一定将字符分配给所有这些代码点。有效的Unicode代码点范围是 U+0000 至U+10FFFF。Unicode4.0将字符分配给一百多万个代码点中的96,382代码点。
* 增补字符：增补字符是代码点在 U+10000 至 U+10FFFF 范围之间的字符，也就是那些使用原始的Unicode的16 位设计无法表示的字符。从U+0000至 U+FFFF之间的字符集有时候被称为基本多语言面 (BMP)。因此，每一个Unicode 字符要么属于BMP，要么属于增补字符。
* 字符编码方案：字符编码方案是从一个或多个编码字符集到一个或多个固定宽度代码单元序列的映射。最常用的代码单元是字节，但是 16 位或 32 位整数也可用于内部处理。UTF-32、UTF-16 和 UTF-8 是 Unicode 标准的编码字符集的字符编码方案。
* UTF-32：即将每一个 Unicode 代码点表示为相同值的 32 位整数。很明显，它是内部处理最方便的表达方式，但是，如果作为一般字符串表达方式，则要消耗更多的内存。
* UTF-16：使用一个或两个未分配的 16 位代码单元的序列对Unicode代码点进行编码。值U+0000至U+FFFF编码为一个相同值的16位单元。增补字符编码为两个代码单元，{dy}个单元来自于高代理范围（U+D800 至 U+DBFF），第二个单元来自于低代理范围（U+DC00至U+DFFF）。这在概念上可能看起来类似于多字节编码，但是其中有一个重要区别：值 U+D800至U+DFFF 保留用于UTF-16；没有这些值分配字符作为代码点。这意味着，对于一个字符串中的每个单独的代码单元，软件可以识别是否该代码单元表示某个单单元字符，或者是否该代码单元是某个双单元字符的{dy}个或第二单元。这相当于某些传统的多字节字符编码来说是一个显著的改进，在传统的多字节字符编码中，字节值 0x41既可能表示字母“A”，也可能是一个双字节字符的第二个字节。
* UTF-8：使用一至四个字节的序列对编码Unicode代码点进行编码。U+0000至U+007F 使用一个字节编码，U+0080至U+07FF使用两个字节，U+0800至U+FFFF 使用三个字节，而U+10000至U+10FFFF使用四个字节。UTF-8设计原理为：字节值0x00至0x7F 始终表示代码点U+0000至U+007F（Basic Latin 字符子集，它对应 ASCII 字符集）。这些字节值永远不会表示其他代码点，这一特性使UTF-8可以很方便地在软件中将特殊的含义赋予某些ASCII字符。
(表1-1 编码的一些基本概念)
1.2 字符编码
字符编码即英文编码，包括字母、数字、标点、运算符等。
字符的编码采用国际通用的ASCII码（American Standard Code for Information Interchange，美国信息交换标准代码），每个ASCII码以1个字节(Byte)储存，从0到数字127代表不同的常用符号，例如大写A的 ASCII码是65，小写a则是97。由于ASCII码只用了字节的七个位，{zg}位并不使用，所以后来又将{zg}的一个位也编入这套编码码中，成为八个位的延伸ASCII(ExtendedASCII)码，这套内码加上了许多外文和表格等特殊符号，成为目前常用的编码。基本的ASCII字符集共有128个字符，其中有96个可打印字符，包括常用的字母、数字、标点符号等，另外还有32个控制字符。标准ASCII码使用7个二进位对字符进行编码，对应的ISO 标准为ISO646标准。
字母和数字的ASCII码的记忆是非常简单的。我们只要记住了一个字母或数字的ASCII码（例如记住A为65，0的ASCII码为48），知道相应的大小写字母之间差32，就可以推算出其余字母、数字的ASCII码。
虽然标准ASCII码是7位编码，但由于计算机基本处理单位为字节（1byte = 8bit），所以一般仍以一个字节来存放一个ASCII字符。每一个字节中多余出来的一位（{zg}位）在计算机内部通常保持为0（在数据传输时可用作奇偶校验位）。由于标准ASCII字符集字符数目有限，在实际应用中往往无法满足要求。为此，国际标准化组织又制定了ISO2022标准，它规定了在保持与 ISO646兼容的前提下将ASCII字符集扩充为8位代码的统一方法。ISO陆续制定了一批适用于不同地区的扩充ASCII字符集，每种扩充ASCII 字符集分别可以扩充128个字符，这些扩充字符的编码均为高位为1的8位代码（即十进制数128~255），称为扩展ASCII码。
1.3 汉字编码
1.3.1 汉字内码
汉字信息在计算机内部也是以二进制方式存放。由于汉字数量多，用一个字节的128种状态不能全部表示出来，因此在1980年我国颁布的《信息交换用汉字编码字符集——基本集》，即国家标准GB2312-80方案中规定用两个字节的十六位二进制表示一个汉字，每个字节都只使用低7位（与ASCII码相同），即有128×128=16384种状态。由于ASCII码的34个控制代码在汉字系统中也要使用，为不致发生冲突，不能作为汉字编码，128除去34只剩 94种，所以汉字编码表的大小是94×94=8836，用以表示国标码规定的7445个汉字和图形符号。
每个汉字或图形符号分别用两位的十进制区码（行码）和两位的十进制位码（列码）表示，不足的地方补０，组合起来就是区位码。把区位码按一定的规则转换成的二进制代码叫做信息交换码（简称国标码）。国标码共有汉字6763个（一级汉字，是最常用的汉字，按汉语拼音字母顺序排列，共3755个；二级汉字，属于次常用汉字，按偏旁部首的笔划顺序排列，共3008个），数字、字母、符号等682个，共7445个。
由于国标码不能直接存储在计算机内，为方便计算机内部处理和存储汉字，又区别于ASCII码，将国标码中的每个字节在{zg}位改设为1，这样就形成了在计算机内部用来进行汉字的存储、运算的编码叫机内码（或汉字内码，或内码）。内码既与国标码有简单的对应关系，易于转换，又与ASCII码有明显的区别，且有统一的标准（内码是惟一的）。
1.3.2 汉字外码
无论是区位码或国标码都不利于输入汉字，为方便汉字的输入而制定的汉字编码，称为汉字输入码，即汉字外码。不同的输入方法，形成了不同的汉字外码。常见的输入法有以下几类：
* 按汉字的排列顺序形成的编码（流水码）：如区位码；
* 按汉字的读音形成的编码（音码）：如全拼、简拼、双拼等；
* 按汉字的字形形成的编码（形码）：如五笔字型、郑码等；
* 按汉字的音、形结合形成的编码（音形码）：如自然码、智能ABC。
* 输入码在计算机中必须转换成机内码，才能进行存储和处理。
(表1-2 常见的输入法)
1.3.3 汉字字形码
为了将汉字在显示器或打印机上输出，把汉字按图形符号设计成点阵图，就得到了相应的点阵代码（字形码）。
全部汉字字码的集合叫汉字字库。汉字库可分为软字库和硬字库。软字库以文件的形式存放在硬盘上，现多用这种方式，硬字库则将字库固化在一个单独的存储芯片中，再和其它必要的器件组成接口卡，插接在计算机上，通常称为汉卡。
用于显示的字库叫显示字库。显示一个汉字一般采用16×16点阵或24×24点阵或48×48点阵。已知汉字点阵的大小，可以计算出存储一个汉字所需占用的字节空间。例：用16×16点阵表示一个汉字，就是将每个汉字用16行，每行16个点表示，一个点需要1位二进制代码，16个点需用16位二进制代码（即2个字节），共16行，所以需要16行×2字节/行=32字节，即16×16点阵表示一个汉字，字形码需用32字节。即：字节数 = 点阵行数 * 点阵列数 / 8。
用于打印的字库叫打印字库，其中的汉字比显示字库多，而且工作时也不像显示字库需调入内存。可以这样理解，为在计算机内表示汉字而统一的编码方式形成汉字编码叫内码（如国标码），内码是惟一的。为方便汉字输入而形成的汉字编码为输入码，属于汉字的外码，输入码因编码方式不同而不同，是多种多样的。为显示和打印输出汉字而形成的汉字编码为字形码，计算机通过汉字内码在字模库中找出汉字的字形码，实现其转换。例如：
1：已知汉字"春"的国标码为343AH，求其机内码？
答：机内码 = 国标码 + 8080H = 343AH + 8080H = B4BAH

2：用24×24点阵来表示一个汉字（一点为一个二进制位），则2000个汉字需要多少KB容量？
答： 容量 = （24 * 24/8）* 2000 / 1024 = 140.7KB ≈ 141KB
(表1-3 汉字内码与字形码的转换实例)
2 UNICODE编码
Unicode 是基于通用字符集（Universal Character Set）的标准来发展，并且同时也以书本的形式（The Unicode Standard，目前第五版由Addison-Wesley Professional出版，ISBN-10: 0321480910）对外发表。Unicode包含了超过十万个字符（在2005年，Unicode的第十万个字符被采纳且认可成为标准之一）、一组可用以作为视觉参考的代码图表、一套编码方法与一组标准字符编码、一套包含了上标字、下标字等字符特性的列举等。
在计算机科学领域中，Unicode（统一码、万国码、单一码、标准万国码）是业界的一种标准，它可以使电脑得以呈现世界上数十种文字的系统。Unicode组织（The Unicode Consortium）是由一个非营利性的机构所运作，并主导Unicode的后续发展，其目标在于：将既有的字符编码方案，以Unicode编码方案来加以取代，特别是既有的方案在多语环境下，皆仅有有限的空间以及不相容的问题。
Unicode在字符集认可的成功，使其得以在电脑软件的国际化与本地化领域中，广泛且具优势的被采用。这标准已在近年来的多种新科技当中被加以采用，包含了可扩展置标语言（XML）、Java编程语言、以及{zx1}的操作系统中。
2.2 UNICODE的起源与发展
Unicode是由于传统的字符编码方式的局限性而产生的，例如 ISO 8859所定义的字符虽然在不同的国家中广泛地使用，可是在不同国家间却经常出现不相容的情况。很多传统的编码方式都具有一个共通的问题，即其容许电脑进行双语环境式的处理（通常使用拉丁字母以及其本地语言），但却无法同时支援多语言环境式的处理（指可同时处理混合多种语言的情况）。
Unicode试图将字位（字素，graphemes）与类字位字符加以认定与编码，而非以不同的字形（glyphs）来加以区分。然而在汉字的个案来看，这样方式有时会引起一字多形的认定争议（详见中日韩统一表意文字主题）。
在文字处理方面，Unicode的功用是为每一个字符提供一个{wy}的代码（即一组数字），而不是一种字形。换句话说，Unicode是将字符以一种抽象的方式来呈现，而将视觉上的演绎工作（例如字体大小、外观形状、字体形态、文体等）留给其他软件来处理，例如网页浏览器或是文字处理器。
为了使Unicode与已存在和广泛使用的旧有编码互相兼容，尤其是差不多所有电脑系统都支援的基本拉丁字母部分，所以Unicode的首256字符仍旧保留给ISO 8859-1所定义的字符，使既有的西欧语系文字的转换不需特别考量；另方面因相同的原因，Unicode 把大量相同的字符重复编到不同的字符码中去，使得旧有纷杂的编码方式得以和 Unicode 编码间互相直接转换，而不会遗失任何资讯。举例来说，全角格式区段包含了主要的拉丁字母的全角格式，在中文、日文、以及韩文字形当中，这些字符以全角的方式来呈现，而不以常见的半角形式显示，这对竖排文字和等宽排列文字有重要作用。
Unicode组织位于美国加州，组织允许任何愿意支付会员费用的公司或是个人加入，其成员包含了主要的电脑软硬件厂商，例如奥多比系统（Adobe Systems）、苹果公司（Apple）、惠普（HP）、IBM、微软（Microsoft）、全录（Xerox）等。Unicode 组织在 1991 年首次发布了 The Unicode Standard（ISBN 0-321-18578-1）。Unicode的开发结合了国际标准化组织（International Organization for Standardization，简称 ISO）所制定的ISO/IEC 10646，即通用字符集（Universal Character Set，简称 UCS）。Unicode 与 ISO/IEC 10646 在编码的运作原理相同，但 The Unicode Standard 包含了更详尽的实现资讯、涵盖了更细节的主题，诸如字符编码（bitwise encoding）、校对以及呈现等。 The Unicode Standard 也列举了诸多的字符特性，包含了那些必须支援双方向呈现的文字（由左至右或由右至左的文字呈现方向，例如阿拉伯文是由右至左）。Unicode与 ISO/IEC 10646两个标准在术语上的使用有些微的不同。
Unicode截至目前为止历次的版次与发布时间如下：
Unicode 1.0：1991年10月；
Unicode 1.0.1：1992年6月；
Unicode 1.1：1993年6月；
Unicode 2.0：1997年7月；
Unicode 2.1：1998年5月；
Unicode 2.1.2：1998年5月；
Unicode 3.0：1999年9月；涵盖了来自ISO 10646-1的十六位元通用字符集（UCS）基本多文种平面（Basic Multilingual Plane）；
Unicode 3.1：2001年3月；新增从ISO 10646-2定义的辅助平面（Supplementary Planes）；
Unicode 3.2：2002年3月；
Unicode 4.0：2003年4月；
Unicode 4.0.1：2004年3月；
Unicode 4.1：2005年3月；
Unicode 5.0：2006年7月；
Unicode 5.1：2008年4月。
(表2-1 unicode编码的版次与发布时间)
2.3 Unicode 的编码和实现
2.3.1 编码方式
Unicode 的编码方式与 ISO 10646 的通用字符集（Universal Character Set，UCS）概念相对应，目前实际应用的 Unicode 版本对应于 UCS-2，使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示 216 即 65536 个字符。基本满足各种语言的使用。实际上目前版本的 Unicode 尚未填充满这16位编码，保留了大量空间作为特殊使用或将来扩展。
上述16位Unicode字符构成基本多文种平面（Basic Multilingual Plane，简称BMP）。{zx1}（但未实际广泛使用）的Unicode 版本定义了16个辅助平面，两者合起来至少需要占据21位的编码空间，比3字节略少。但事实上辅助平面字符仍然占用4字节编码空间，与UCS-4保持一致。未来版本会扩充到 ISO 10646-1 实现级别3，即涵盖UCS-4的所有字符。UCS-4 是一个更大的尚未填充wq的31位字符集，加上恒为0的sw，共需占据32位，即4字节。理论上最多能表示231个字符，wq可以涵盖一切语言所用的符号。
BMP字符的Unicode编码表示为 U+hhhh，其中每个 h 代表一个十六进制数位。与UCS-2编码wq相同。对应的4字节UCS-4编码后两个字节一致，前两个字节的所有位均为0。
2.3.2 实现方式
Unicode的实现方式不同于编码方式。一个字符的Unicode 编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。 Unicode的实现方式称为Unicode转换格式（Unicode Translation Format，简称为 UTF）。
例如，如果一个仅包含基本7位ASCII字符的Unicode文件，如果每个字符都使用2字节的原Unicode 编码传输，其{dy}字节的8位始终为0。这就造成了比较大的浪费。对于这种情况，可以使用 UTF-8 编码，这是一种变长编码，它将基本7位ASCII字符仍用7位编码表示，占用一个字节（sw补0）。而遇到与其他 Unicode 字符混合的情况，将按一定算法转换，每个字符使用1-3个字节编码，并利用sw为0或1进行识别。这样对以7位ASCII字符为主的西文文档就大大节省了编码长度。类似的，对未来会出现的需要4个字节的辅助平面字符和其他 UCS-4 扩充字符，2字节编码的UTF-16也需要通过一定的算法进行转换。
再如，如果直接使用与Unicode编码一致（jx于 BMP 字符）的UTF-16编码，由于每个字符占用了两个字节，在Macintosh机和PC机上，对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容，如编码为U+594E的字符“奎”同编码为 U+4E59 的“乙”就可能发生混淆。于是在UTF-16编码实现方式中使用了大尾序（big-endian）、小尾序（little-endian）的概念，以及 BOM（Byte Order Mark）解决方案。
此外 Unicode 的实现方式还包括UTF-7、Punycode、CESU-8、SCSU、UTF-32等，这些实现方式有些仅在一定的国家和地区使用，有些则属于未来的规划方式。目前通用的实现方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微软公司Windows XP操作系统附带的记事本中，“另存为”对话框可以选择的四种编码方式除去非 Unicode 编码的 ANSI 外，其余三种“Unicode”、“Unicode big endian”和“UTF-8”即分别对应这三种实现方式。

3 UTF-8
UTF是UCS / Unicode Transformation Format（Unicode转换格式）的缩写，UTF-8（8位元Universal Character Set／Unicode Transformation Format）是一种针对 Unicode 的可变长度字符编码。它可以用来表示 Unicode 标准中的任何字符，且其编码中的{dy}个字节仍与ASCII相容，这使得原来处理ASCII字符的软件无须或只须做少部份修改，即可继续使用。因此，它逐渐成为电子邮件、网页及其他储存或传送文字的应用中，优先采用的编码。
3.1 UTF-8的历史
1992年初，为建立良好的字节串编码系统（byte-stream encoding）以供多字节字符集（multi-byte character sets）使用，开始了一个正式的研究。ISO/IEC 10646的初稿中有一个非必须的附录，名为UTF。当中包含了一个供32位元的字符使用的字节串编码系统。这个编码方式的性能并不令人满意，但它提出了将0-127的范围保留给ASCII以相容旧系统的概念。
1992年7月，X/Open委员会XoJIG开始寻求一个较佳的编码系统。Unix系统实验室（UNIX System Laboratories, USL）的Dave Prosser为此提出了一个编码系统的建议。它具备可更快速实作的特性，并引入一项新的改进。其中，7位元的ASCII符号只代表原来的意思，所有多字节序列则会包含第8位元的符号，也就是所谓的{zg}有效位元（Most significant bit）。
1992年8月，这个建议由IBMX/Open的代表流传到一些感兴趣的团体。与此同时，贝尔实验室Plan 9操作系统工作小组的肯·汤普逊对这编码系统作出重大的修改，让编码可以自我同步（self-synchronizing），使得不必从字串的开首读取，也能找出字符间的分界。1992年9月2日，肯·汤普逊和Rob Pike一起在美国新泽西州一架餐车的餐桌垫上描绘出此设计的要点。接下来的日子，Pike及汤普逊将它实现，并将这编码系统wq应用在Plan 9当中，及后他将有关成果回馈X/Open。
1993年1月25-29日的在圣地牙哥举行的USENIX会议首次正式介绍UTF-8。
自1996年起，微软的CAB（MS Cabinet）规格在UTF-8标准正式落实前就明确容许在任何地方使用UTF-8编码系统。但有关的编码器实际上从来没有实作这方面的规格。
3.2 UTF-8的优缺点
3.2.1 UTF-8的特质
UTF-8的设计有以下的多字符组序列的特质：
?单字节字符的{zg}有效位元永远为0；
?多字节序列中的{sg}字符组的几个{zg}有效位元决定了序列的长度。{zg}有效位为110的，是2字节序列，而1110的是三字节序列，如此类推；
?多字节序列中其余的字节中的首两个{zg}有效位元为10。
(表3-1 UTF-8的特质)
UTF-8的这些特质，保证了一个字符的字节序列不会包含在另一个字符的字节序列中。这确保了以字节为基础的部份字串比对（sub-string match）方法可以适用于在文字中搜寻字或词。有些比较旧的可变长度8位元编码（如Shift JIS）没有这个特质，故字串比对的算法变得相当复杂。虽然这增加了UTF-8编码的字串的信息冗余，但是利多于弊。另外，资料压缩并非Unicode的目的，所以不可混为一谈。即使在传送过程中有部份字节因错误或干扰而wq遗失，还是有可能在下一个字符的起点重新同步，令受损范围受到限制。
另一方面，由于其字节序列设计，如果一个疑似为字符串的序列被验证为UTF-8编码，那么我们可以有把握地说它是UTF-8字符串。一段两字节随机序列碰巧为合法的UTF-8而非ASCII 的机率为32分1。对于三字节序列的机率为256分3，对更长的序列的机率就更低了。
3.2.2 UTF-8的优点
UTF-8编码可以通过屏蔽位和移位操作快速读写。字符串比较时 strcmp()和wcscmp()的返回结果相同，因此使排序变得更加容易。字节FF和FE在UTF-8编码中永远不会出现，因此他们可以用来表明 UTF-16或UTF-32文本（见BOM） UTF-8 是字节顺序无关的。它的字节顺序在所有系统中都是一样的，因此它实际上并不需要BOM。
UTF-8是ASCII的一个超集。因为一个纯ASCII字符串也是一个合法的UTF-8字符串，所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用；
使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。（尽管这只有有限的有用性，因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序）；
UTF-8和UTF-16都是可扩展标记语言文档的标准编码，所有其它编码都必须通过显式或文本声明来指定；
任何面向字节的字符串搜索算法都可以用于UTF-8的数据（只要输入仅由完整的UTF-8字符组成）。但是，对于包含字符记数的正则表达式或其它结构必须小心。
UTF-8字符串可以由一个简单的算法可靠地识别出来。就是:一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低，并随字符串长度增长而减小。举例说，字符值C0,C1,F5至FF从来没有出现。为了更好的可靠性，可以使用正则表达式来统计非法过长和替代值（可以查看W3 FAQ: Multilingual Forms上的验证UTF-8字符串的正则表达式）。
3.2.3 UTF-8的缺点
A 不利于正则表达式检索，正则表达式可以进行很多英文高级的模糊检索。例如，[a-h]表示a到h间所有字母。同样GBK编码的中文也可以这样利用正则表达式，比如在只知道一个字的读音而不知道怎么写的情况下，也可用正则表达式检索，因为GBK编码是按读音排序的。只是UTF-8不是按读音排序的，所以会对正则表达式检索造成不利影响。但是这种使用方式并未考虑中文中的破音字，因此影响不大。Unicode是按部首排序的，因此在只知道一个字的部首而不知道如何发音的情况下，UTF-8 可用正则表达式检索而GBK不行。
B 你无法从UNICODE字符数判断出UTF-8文本的字节数，因为UTF-8是一种变长编码它需要用2个字节编码那些用扩展ASCII字符集只需1个字节的字符 ISO Latin-1 是UNICODE的子集，但不是UTF-8的子集 8位字符的UTF-8编码会被email网关过滤，因为internet信息最初设计为7为ASCII码。因此产生了UTF-7编码。UTF-8 在它的表示中使用值100xxxxx的几率超过50%，而现存的实现如ISO 2022，4873，6429，和8859系统，会把它错认为是C1 控制码。因此产生了UTF-7.5编码。
一份写得很差（并且与当前标准的版本不兼容）的UTF-8解析器可能会接受一些不同的伪UTF-8表示并将它们转换到相同的Unicode输出上。这为设计用于处理八位表示的校验例程提供了一种遗漏信息的方式。
C 占据空间大，与其他 Unicode 编码相比，特别是UTF-16，在 UTF-8 中 ASCII 字符占用的空间只有一半，可是在一些字符的 UTF-8 编码占用的空间就要多出，特别是中文、日文和韩文（CJK）这样的象形文字，所以具体因素因文档而异，但不论哪种情况，差别都不可能很明显。