字符编码--第3章 字符的存储--EUC

第2节 EUC

EUC全名为Extended Unix Code，是一个使用8位编码来表示字符的方法。EUC最初是针对Unix系统，由一些Unix公司所开发，于1991年标准化。EUC基于ISO/IEC 2022的7位编码标准，因此单字节的编码空间为94，双字节的编码空间（区位码）为94x94。把每个区位加上0xA0来表示，以便符合ISO 2022。它主要用于表示及储存汉语文字、日语文字及朝鲜文字。

EUC定义了4个单独的码集（code set）。码集0总是对应于7位的ASCII（或其它的各国定义的ISO 646），包括了ISO 2022定义的C0与G0空间的值。码集1, 2, 3表示G1空间的值。其中，码集1表示一些未经修饰（unadorned）的字符。码集2的字符编码以0x8E（属于C1控制字符，或称SS2）为第一字节。码集3的字符编码以0x8F（另一个属于C1的控制字符，或称SS3）为第一字节。码集0总是编码为单字节；码集2、3总是编码为至少2个字节；码集1编码为1-3个字节。

 

1.EUC-CN

EUC-CN是GB 2312最常用的表示方法。浏览器编码表上的“GB2312”，通常都是指“EUC-CN”表示法。

ASCII字符，范围为0x21-0x7E，直接用单字节表示。这是码集0。

GB 2312字元使用两个字节来表示。这是码集1。

“第一位字节”使用0xA1-0xF7“，第二位字节”使用0xA1-0xFE。

GB2312没有使用码集2、码集3部分。

举例来说，“啊”字是GB 2312之中的第一个汉字，它的区位码是1601。在EUC-CN之中，它把0xA0+16=0xB0,0xA0+1=0xA1，得出0xB0A1。

 

2.EUC-JP

EUC-JP用来储存日本JIS X 0208（旧称JIS C 6226）及JIS X 0212字集的字符，主要影响了类Unix操作系统的日文表示与处理。但是，日文Windows操作系统较多使用ISO-2022-JP或Shift JIS的方法来表示。

ASCII字符，范围为0x21-0x7E，直接用单字节表示。这是码集0。

半角片假名使用两个字节来表示。这是码集2。

“第一位字节”使用0x8E“，第二位字节”使用0xA1-0xDF。

JIS X 0208字元使用两个字节来表示。这是码集1。

“第一位字节”使用0xA1-0xFE，“第二位字节”使用0xA1-0xFE。

JIS X 0212字元使用三个字节来表示。这是码集3。

“第一位字节”使用0x8F，“第二位字节”使用0xA1-0xFE，“第三位字节”使用0xA1-0xFE。

 

EUC-JISX0213

EUC-JISX0213是一个制定中的EUC规格，用来表示JIS X 0213字集的字符。

半角片假名使用两个字节来表示。

“第一位字节”使用0x8E“第二位字节”使用0xA1-0xDF

JIS X 0213第一字面字元使用两个字节来表示。

“第一位字节”使用0xA1-0xFE“第二位字节”使用0xA1-0xFE

JIS X 0213第二字面字元使用三个字节来表示。

“第一位字节”使用0x8F“第二位字节”使用0xA1-0xFE“第三位字节”使用0xA1-0xFE

 

3.EUC-KR

EUC-KR用来储存韩国KS X 1001字集（旧称KS C 5601）的字符。此规格由KS X 2901（旧称KS C 5861）定义。

KS X 1001字元使用两个字节来表示。

“高位字节”使用0xA1-0xFE“低位字节”使用0xA1-0xFE

 

4.EUC-TW

EUC-TW为台湾使用的汉字编码方法之一，以CNS 11643字表为基础；但是台湾普遍使用大五码，EUC-TW甚少使用。

CNS 11643第一字面的字元使用两个字节来表示。

“第一位字节”使用0xA1-0xFE“第二位字节”使用0xA1-0xFE

CNS 11643其他字面的字元使用四个字节来表示。

“第一位字节”使用0x8E“第二位字节”使用0xA1-0xB0（0xA1-0xA7分别代表第1至第7个字面，其余未定义）“第三位字节”使用0xA1-0xFE“第四位字节”使用0xA1-0xFE

（CNS 11643第一字面可选择使用两个字节或四个字节来表示）

 

第3节 GB 2312

