中日韓統一表意文字
中日韓統一表意文字（），也稱統一漢字、統漢碼（），目的是要把分別來自中文、日文、韓文、越南文、壮文、琉球文中，起源相同、本義相同、形狀一樣或稍異的表意文字，在ISO 10646及Unicode標準賦予相同編碼。
所謂「起源相同、本義相同」、主要是汉字，包括繁體字、簡化字、日本漢字（／）、韓國漢字（／）、琉球汉字（／）、越南的喃字（／）與儒字（／）、方塊壯字（／）。
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個字。還有一個漢字“〇”（碼位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。
另外，第三平面的U+31400–U+33D1F預計放置小篆，U+33E00–U+355FF預計放置甲骨文，相關提案已經提交。按路線圖，該平面還會收錄金文、簡帛文、陶文、鳥蟲書等。最初期的統一漢字共20,902字，其範圍為：U+4E00–U+9FA5。其收字來源包括了以下字集： 其中，統一碼技術委員會源（U源）是指，並非由表意文字小組所遞交的參考字集，而是委員會額外遞交作參考的字集標準。並且此來源的字集不適用原字集分離原則（見稍後）。
擴展A區包含有6,592個漢字，位置在U+3400—U+4DBF。這6千多個漢字分別從以下字典或字集中取得： 擴展B區包含有42,717個漢字，位置在U+20000—U+2A6DD。根據IRG N777號文件，這四萬多個漢字分別從以下字典或字集中取得： 這些漢字中重複的漢字有不少，所以經過整理之後，實際總數只有42,711個漢字。
另外，在U+2F800—U+2FA1D的位置，放了542個來自臺灣的兼容漢字。
為使Unicode向下兼容GB 18030和香港增補字符集（HKSCS）的所有漢字，而擴展C區又遲遲未能出籠，在Unicode 4.1版中引進了14個香港增補字符集的用字和8個GB 18030用字。該22字被編於U+9FA6–U+9FBB的位置。
另外，在U+FA70—U+FAD9的位置，放了106個來自北韓的兼容漢字。
在2008年4月推出的Unicode 5.1版本，收錄7個由日本Adobe公司遞交的日語漢字（U+9FBC–U+9FC2），和鿃（大字加兩個入字，就如陝西省的-{陝}-字換上目字旁）（U+9FC3）。本來Unicode 3.0收錄了目字旁加-{夾}-（大字加兩個人字）字的「-{䀹}-」（U+4039），目字旁加㚒字的字，與「-{䀹}-」無論在意義和發音均不相同，故魏安（Andrew West）和井作恆（John H. Jenkins）申請追加此字。
於2009年10月發布的Unicode 5.2涵蓋了擴展C區，共收錄4,149個漢字，包括來自中國大陆、澳門、臺灣、日本、越南等尚未被編碼的漢字。位置在U+2A700—U+2B734。這四千多個漢字分別從以下字典或字集中取得：
擴展D區包含的都是所謂的「急用漢字」，合共222個新漢字，於2010年下半年發布的Unicode 6.0中，編碼範圍為U+2B740–U+2B81F（實際有字元為U+2B740–U+2B81D）。
擴展D區原本計劃放置擴展C區未收錄的16,000多個漢字，但在2007年5月，臺灣撤消了6,545個第二部分字集內私用漢字，不再使用字，原因是那些人名用字的擁有人或已去世或已移居外地，此後擴展D區縮減到大約10,000字左右。由於各種阻礙，協議先把數量較少，又急切要收錄的漢字提交出來，就是「急用漢字」，以便和統一碼6.0.0版一起發表。提出的急用漢字只有二百二十二字（本來有二百二十三字，但日本撤回其中一字）。現在文字小組把第二部分字集延後到擴充E區。
扩展E区亦在2015年6月17日的Unicode 8.0中发布，放置于编码范围U+2B820–U+2CEAF。
扩展E区本应包含扩展D区未收录的10000多个汉字，但在2008年11月，中国大陆以“难以逐个找证据”为理由，撤销了3215个汉字，这些汉字主要用于地名、人名、姓氏，亦有数百个《中国大百科全书》中的文字。这是继台湾撤销6545字之后的又一次大规模撤销。之后又经过长时间的检查处理，E区最终定稿，共有5762字。这些汉字来源如下：
「急用漢字」是擴展E區整理後期，各地新發現並急於使用，又等不及放入擴展F區的字；和擴展E區一起收入Unicode 8.0，位置在U+9FCD–U+9FD5；當中中國大陸在此處申請收入三字，連同擴展E區的字，通用規範漢字表的8105字至此全部收入。
扩展F区在2017年6月20日的Unicode 10.0中发布，编码范围为U+2CEB0–U+2EBEF。扩展F区来源于新提交的一批汉字，主要包括一千多个方块壮字及数千个佛经、古籍中的用字以及日本户籍用字，共有7473字。
这些汉字的来源如下： 於2020年3月10日公佈的Unicode 13.0中在第三輔助平面收錄擴展區G的4,939個漢字，碼位為U+30000–U+3134A。
这些汉字的来源如下（部分字符來自多於一個來源，所以下表總數多於收錄總數4,939字）：
表意文字認同原則（Han Unification Rule，又稱表意文字統合原則）與原字集分離原則（Source Separation Rule，又稱來源字集分離原則、原規格分離原則、字源分離原則），是兩個對立的原則，它們是Unicode整理中日韓統一表意文字的基礎。
東亞各國字形多有微妙的差異。如「房」字的第一筆，韓國傳統漢字字形、臺灣教育部標準字體作撇「」；香港教育參考字形、中國大陆規範作點「」；日本標準作橫「」。又如「次」字的左旁，韓國採用傳統字形，首筆爲橫，次筆爲挑；臺灣教育部作兩橫；大陸、日本、香港等則作「冫」（俗稱兩點水）。這種程度的差異，理想上是整併為一個字為佳。否則，要是凡異體字都收進不同碼位裏，Unicode收錄的漢字就會過於臃腫，用戶搜尋時也會因異體問題而找不到想要的結果。
然而，從之前各種受挫之文字整併計劃的經驗得知，整合字集與現行通用字集（Big5或國標碼）等無法一一對應，是推行整合字集的最大阻礙。例如，日本的JIS編碼同時收錄了「-{剣}-」字與「-{劍}-」字，原本JIS文件裏這兩個字可以並存。如果採用整合字集後，它們會變成同一個字，就會造成使用上的困擾。而且，如果將多個不同地區字形合併，會影響閱讀者，令使用者不習慣並非以往所見字形；更有可能引致閱讀者因習慣而書寫不屬於自己地區的字形（或地區性的異體字）。
於是，表意文字認同原則與原字集分離原則就應運而生。
在表意文字認同原則下，Unicode「只對字（Character），而不對字形（Glyph）」編碼，會把同一字的不同字形（即異體字）合併。好像上述的「次」字，在Unicode裏會整併成一個碼。又例如不同地區而有不同寫法的部首，如「（中國大陸規範、日本新字體）、（港臺舊字形、韓國、日本舊字體）、（臺灣教育部）」、「（中國大陸規範、臺灣教育部）、（日本新字體）、（日本舊字體、韓國、港臺舊字形）」、「（中國大陸、港臺新字形）、（舊字形）」等，會合併編碼。這些部首的寫法差異就會交由字型處理。比如說，使用依中國大陸漢字標準《印刷通用漢字字形表》的字體下（如中易宋體、微軟雅黑體）便會出現「、」；使用臺灣教育部標準字體（如微軟正黑體或新版細明體，但非舊版細明體）就會出現「、」等字形。這大大解決了因地區而異之部首寫法。
至於原字集分離原則是指，在上述所列出之各種收字來源裏，若有任何字集同時收了兩種以上的文字字形，則在Unicode中日韓統一表意文字中，也同時收錄這些字。這樣一來，現行的各種原有字集與Unicode漢字可以一一對應。比如「房」字，各地字集都沒有分別編碼，就只編進一個碼位，部首第一筆的寫法交由字型處理。然而，「-{戶}-」、「-{户}-」、「-{戸}-」這三個字，在一些地區標準裏是分別編碼的，Unicode則以三個碼位來分別收錄它們。上述的「-{剣}-」與「-{劍}-」也一樣，被安放到不同的碼位中。
基於上述運作，Unicode能大幅減少收錄漢字字數，同時讓地區編碼過渡至Unicode時，字集裏的字元不會有流失。但是，原字集分離原則破壞了Unicode「只對字，而不對字形」編碼之原則，使某些漢字獲得兩個或多個編碼，亦遭受不少批評。
後來的一些重複漢字會使用“兼容区”提供暂存编码，可通过归一化（）步骤移除。一般的漢字輸入法，以及多數漢字字型，也不支援兼容區字元。
另外，原字集分離原則只適用於最初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本身也使用了不一致的併分尺度，因此，早期的異體字時常獲分配正常碼位，後來常常只有兼容區的暫存編碼，再後來則不時被直接整併並交由異體字選擇器處理。若不修正或更改早期的編碼，類似的問題將會持續存在。
統漢字資料庫（）是統一碼聯盟所維護的資料庫文件。其為統漢字的每個漢字做了說明，內容包含：
其資料庫透過以下幾種方式發佈：
合併異體字，雖有助減少收錄字數，但在研究學術時，如古籍、歷史及文字研究等，部份文獻卻要將字形不同之字同時並列。已合併的各個字，在這些文獻裏變得各有各意思。學者若使用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區使用了輔助平面來擺放漢字，以致不少文書處理軟件都不能支援。例如，Microsoft Office 2000或之前的版本，即使電腦擁有擴展B區漢字字體，也只會顯示兩個方格。
另外，因擴展B區在整理上有缺陷，收錄了以下5個本來應該與其他漢字統一的字： 而在WG2 N1155文件中，亦列出了152對可考慮統一的漢字。
表意文字小组（IRG）处理文字时，遵循对字而不是对字形编码的原则。但是有的字被错误统一编在同一个编码之中，如编码为U+2827C的汉字。2014年5月有人指出了这个问题：
当-{惡}-和悪作为部件时是不应该统一的，因为-{惡}-和悪的繁简性质不同。相关的规定中也并未提及-{惡}-和悪作为部件应当统一，况且和-{噁}-是分开编码的。
但是当表意文字小组（IRG）收到这个问题后，认为应当保持统一。因此这两个字仍然在同一编码之中。