【中日韩统一表意文字】
中日韩统一表意文字（CJK Unified Ideographs），或译为中日韩等同表意文字、中日韩认同表意文字、中日韩统一汉字集、中日韩统合汉字，又称作统汉码、统一汉字集（Unihan），其建立目的是将中、日、韩、越、壮、琉球文之中，起源相同、本义相通、形状一样或稍异的表意文字，在ISO 10646及Unicode标准中赋予相同编码。这样的作业活动在Unicode标准中，称为汉字等同（Han unification，或译为汉字认同、汉字统一、汉字统合）。整理出来的中日韩统一表意文字，由Unicode联盟建置的Unihan资料库维护。
中日韩统一汉字集所含括的-{对象}-为汉字及其衍生出来的语素文字，包括繁体字、简化字、日本汉字（汉字／かんじ）、韩国汉字（汉字／한자）、琉球汉字（汉字／ハンジ）、越南的喃字（𡨸喃／Chữ Nôm）与儒字（𡨸儒／Chữ Nho）、方块壮字（／sawgun）。
==历史==
1978年，日本产业规格制订了基于ISO/IEC 2022的JIS C 6226，为全世界最早的汉字编码，包含6349个汉字。1980年代，台湾（CCCII、CNS 11643）、中国大陆（GB 2312）、韩国（KS C 5601）开始-{制}-订了各自的编码规范。这些规范彼此之间并无连系。若要在一份文件中同时使用，则要以跳脱字元的方式来交换。
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个字。还有一个汉字“〇”（码位U+3007），被当成数字放入了符号和标点区。一个月后，制订了统一码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年，统一码7.0基本多文种平面增加1个汉字：U+9FCC。
2015年，统一码8.0扩展区E增加U+2B820–U+2CEAF，基本多文种平面增加U+9FCD–U+9FD5。
2017年，统一码10.0扩展区F增加U+2CEB0–U+2EBEF，基本多文种平面增加U+9FD6–U+9FEA。
2018年，统一码11.0基本多文种平面末尾增加5个汉字：U+9FEB–U+9FEF。
2020年，统一码13.0增加4,969个汉字，其中4,939个位于第三平面的扩展区G，码位为U+30000–U+3134A。同时，亦在基本区增加13字：U+9FF0–U+9FFC，在扩展A区增加10字：U+4DB6–U+4DBF，在扩展B区增加7字：U+2A6D7–U+2A6DD。
2021年，统一码14.0基本多文种平面末尾增加3个汉字: U+9FFC–U+9FFF。同时，亦在扩展B区增加2字：U+2A6DE–U+2A6DF，在扩展C区增加4字：U+2B735–U+2B738。
2022年，统一码15.0增加4,193个汉字，其中4,192个位于第三平面的扩展区H，码位为U+31350–U+323AF。同时，亦在扩展C区增加7字：U+2B739。
另外，第三平面的U+31400–U+33D1F预计放置小篆，U+33E00–U+355FF预计放置甲骨文，相关提案已经提交。按路线图，该平面还会收录金文、简帛文、陶文、鸟虫书等。
== 版本 ==
== 成员机构 ==
*Unicode 协会
*（政府资讯科技总监办公室辖下中文界面咨询委员会）
*（资讯系统中文编码工作小组，由行政公职局协调）
*（台北市电脑商业同业公会）
*（2008年11月第31次IRG会议加入）
*大藏经文本数据库委员会（大蔵経テキストデータベース委员会，SAT）
== 收字来源 ==
=== 总计 ===
=== 最初期统一汉字 ===
最初期的统一汉字共20,902字，其范围为：U+4E00–U+9FA5。其收字来源包括了以下字集：
其中，统一码技术委员会源（U源）是指，并非由表意文字小组所递交的参考字集，而是委员会额外递交作参考的字集标准。并且此来源的字集不适用原字集分离原则（见稍后）。
===扩展A区===
扩展A区包含有6,592个汉字，位置在U+3400—U+4DBF。这6千多个汉字分别从以下字典或字集中取得：
===扩展B区===
扩展B区包含有42,717个汉字，位置在U+20000—U+2A6DD。根据 IRG N777号文件date=20060925091454 ，这四万多个汉字分别从以下字典或字集中取得：
这些汉字中重复的汉字有不少，所以经过整理之后，实际总数只有42,711个汉字。
另外，在U+2F800—U+2FA1D的位置，放了542个来自台湾的兼容汉字。
===Unicode 4.1汉字===
为使Unicode向下兼容GB 18030和香港增补字符集（HKSCS）的所有汉字，而扩展C区又迟迟未能出笼，在Unicode 4.1版中引进了14个香港增补字符集的用字和8个GB 18030用字。该22字被编于U+9FA6–U+9FBB的位置。
另外，在U+FA70—U+FAD9的位置，放了106个来自北韩的兼容汉字。
===Unicode 5.1汉字===
在2008年4月推出的Unicode 5.1版本，收录7个由日本Adobe公司递交的日语汉字（U+9FBC–U+9FC2），和鿃（大字加两个入字，就如陕西省的-{陕}-字换上目字旁）（U+9FC3）。本来Unicode 3.0收录了目字旁加-{夹}-（大字加两个人字）字的「-{𥅴}-」（U+4039），目字旁加㚒字的字，与「-{𥅴}-」无论在意义和发音均不相同，故魏安（Andrew West）和井作恒（John H. Jenkins）申请追加此字。
===扩展C区===
于2009年10月发布的Unicode 5.2涵盖了扩展C区，共收录4,149个汉字，包括来自中国大陆、澳门、台湾、日本、越南等尚未被编码的汉字。位置在U+2A700—U+2B734。这四千多个汉字分别从以下字典或字集中取得：
===扩展D区===
扩展D区包含的都是所谓的「急用汉字」，合共222个新汉字，于2010年下半年发布的Unicode 6.0中，编码范围为U+2B740–U+2B81F（实际有字元为U+2B740–U+2B81D）。
扩展D区原本计划放置扩展C区未收录的16,000多个汉字，但在2007年5月，台湾-{zh-hans:撤销; zh-hant:撤消; zh-cn:撤销; zh-tw:撤消; zh-hk:撤消; zh-mo:撤消; zh-my:撤销; zh-sg:撤销}-了6,545个第二部分字集内私用汉字，不再使用字，原因是那些人名用字的拥有人或已去世或已移居外地，此后扩展D区缩减到大约10,000字左右。由于各种阻碍，协议先把数量较少，又急切要收录的汉字提交出来，就是「急用汉字」，以便和统一码6.0.0版一起发表。提出的急用汉字只有二百二十二字（本来有二百二十三字，但日本撤回其中一字）。现在文字小组把第二部分字集延后到扩充E区。
===扩展E区===
扩展E区亦在2015年6月17日的Unicode 8.0中发布，放置于编码范围U+2B820–U+2CEAF。
扩展E区本应包含扩展D区未收录的10000多个汉字，但在2008年11月，中国大陆以“难以逐个找证据”为理由，-{zh-hans:撤销; zh-hant:撤消; zh-cn:撤销; zh-tw:撤消; zh-hk:撤消; zh-mo:撤消; zh-my:撤销; zh-sg:撤销}-了3215个汉字，这些汉字主要用于地名、人名、姓氏，亦有数百个《中国大百科全书》中的文字。这是继台湾-{zh-hans:撤销; zh-hant:撤消; zh-cn:撤销; zh-tw:撤消; zh-hk:撤消; zh-mo:撤消; zh-my:撤销; zh-sg:撤销}-6545字之后的又一次大规模-{zh-hans:撤销; zh-hant:撤消; zh-cn:撤销; zh-tw:撤消; zh-hk:撤消; zh-mo:撤消; zh-my:撤销; zh-sg:撤销}-。之后又经过长时间的检查处理，E区最终定稿，共有5762字。这些汉字来源如下：
===急用汉字===
「急用汉字」是扩展E区整理后期，各地新发现并急于使用，又等不及放入扩展F区的字；和扩展E区一起收入Unicode 8.0，位置在U+9FCD–U+9FD5；当中中国大陆在此处申请收入三字，连同扩展E区的字，通用规范汉字表的8105字至此全部收入。
===扩展F区===
扩展F区在2017年6月20日的Unicode 10.0中发布，编码范围为U+2CEB0–U+2EBEF。扩展F区来源于新提交的一批汉字，主要包括一千多个方块壮字及数千个佛经、古籍中的用字以及日本户籍用字，共有7473字。
这些汉字的来源如下：
===扩展G区===
于2020年3月10日公布的Unicode 13.0中在第三辅助平面收录扩展区G的4,939个汉字，码位为U+30000–U+3134A。
这些汉字的来源如下（部分字符来自多于一个来源，所以下表总数多于收录总数4,939字）：
===扩展H区===
于2022年9月13日公布的Unicode 15.0中在第三辅助平面收录扩展区H的4,192个汉字，码位为U+31350–U+323AF。
这些汉字的来源如下（部分字符来自多于一个来源，所以下表总数多于收录总数4,192字）：
== 认同原则与原字集分离原则 ==
台湾教育部字形、大陆规范汉字、韩国的汉字、越南的汉字、日本的汉字。
表意文字认同原则（Han Unification Rule，又称表意文字统合原则）与原字集分离原则（Source Separation Rule，又称来源字集分离原则、原规格分离原则），是两个对立的原则，它们是Unicode整理中日韩统一表意文字的基础。
东亚各国字形多有微妙的差异。如「房」字的第一笔，韩国传统汉字字形、台湾教育部标准字体作撇「房」；香港教育参考字形、中国大陆规范作点「房」；日本标准作横「房」。又如「次」字的左旁，韩国采用传统字形，首笔为横，次笔为挑；台湾教育部作两横；大陆、日本、香港等则作「冫」（俗称两点水）。这种程度的差异，理想上是整并为一个字为佳。否则，要是凡异体字都收进不同码位里，Unicode收录的汉字就会过于臃肿，用户搜寻时也会因异体问题而找不到想要的结果。
然而，从之前各种受挫之文字整并计划的经验得知，整合字集与现行通用字集（Big5或国标码）等无法一一对应，是推行整合字集的最大阻碍。例如，日本的JIS编码同时收录了「-{剣}-」字与「-{剑}-」字，原本JIS文件里这两个字可以并存。如果采用整合字集后，它们会变成同一个字，就会造成使用上的困扰。而且，如果将多个不同地区字形合并，会影响阅读者，令使用者不习惯并非以往所见字形；更有可能引致阅读者因习惯而书写不属于自己地区的字形（或地区性的异体字）。
于是，表意文字认同原则与原字集分离原则就应运而生。
在表意文字认同原则下，Unicode「只对字（Character），而不对字形（Glyph）」编码，会把同一字的不同字形（即异体字）合并。好像上述的「次」字，在Unicode里会整并成一个码。又例如不同地区而有不同写法的部首，如「⻌（中国大陆规范、日本新字体）、⻍（港台旧字形、韩国、日本旧字体）、⻎（台湾教育部）」、「礻（中国大陆规范、台湾教育部）、礻（日本新字体）、⺬（日本旧字体、韩国、港台旧字形）」、「爫（中国大陆、港台新字形）、⺥（旧字形）」等，会合并编码。这些部首的写法差异就会交由字型处理。比如说，使用依中国大陆汉字标准《印刷通用汉字字形表》的字体下（如中易宋体、微软雅黑体）便会出现「⻌、爫」；使用台湾教育部标准字体（如微软正黑体或新版细明体，但非旧版细明体NoteTag|旧版“细明体”指Windows XP或以前版本之新细明体及细明体，其汉字写法大体上遵从传承字形。）就会出现「⻎、爫」等字形。这大大解决了因地区而异之部首写法。
至于原字集分离原则是指，在上述所列出之各种收字来源里，若有任何字集同时收了两种以上的文字字形，则在Unicode中日韩统一表意文字中，也同时收录这些字。这样一来，现行的各种原有字集与Unicode汉字可以一一对应。比如「房」字，各地字集都没有分别编码，就只编进一个码位，部首第一笔的写法交由字型处理。然而，「-{户}-」、「-{户}-」、「-{戸}-」这三个字，在一些地区标准里是分别编码的，Unicode则以三个码位来分别收录它们。上述的「-{剣}-」与「-{剑}-」也一样，被安放到不同的码位中。
基于上述运作，Unicode能大幅减少收录汉字字数，同时让地区编码过渡至Unicode时，字集里的字元不会有流失。但是，原字集分离原则破坏了Unicode「只对字，而不对字形」编码之原则，使某些汉字获得两个或多个编码，亦遭受不少批评。
后来的一些重复汉字会使用“兼容区”提供暂存编码，可通过归一化（normalization）步骤移除。一般的汉字输入法，以及多数汉字字型，也不支援兼容区字元。
另外，原字集分离原则只适用于最初Unified Repertoire and Ordering（URO）的20,902字，换言之，由「扩展区A」开始就不再适用。原因是个别地区提交了不少仅有十分轻微差异的字样，比如台湾《异体字字典》里的各种异体，要求Unicode分别编码。然而，那些字样所建基的地区编码，并非该地区的通用编码，例如是中文标准交换码（台湾实际通行的编码是Big5码）。若Unicode全面采纳，将会令Unicode对异体字的处理更混乱。
今天，异体字选择器（Variation Sequence）以及Adobe常用的CID字型等技术，已容许在一个Unicode编码里收录和调用两个或多个汉字字样，原字集分离原则在今天已成为过时技术的副产品。
===起源不同原则===
留意的是，可以整并的字只限异体字。如果有些汉字，它的音、义根本不一样，是两个不相同的字，即使它们外形相近，写法差异比另一些整并的字少，但仍不能合并。这规则称为起源不同原则（Noncognate Rule）。
擧例说：「土」和「士」虽然形似，却是两个不同的字，我们不可以整并它们。然而，日本、韩国、大陆、香港等地的「寺」字，与台湾教育部的「寺」字，两者顶部分别是「土」和「士」，但它们音义全同，是同一字的异体，于是就能够整并。
其他起源不同的例子还有「-{朏}-」与「-{胐}-」（「月偏旁」与「肉偏旁」对立）、「-{胄}-」与「-{胄}-」（「肉底」与「冃底」对立），「柿」和「杮」（右方「市部件」与「巿部件」对立），「汨」和「汩」（右方「日部件」与「曰部件」对立），「-{陕}-」与「-{陜}-」（右旁「-{夹}-部件」与「-{㚒}-部件」对立）等。
然而，汉字中有「同形字」的现象，有两个或多个读音与字义，虽然字源不同，却由同一字形表达出来。比如汉字「芸芸众生」的「芸」，与日本汉字「艺」字的新字体「芸」，是同形字。要是这些同形字，在字形上确实相同而非相似（「芸」字的草头虽然有三笔的「-{⺾}-」、四笔的「-{⺿}-」等不同写法，但它们都指同一部件，没有形成对立），就不会应用起源不同原则。
===学界批评===
中文文字学学界对Unicode的原字集分离原则有不少批评，尤其是它令同一个异体部件时而分离，时而合并，在日常使用层面引伸了许多问题。擧例说，「青」和「靑」、「淸」和「清」都在正常区域中作分离编码，获得两个码位；「晴」、「靖」、「精」虽也获两个码位，但其中一个是在兼容区中，日常难以应用；「请」、「情」、「蜻」、「静」更只有一个码位。或例如，「直」和「直」、「植」和「植」是被整并的，可是「値」和「值」却分离作两个码位。Unicode的做法，没有把含有相同异体部件的字全都合并，也没有把它们全都分离，结果经常导致字形不一致，或者使用者无法选择他希望使用的字形。
其他汉字使用地区也有类似声音。例如「戋」和「㦮」两个偏旁，前者为「-{戋}-」的大陆简化字，后者为「-{戋}-」的日本新字体，在「残」和「残」、「浅」和「浅」、「践」和「践」等组合里，就整并起来。可是碰到「桟」和「栈」，却不统合，分列U+685F与U+6808两个码位中。这种情况被日本学者指为Unicode的矛盾。
事实上，由于在「中日韩统一表意文字」的不同区域里，Unicode本身也使用了不一致的并分尺度，因此，早期的异体字时常获分配正常码位，后来常常只有兼容区的暂存编码，再后来则不时被直接整并并交由异体字选择器处理。若不修正或更改早期的编码，类似的问题将会持续存在。
== 统汉字资料库 ==
统汉字资料库（Unihan）是统一码联盟所维护的资料库文件。其为统汉字的每个汉字做了说明，内容包含：
*统一码与各国家、地区标准及各工业标准的对应。
*依据重要字典（如康熙字典）的排序索引。
*经过编码的异体字。
*汉字在各种语言中的发音。
*英文释义。
其资料库透过以下几种方式发布：
*统一码联盟维护的网站版本。
*可供下载的 txt文本文件date=20120203092815 。
*基于上述文件开发的第三方版本。
**libUnihan项目开发了一套可供调用的c函式库，和一个SQLite格式的Unihan数据库。前者以LGPL协议发布，后者以MIT协议发布。
==批评==
===收字过少===
合并异体字，虽有助减少收录字数，但在研究学术时，如古籍、历史及文字研究等，部份文献却要将字形不同之字同时并列。已合并的各个字，在这些文献里变得各有各意思。学者若使用Unicode，遇到这种情况，就要用不同电脑字型去显示同一个字码，甚至要自行造字，或舍Unicode而用其他编码。一来寻找、转换电脑字型构成不便，二来有损Unicode记录每一个字之用意，三来不能以纯文本交换，四来电脑字型或因授权条款之限，难以交换流传。另外，这亦等于不能以Unicode准确记录文献，不利于文本的电脑化。
不同字形之字合并后，若检索方法以字形为本，会产生混乱，难以检索。例如笔画检字，艸部之「-{艹}-头」，中国、日本算作三画，而传统中文为四画，留有「-{艸}-」形者则为六画。Unicode同一字码，源于字形不同，就有几种笔画，检索混乱。即使检出字，笔画与显示出来的字形也不相符。因此，批评者认为，Unicode合并异体字并不可取。
===收字过多===
但是另一方面，Unicode收录不少幽灵汉字，人们难以找到其出处，它们在实际生活上也极少机会使用，有些甚至是错讹字，或者仅是某一个人的名字用字，那个人不见得是名人，甚至可能已去世，却永久成为标准里的字元，占用了一个码位。比如台湾律师吕秋𧽚，他名字里的「𧽚」字本应作「-{远}-」，可是户政人员误听他外公说的台语，把「辵字边」听成「走马边」，外公又不敢更正。当事人长大后，才确认这是错字，「五千年来从来没人这么写过」。但这字已永久收进Unicode中。又如香港增补字符集里的许多人名用字，都被学者指出乃属讹写，或者是来历不明的自创新字，多部权威字书都没有收录，学者批评把这些字收进字库后将会永久遗害。中文资讯界的李祥在其专栏批评当局「解决不了增补字集中上千错字、白字、生造字的读音问题」，呼吁「不要把香港增补字符集与申请ISO强迫联系在一起」。然而，这些人名讹字亦已经收进Unicode中。这构成了收字过多的争议。
也有批评认为Unicode收入大量错讹字及写法高度相似的同一字的不同字形本身就是不应该的。电脑文本本身永远不可能完全无损地记录文献，且文献本身也会因传抄制版等原因略有不同，如果把每个字的各种写法全部编码，会浪费空间。
完全无损地研究、记录文献只能通过查看原本或照相影印版来完成，把无损保存转嫁给编码是错误的。
现时Unicode把一些异体字分别编码，带来了检索困难。只要写法稍有不同，就无法检出，令使用户检索字词时，必须反复检索其不同写法，造成重复劳动，对文献研究反而是种妨碍。例如Unicode中将「-{儿}-」和「𠒇」字安放在不同的码位里。在检索文献时，检索「-{儿}-」字时就找不到「雷庄𠒇」，检索「𠒇」字时就找不到「雷庄-{儿}-」，反而造成困扰。
===准则矛盾===
对于同一部件，Unicode有分有合，原则不一致。如「真」和「真」、「塡」和「填」都分离编码，但「缜」和「缜」就整并了；「直」和「直」、「植」和「植」皆整并作一码，而「値」和「值」又分开来，既令人混淆，亦令人无所适从。Unicode按原字集分离原则收字，只看各地区的既有编码，不理会在文字学上同一部件的问题。可是用户实际上在电脑输入文字时，看到的是具体的字形，而不是编码码位，这就会让人感到矛盾和困惑。
而且在Unicode「中日韩统一表意文字」的不同区域里，官方也使用了不一致的并分尺度。早期的异体字时常获分配正常码位；后来常常只有兼容区的暂存编码，使兼容区的字元在输入和显示时经常碰到问题；再后来则不时被直接整并并交由异体字选择器处理。于是Unicode在编码上的矛盾就更突显。
===汉字〇===
「〇」是一个汉字，《集韵》中已有此字，则天文字中亦有此字。《汉语大字典》《中华字海》《现代汉语词典》都收录了此字。但在Unicode中它被放入CJK符号和标点区，被等同于数字0，在搜索「〇」的时候，会连带搜索出数字0，使用上颇为不便（搜索汉字「一、二、三」，不会搜索出数字1、2、3）。此外，很多程序限定了汉字的范围为Unicode各汉字区，区外不视为汉字，由于「〇」不在汉字区中，导致这些程序无法处理「〇」这个汉字，造成不便。
== 已统一汉字 ==
原则上ISO 10646只对字（Character），而非字形（Glyph）编码。同一字各地可使用自己的标准写法。以下使用HTML标示同一编码的字在不同地区的写法（但只是读者的浏览器所渲染的字型，与浏览器的设置与设备安装的字体有关，未必代表该地区的标准写法）。
例子
注：不是所有网页浏览器均可分辨全部HTML的语言代码（Language Code）并使用不同字形。如非某一地区的使用者看到的字形和当地通用的字形一样，表示该用户的浏览器不能分辨此标签，或设定两者以同一种字形显示。
==未统一汉字==
有些字只是同一字在不同地区的写法，理应统一，但因为原字集分离原则而只好分开编码。由于KS X 1001、Big5、IBM 32、JIS X 0213、ARIB STD-B24、KPS 10721、CNS 11643中有太多字形非常接近，按Unicode标准应该统一，但是从编码上分离的字。这些字只有正统的会编入正式字集（包括扩展区），不正统的编入「相容表意文字区」（Compatibility Ideographs）和位于「第二辅助平面」的「相容表意文字补充区」（Compatibility Ideographs Supplement）中。
范例：
-{
}-
自上表发表后，WG2亦调查过其他汉字，认为另一批属于基本多文种平面的汉字，亦可考虑收编到ISO 10646 Annex S3。
==技术问题==
===扩展B区的问题===
扩展B区使用了辅助平面来摆放汉字，以致不少文书处理软件都不能支援。例如，Microsoft Office 2000或之前的版本，即使电脑拥有扩展B区汉字字体，也只会显示两个方格。
另外，因扩展B区在整理上有缺陷，收录了以下5个本来应该与其他汉字统一的字：
*U+20457 20457 = U+34A8 34A8
*U+2420E 2420E = U+3DB7 3DB7
*U+27144 27144 = U+8641 8641
*U+23515 23515 = U+204F2 204F2
*U+249E9 249E9 = U+249BC 249BC
而在WG2 N1155文件中，亦列出了152对可考虑统一的汉字。
===错误统一的问题===
表意文字小组（IRG）处理文字时，遵循对字而不是对字形编码的原则。但是有的字被错误统一编在同一个编码之中，如编码为U+2827C的汉字。2014年5月有人指出了这个问题：
当-{恶}-和悪作为部件时是不应该统一的，因为-{恶}-和悪的繁简性质不同。相关的规定中也并未提及-{恶}-和悪作为部件应当统一，况且左“口”右“悪”和-{恶}-是分开编码的。
但是当表意文字小组（IRG）收到这个问题后，认为应当保持统一。因此这两个字仍然在同一编码之中。