GB 2312标准共收录6763个汉字，其中一级汉字3755个，二级汉字3008个；同时收录了包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的682个字符。

GB 2312的出现，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。但对于人名、古汉语等方面出现的罕用字和繁体字，GB 2312不能处理，因此后来GBK及GB 18030汉字字符集相继出现以解决这些问题。

 

分区表示

GB 2312中对所收汉字进行了“分区”处理，每区含有94个汉字／符号。这种表示方式也称为区位码。

01-09区为特殊符号。

16-55区为一级汉字，按拼音排序。

56-87区为二级汉字，按部首／笔画排序。

10-15区及88-94区则未有编码。

举例来说，“啊”字是GB2312之中的第一个汉字，它的区位码就是1601。

 

字节结构

在使用GB2312的程序通常采用EUC储存方法，以便兼容于ASCII。浏览器编码表上的“GB2312”，通常都是指“EUC-CN”表示法。每个汉字及符号以两个字节来表示。第一个字节称为“高位字节”，第二个字节称为“低位字节”。“高位字节”使用了0xA1-0xF7（把01-87区的区号加上0xA0），“低位字节”使用了0xA1-0xFE（把01-94加上0xA0）。 由于一级汉字从16区起始，汉字区的“高位字节”的范围是0xB0-0xF7，“低位字节”的范围是0xA1-0xFE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

例如“啊”字在大多数程序中，会以两个字节，0xB0（第一个字节）0xA1（第二个字节）储存。（与区位码对比：0xB0=0xA0+16,0xA1=0xA0+1）。

对“不规范简化字”和繁体字的收录

收了两个不合乎中华人民共和国标准的简化字： 渖（68-41）：由“审[審]”类推简化而来，但《简化字总表》已将“瀋”简化归并为“沈”。旧版《新华字典》收有此字，释为“汁”；新版取消，并入“沈”。镟（79-64）：由“钅[釒]”类推简化而来，但《简化字总表》已将“鏇”简化归并为“旋”。

收了两个繁体字： 鍾（79-81）：原版收入使用繁体偏旁之“鍾”字，但《简化字总表》已将“鍾”和“鐘”简化归并为“钟”；后续的字模附录将之修正为“锺”（下详）。

後（65-65）：该繁体字已经在《简化字总表》简化成“后”（26-83）字，而且没有说明在语义不清时用“後”来表示，可是GB2312却多收此字。

 

修订

GB 5007.1-85《信息交换用汉字 24x24 点阵字模集》首次附录对 GB 2312 之更正，包括：

调整拉丁字母“g”之字形

补充六个拼音符号 ɑḿńňǹɡ

补充94个半字图形字符（第3区之半形版本，相当于 GB 1988）

“鍾”更正为“锺”

另建议于第11区加入第8区首32个拼音符号（包括以上补充六个）之半形版本。

GB2312 本身一直未有修订，但此等修订部份收入相关字模集（下详）、GB 12345、后续之 GBK 及 GB 18030。

GB2312 亦用于 ISO-IR-165。

字模集

GB 5007.1-85《信息交换用汉字 24x24 点阵字模集》

GB 5007.2-85《信息交换用汉字 24x24 点阵字模数据集》

GB 5199.1-85《信息交换用汉字 15x16 点阵字模集》

GB 5199.2-85《信息交换用汉字 15x16 点阵字模数据集》

GB 6345.1-86《信息交换用汉字 32x32 点阵字模集》

GB 6345.2-86《信息交换用汉字 32x32 点阵字模数据集》

GB 12034-89《信息交换用汉字 32x32 点阵仿宋体字模集及数据集》

GB 12035-89《信息交换用汉字 32x32 点阵楷体字模集及数据集》

GB 12036-89《信息交换用汉字 32x32 点阵黑体字模集及数据集》

GB 12037-89《信息交换用汉字 36x36 点阵宋体字模集及数据集》

GB 12038-89《信息交换用汉字 36x36 点阵仿宋体字模集及数据集》

GB 12039-89《信息交换用汉字 36x36 点阵楷体字模集及数据集》

GB 12040-89《信息交换用汉字 36x36 点阵黑体字模集及数据集》

GB 12041-89《信息交换用汉字 48x48 点阵宋体字模集及数据集》

GB 12042-89《信息交换用汉字 48x48 点阵仿宋体字模集及数据集》

GB 12043-89《信息交换用汉字 48x48 点阵楷体字模集及数据集》

GB 12044-89《信息交换用汉字 48x48 点阵黑体字模集及数据集》

GB/T 13443-92《信息交换用汉字 128x128 点阵楷体字模集及数据集》

GB/T 13444-92《信息交换用汉字 128x128 点阵仿宋体字模集及数据集》

GB/T 13445-92《信息交换用汉字 256x256 点阵楷体字模集及数据集》

GB/T 13446-92《信息交换用汉字 256x256 点阵仿宋体字模集及数据集》

GB/T 13844-92《图形信息交换用矢量汉字单线宋体字模集及数据集》

GB/T 13845-92《图形信息交换用矢量汉字宋体字模集及数据集》

GB/T 13846-92《图形信息交换用矢量汉字仿宋体字模集及数据集》

GB/T 13847-92《图形信息交换用矢量汉字楷体字模集及数据集》

GB/T 13848-92《图形信息交换用矢量汉字黑体字模集及数据集》

 

第4节 GBK 汉字内码扩展规范

GBK即汉字内码扩展规范，K为汉语拼音 Kuo Zhan（扩展）中“扩”字的声母。英文全称Chinese Internal Code Specification。

历史

1993年，Unicode 1.1版本推出，收录中国大陆、台湾、日本及韩国通用字符集的汉字，总共有20,902个。中国大陆订定了等同于Unicode 1.1版本的“GB 13000.1-93”“信息技术通用多八位编码字符集（UCS）第一部分：体系结构与基本多文种平面”。由于GB 2312-80只收录6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如“啰”），部分人名用字（如中国前总理朱镕基的“镕”字），台湾及香港使用的繁体字，日语及朝鲜语汉字等，并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间，收录GB 13000.1-93全部字符制定了GBK编码。

根据微软资料，GBK是对GB2312-80的扩展，也就是CP936字码表 (Code Page 936)的扩展（之前CP936和GB 2312-80一模一样），最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符，但编码方式并不相同。

GBK自身并非国家标准，只是曾由国家技术监督局标准化司、电子工业部科技与质量监督司公布为“技术规范指导性文件”。原始GB13000一直未被业界采用，后续国家标准GB18030技术上兼容GBK而非GB13000。

编码方式

字符有一字节和双字节编码，00–7F范围内是第一个字节，和ASCII保持一致，此范围内严格上说有96个文字和32个控制符号。

之后的双字节中，前一字节是双字节的第一位。总体上说第一字节的范围是81–FE（也就是不含80和FF），第二字节的一部分领域在40–7E，其他领域在80–FE。

与其他编码的关系

GBK向下完全兼容GB2312-80编码。 支持GB2312-80编码不支持的部分中文姓，中文繁体，日文假名，还包括希腊字母以及俄语字母等字母。不过这种编码不支持韩国字，也是其在实际使用中与unicode编码相比欠缺的部分。

上述GBK/1和GBK/2的领域即GB 2312-80用通常方法编码的区域。GB 2312 (正确说法是其根据EUC-CN的编码)和ISO/IEC 2022中调用GR其他的94² 字符集一样，A1–FE的范围开始读取字节对。这是上图中右下角的部分。但是，GB 2312中对于AA–AF和F8–FE区域是空的，没有赋予编码。于是GBK就在这些领域里进行拓展。二者剩余部分作为用户定义区。

更重要的是，GBK进行了字节范围的扩展。ISO/IEC 2022中GR区域的字数有94²=8,836字的限制。只要放弃ISO/IEC 2022中针对图形文字和控制文字赋予严格的范围的模式，下位字节为单字节文字，上位字节对保留对应字符的功能，潜在的128²=16,384的代码位置就可以使用。GBK采用其中的一部分，第一个字节从A1–FE (每个字节有94个选项)扩展成81–FE (126个选项) ，第二字节的范围是 40–FE (191个选项) ，总共有24066(126*191)个位置。

 

与CP936字码表比较

微软的CP936通常被视为等同GBK，连 IANA 也以“CP936”为“GBK”之别名。事实上比较起来， GBK 定义之字符较 CP936 多出95字（15个非汉字及80个汉字），皆为其时未收入 ISO 10646 / Unicode 之符号：非汉字包括异体字符号、十二个表意文字描述字元（Ideographic Description Characters）及 GB 5007.1-85《信息交换用汉字 24x24 点阵字模集》附录对 GB 2312 增加，但 Unicode 未收之拼音符号“ḿ”和“ǹ”；汉字包括未收入 ISO 10646 的《简化字总表》汉字52个、《康熙字典》及《辞海》汉字部件28个。CP936中的这95字分配到了Unicode的私有区域，现已全部收于新版 Unicode。

输入方法

VimIM 在 Vim 环境中，可以直接键入十进制或十六进制 GBK 码。既不需要启动输入法，也不需要码表。

后续

中华人民共和国国家质量技术监督局于2000年3月17日推出了GB 18030-2000标准，以取代GBK。GB 18030-2000除保留全部GBK编码汉字，在第二字节把能使用范围再度进行扩展，增加了大约一百个汉字及四位元组编码空间，但是将GBK作为子集全部保留。请参看GB 18030。

 

代码页936

代码页936（Codepage 936）是 Microsoft 的简体中文字元集标准，是东亚语文的四种双位元组字元集 (DBCS) 之一。其最初版本和 GB 2312 一模一样，但在推出 Windows 95 时扩展成包含绝大部份的 GBK 字元（代码页936 比 GBK 少95个字元，皆为当时尚未收入 Unicode 的字元）；虽然该等字元现在已全部收入 Unicode，但代码页936 至今都没有修订。现在要求所有软件都要支持 GB 18030（Microsoft 称之为代码页54936）。

 

第5节 GB 18030

GB 18030，全称：国家标准GB 18030-2005《信息技术　中文编码字符集》，是中华人民共和国现时最新的内码字集，是GB 18030-2000《信息技术　信息交换用汉字编码字符集　基本集的扩充》的修订版。与GB 2312-1980完全兼容，与GBK基本兼容，支持GB 13000及Unicode的全部统一汉字，共收录汉字70244个。

 

GB 18030主要有以下特点：

代码页 54936

与 UTF-8 相同，采用多字节编码，每个字可以由1个、2个或4个字节组成。

编码空间庞大，最多可定义161万个字元。

支持中国国内少数民族的文字，不需要动用造字区。

汉字收录范围包含繁体汉字以及日韩汉字。

本规格的初版是由中华人民共和国信息产业部电子工业标准化研究所起草，由国家质量技术监督局于2000年3月17日发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于2005年11月8日发布，2006年5月1日实施。

此标准内的单字节编码部分、双字节编码部分，和四字节编码部分收录的中日韩统一表意文字扩展A区汉字，为强制性标准。其他部分则属于规模性标准。在中华人民共和国境内所有软件产品，都需要支持这个同时包含单字节、双字节和四字节编码的规格。

 

字节结构

单字节，其值从0到0x7F。

双字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x40到0xFE（不包括0x7F）。

四字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x30到0x39，第三个字节从0x81到0xFE，第四个字节从0x30到0x39。

 

版本

GB 18030-2000，兼容 Unicode 3.0 中日韩统一表意文字，共收27533个汉字；2000年3月17日发布

GB 18030-2005，更新至 Unicode 3.1 中日韩统一表意文字及增加少数民族文字，共有70244个汉字；2005年11月8日发布、2006年5月1日实施

 

代码页54936

 

 

 

第6节 CJK 中日韩统一表意文字

中日韩统一表意文字（英语：CJK Unified Ideographs），也称统一汉字（英语：Unihan），目的是要把分别来自中文、日文、韩文、越南文、壮文中，起源相同、本义相同、形状一样或稍异的表意文字，赋予其在ISO 10646及万国码标准中相同编码。

所谓“起源相同、本义相同、形状一样或稍异的表意文字”，主要为汉字，包括繁体字、简体字、日本汉字（漢字／かんじ）、韩国汉字（漢字／한자）、越南的喃字（喃／Chữ Nôm）与儒字（儒／Chữ Nho）、方块壮字。

此计划原本只包含中文、日文及韩文中所使用的汉字，旧称中日韩（CJK）统一表意文字（Unified Ideographs）。后来，此计划加入了越南文的喃字，所以合称中日韩越（CJKV）统一表意文字。

历史

1978年，日本基于ISO 2022，制订了全世界最早的汉字编码JIS C 6226。1980年代，中国大陆、台湾、韩国则各自制订了自己的规范。这些规范彼此之间并无关联。若要在一份文件中同时使用，则要以脱序字符的方式来交换。

1980年，日本的国立国会图书馆的高桥德太郎以图书学的观点指出，一个统一的东亚汉字编码系统是有必要的。同年，台湾制定了三位元组的中文资讯交换码。偶然的是，这是第一个期望可以一致处理中国大陆、日本、台湾汉字的编码。之后，美国的国会图书馆采用了此规格，并另外命名为东亚编码字符（East Asia Coded Character，EACC，ANSI/NISO Z39.64）。

1984年，ISO的文字编码委员会（ISO/TC 97/SC2）决议制订出一套编码规格（ISO 10646），是以交换文字集的方式来统一处理世界的文字。并成立了工作小组（ISO/TC 97/SC 2/ WG 2）。这个编码一开始的构想是采用16位元，而对于日本及中国等国的汉字编码则原封不动地加入。但若如此，中国当时所制订的编码都无法加入，因而反对。并于1989年，提出了各国的汉字统合集合（Han Character Collection，HCC）的构想。

1990年完成了ISO 10646的初版草案（DIS 10646）。汉字使用32位元来表示。并将各国的汉字编码原封不动地加入。但中国认为，若各国各自为汉字编码，将不利于统一处理汉字，因而反对。为了日后关于汉字编码的讨论及方针能顺利进行，并呼吁WG 2特别设置了中日韩联合研究小组（CJK-JRG，Joint Research Group，为表意文字小组的前身），以持续讨论。

另一方面，1987年，全录的Joe Becker和Lee Collins开发了统合处理全世界所有文字的统一码。1989年发表了统一码概要。基本为16位元。于是，中、日、韩文字统合了。基本方针为以16位元处理所有文字。 1990年，完成了基于此方针的最终草案。隔年1991年1月，大致同意此方案的企业成立了统一码联盟。中、日、韩中类似的汉字使用约二万多个字。为了未来扩充，保留了三万个汉字以供其它用途。

1991年，各国希望能以一致的方式处理文字，如统一码这般，因而否决了ISO/IEC 10646的初版草案。基于中国与统一码联盟的提议，ISO 10646和统一码成立了中日韩联合研究小组。中日韩联合研究小组将基于各国的汉字编码，独自订定规范、制作ISO 10646和统一码的统一汉字编码。年尾，完成了Unified Repertoire and Ordering（URO）。

1992年，URO加入ISO 10646的第二版。但是，发现了一些缺失，之后进行了修正。

1993年5月，正式制订了最初的中日韩统一表意文字，位于U+4E00–U+9FFF这个区域，共20,902个字。一个月后，制订了统一码1.1。

1999年，依据ISO/IEC 10646的第17个修正案（Amendment 17）订定了扩充区A，于U+3400–U+4DFF加入了6,582个字。

2001年，依据ISO/IEC 10646-2，新增了扩充区B，有42,711字。位于U+20000–U+2A6FF。但因在短时间内增加了大量的汉字，导致产生了许多重复的字形。

2005年，依据ISO/IEC 10646:2003的第1个修正案（Amendment 1），基本多文种平面增加了U+9FA6到U+9FBB等22个汉字。

2009年，统一码5.2扩充区C增加了U+2A700-U+2B734和U+9FC4～U+9FCB。

2010年，统一码6.0扩充区D增加了U+2B740-U+2B81F。

2012年, 1字增加U+9FCC。

成员机构

G　　中华人民共和国

H　　香港特别行政区

J　　日本国

K　　大韩民国

KP　 朝鲜民主主义人民共和国

M　　澳门特别行政区

MY　 马来西亚(2008年11月第31次IRG会议加入)

T　　中华民国

U　　Unicode协会

V　　越南

Z　　不隶属于任何成员机构组成的国际组织

 

字源分离原则

字源分离原则（Source Separation Rule）是整理中日韩统一表意文字的基础。由于CJK各地字型多有微妙的差异，如“户”字的第一笔，台湾作撇“戶”、香港、中国大陆作点“户”、日本作横“戸”，这种程度的差异，理想上是整并为一个字为佳。然而，从之前各种受挫之文字整并计划的经验得知，整合字集与现行通用字集（Big5或国标码）等无法一一对应，是推行整合字集的最大阻碍。

例如，日本的JIS标准同时收录了“剣”字与“劍”字，原本JIS文件里这两个字可以并存，但采用整合字集后反而变成同一个字，会造成使用上的困扰。而且，如果将多个不同地区字形合并会影响阅读者，令使用者不习惯并非以往所见字形；更有可能引致阅读者因习惯而书写不属于自己地区的字形（或地区性的异体字）、学习错误的字形。于是，字源分离原则因而诞生。

而在不同地区而有不同写法的部首，如“⻌（中国大陆）、⻍（港台旧字体）、辶（港台）”、“⺾（新字体）、卝䒑（旧字体）”、“⺥（中国大陆）、爫（港台）”等就会交由字体处理，例如使用依中国大陆汉字标准《印刷通用汉字字形表》的字体下（如中易宋体、微软雅黑体）便会出现“⻌、⺥”；使用港台字体标准字体下（如微软正黑体，但非旧版细明体[17]）就会出现“辶、爫”等字形。大大解决了因地区而异之部首写法。

字源分离原则是指，在上述所列出之各种字源里，若有任何字集同时收了两种以上的文字字形，则在Unicode中日韩统一表意文字中，也同时收录这些字。这样一来，现行的各种原有字集与Unicode汉字可以一一对应。

由于Unicode中日韩统一表意文字的主要诉求，就是能大幅减少Unicode收录汉字字数，同时尊重各地的习惯字形。但字源分离原则则破坏了“只对字，而不对字形”编码之原则，亦遭受不少批评。

 

统汉字资料库

统汉字资料库是统一码联盟所维护的资料库文件。其为统汉字的每个汉字做了说明，内容包含：

统一码与各国家、地区标准及各工业标准的对应。

依据重要字典（如康熙字典）的排序索引。

经过编码的异体字。

汉字在各种语言中的发音。

英文释义。

其资料库透过以下几种方式发布：

统一码联盟维护的网站版本。

可供下载的txt文本文件。

基于上述文件开发的第三方版本。 libUnihan项目开发了一套可供调用的c函式库，和一个SQLite格式的Unihan数据库。[19]前者以LGPL协议发布，后者以MIT协议发布。

 

批评

收字过少的批评

合并同义字，虽有助减少收录字数，但在研究学术时，如古籍、历史及文字研究等，部份文献确要将字形不同之字同时并列，已合并各字，变得各有各意思。学者若用Unicode，遇此情况，就要用同码不同电脑字形，甚至要自行造字，或舍Unicode而用其他编码。一来寻转电脑字形不便，二来有损Unicode记录每一个字之用意，三来不能以纯文本交换。另外亦不能以Unicode准确记录文献，原本不同字形之字合并，原有有别义，转Unicode而讹误，不利于文本存于电脑。

另外，同一部件，有分有合，原则不一致。如“眞”“真”分、“直”“直”合而“値”“值”又分，令人混淆。

不同字形之字合并后，若检索方法以字形为本，会混乱而难以检索。例如笔划检字，艸部之草花头，中国大陆、日本计三划，而传统中文四划，留有艸形则六划。Unicode同一字码，源于字形不同，就有几种笔划，检索混乱。即使检出字，笔划与显示之字亦不符。

文化上，东亚各国用字形有别，用电脑字形亦有别，在日本难以用传统字之电脑字体，在港台难以用日本电脑字体，故合并后，文本要显示文化差异之字形，则大有困难。

 

收字过多的批评

但是另一方面，也有批评认为UNICODE收入大量错讹字及写法高度相似的同一字的不同字形本身就是不应该的。电脑文本本身永远不可能完全无损地记录文献，且文献本身也会因传抄制版等原因略有不同，如果把每个字的各种写法全部编码，不仅浪费空间，而且检索困难，写法稍有不同就无法检出，以至于检索字词时必须反复检索其不同写法，造成重复劳动，对文献研究反而是种妨碍，例如UNICODE中将避讳的缺笔字也进行编码，在检索文献时，这些字无法检索出，反造成困扰。完全无损地研究、记录文献只能通过查看原本或照相影印版来完成，把无损保存转嫁给编码是错误的。

 

已统一汉字

原则上ISO 10646只对字（Character），而非字形（Glyph）编码。同一字各地可使用自己的标准写法。下例中使用HTML标示同一编码的字在不同地区中的写法（但只是读者的浏览器所提供的字型，未必代表该地区的标准写法）。