Unicode

Unicode
Unicode財團的徽標
別名
語言請參閱腳本列表
標準Unicode標準
編碼格式
（罕見）
（過時的）
先於

Unicode是Unicode標準，是由Unicode財團維護的文本編碼標準，旨在支持在世界上所有主要寫作系統中寫入文本的使用。標准定義的15.1版149 813個字符和161個腳本，用於各種普通，文學，學術和技術環境。

許多常見字符，包括數字，標點符號和其他符號，都在標準中統一，並且不被視為特定於任何給定的寫作系統。 Unicode編碼了數千個表情符號，並由財團作為標準的一部分進行。此外，Unicode的廣泛採用很大程度上是由於日本以外的表情符號的最初普及。 Unicode最終能夠編碼超過110萬個字符。

Unicode在很大程度上取代了多種不兼容的角色集的先前環境，每個角色集在不同的語言環境和不同的計算機體系結構中使用。 Unicode用於編碼Internet上的絕大多數文本，包括大多數網頁，相關的Unicode支持已成為當代軟件開發中的普遍考慮。

Unicode字符曲目與ISO/IEC 10646同步，每個曲線彼此相同。但是， Unicode標準不僅僅是分配字符的曲目。為了幫助開發人員和設計師，該標準還提供了圖表和參考數據，並附加了向各種腳本解釋概念的概念，從而為其實施提供了指導。這些附件所涵蓋的主題包括字符歸一化，特徵組成和分解，整理和方向性。

使用幾個編碼之一將Unicode文本處理並存儲為二進制數據，該編碼將如何將標準的字符的抽象代碼轉換為字節序列。 Unicode標準本身定義了三個編碼： UTF-8 ， UTF-16和UTF-32 ，儘管存在其他幾個編碼。其中，UTF-8是最廣泛使用的大幅度，部分原因是它與ASCII的向後兼容。

起源與發展

Unicode最初是針對所有文本編碼中存在的超越限制的目的，直到該點：每個編碼都依靠在自己的上下文中使用，但沒有特別期望與其他任何編碼的兼容性。實際上，當一起使用時，選擇的任何兩個編碼通常都是完全不可行的，其文本用另一個被解釋為另一個被解釋為垃圾字符的文本。大多數編碼僅是為了促進少數幾個腳本之間的互操作（通常是在給定腳本和拉丁字符之間），而不是在大量腳本之間進行，而不是以一致的方式處理所支持的所有腳本。

基礎Unicode試圖編碼基礎字符的理念（素數和類似石墨般的單元）比圖形區分相比，其視為僅通過其字體，通過標記或其他一些方式來通過字體來處理的圖形區別。在尤其複雜的情況下，例如對漢字字符的拼字變體的處理，關於哪些差異證明其自己的編碼是合理的，而哪些僅是其他字符的圖形變體。

在最抽象的層面上，Unicode分配了一個唯一的數字，稱為每個字符的代碼點。視覺表示的許多問題（包括大小，形狀和样式）旨在符合該軟件的酌處權，實際上呈現文本，例如Web瀏覽器或文字處理器。但是，部分目的是鼓勵快速採用，隨著時間的流逝，這種原始模型的簡單性變得更加精緻，並且在整個標準的發展過程中已經做出了各種務實的讓步。

第一個256個代碼點反映了ISO/IEC 8859-1標準，其目的是使已經用西歐腳本編寫的文本的轉換進行瑣碎。為了保留不同遺產編碼所產生的區別，因此允許它們與Unicode之間的轉換而沒有任何信息丟失，許多字符在外觀和預期功能中幾乎與他人幾乎相同，都給出了不同的代碼點。例如，半寬和全寬圖形式塊包含拉丁字母的完整語義重複，因為舊版CJK編碼既包含“ FullWidth”（與CJK字符的寬度匹配）和“ Halftwidth”）和“ Halftwidth”（與普通拉丁語腳本）。

Unicode Bulldog獎頒發給被認為對Unicode發展具有影響力的人，其中包括Tatsuo Kobayashi ，Thomas Milo， Roozbeh Pournader ， Ken Lunde和Michael Everson等獲獎者。

歷史

Unicode的起源可以追溯到1980年代，到與Xerox的角色代碼標準（XCC）連接的一組個人。 1987年，施樂的員工喬·貝克爾（Joe Becker ）以及蘋果員工李·柯林斯（Lee Collins）和馬克·戴維斯（ Mark Davis ）開始研究創建普遍角色集的實用性。隨著彼得·芬威克（Peter Fenwick）和戴夫·奧普斯塔德（Dave Opstad）的額外意見，貝克爾（Becker）發表了“ 1988年8月的國際/多語言文本角色編碼系統，暫時稱為Unicode”的提案草案。他解釋說，“'Unicode'的名稱旨在提出一個獨特的，統一的，通用的編碼”。

在此文檔（標題為Unicode 88）中，貝克爾使用16位字符概述了一個方案：

Unicode旨在滿足對可行，可靠的世界文本編碼的需求。 Unicode可以被粗略地描述為“寬體ASCII ”，已延伸到16位，以涵蓋世界上所有活語的角色。在適當的設計設計中，每個字符16位足以實現此目的。

該設計決定是基於以下假設做出的：只有“現代”使用中的腳本和字符才需要編碼：

Unicode優先確保未來的效用，而不是保留過去的古物。 Unicode首先針對現代文本中發表的角色（例如1988年世界上印刷的所有報紙和雜誌的聯合），其數字無疑遠低於2 14 = 14 = 16,384。除了那些現代用途的角色之外，所有其他角色還可以定義為過時或罕見。這些是私人用途註冊的候選人，而不是在通常有用的Unicode的公共列表中。

1989年初，Unicode工作組擴展到了隱喻的Ken Whistler和Mike Kernaghan，研究圖書館小組的Karen Smith-Yoshimura和Joan Aliprand，以及Sun Microsystems的Glenn Wright。 1990年， Microsoft的Michel Suignard和Asmus Freytag和Next的Rick McGowan也加入了該小組。到1990年底，重新映射現有標準的大部分工作已經完成，並準備好了Unicode的最終審查草案。

該聯盟於1991年1月3日在加利福尼亞州成立，並於10月發布了Unicode標準的第一卷。第二卷，現在添加了漢特圖，於1992年6月出版。

1996年，Unicode 2.0中實現了替代特性機制，因此Unicode不再限於16位。這將Unicode代碼空間提高到了超過一百萬個代碼點，這允許編碼許多歷史腳本，例如埃及象形文字，以及成千上萬的很少使用或過時的字符，而這些字符尚未被預期包含在標準中。在這些字符中，有各種很少使用的CJK字符 - 主要是用專有名稱使用的，這使得它們對於通用編碼比所設想的原始Unicode架構更為必要。

Microsoft的TrueType規範的1.0版，於1992年發布，在命名表中使用了“ Apple Unicode”的名稱，而不是“ Unicode”的名稱。

Unicode財團

主要文章： Unicode財團

Unicode聯盟是一個協調Unicode開發的非營利組織。完整的成員包括大多數主要的計算機軟件和硬件公司，對文本處理標準有任何興趣，包括Adobe ， Apple ， Facebook ， Google ， IBM ， Microsoft ， Netflix和SAP SE 。

多年來，幾個國家或政府機構一直是Unicode財團的成員。目前，只有捐贈和宗教事務部（阿曼）是擁有投票權的正式成員。

該財團的雄心勃勃的目標是最終用Unicode及其標準Unicode轉換格式（UTF）方案替換現有的字符編碼方案，因為許多現有方案的大小和範圍都有限，並且與多語言環境不相容。

涵蓋了腳本

主要文章：腳本（Unicode）
如該屏幕截圖從OpenOffice.org應用程序所示，許多現代應用程序可以呈現Unicode中許多腳本的大量子集。

Unicode目前涵蓋當今使用的大多數主要寫作系統。

截至2023年，最新版本的Unicode（涵蓋字母， abugidas和thrallabaries ）中總共包含161個腳本，儘管仍有尚未編碼的腳本，尤其是在歷史，禮儀和學術環境中主要使用的腳本。還會出現在已經編碼的腳本以及符號中，特別是在數學和音樂的符號（以音符和節奏符號的形式）中進一步添加字符。

Unicode路線圖委員會（ Michael Everson ，Rick McGowan，Ken Whistler，vs Umamaheswaran）維護了腳本列表，這些腳本是Unicode uncode uncode uncode uncode uncode Roadmap頁面上的候選人或潛在的編碼及其臨時代碼塊分配的列表。對於路線圖上的某些腳本，例如Jurchen和Khitan大型腳本，已經提出了編碼建議，並且正在通過批准過程進行努力。對於其他劇本，例如瑪雅（除了數字）和隆戈朗戈，尚未提出任何建議，他們等待有關角色曲目的協議以及所涉及的用戶社區的其他細節。

一些現代發明的腳本尚未包含在Unicode（例如Tengwar ）中，或者由於缺乏現實世界的使用（例如， Klingon ）而沒有資格納入Unicode（例如，非正式的Unicode註冊表）以及非官方中列出了但是廣泛使用的私人使用區域代碼分配。

還有一個中世紀的Unicode字體倡議，重點是特殊的拉丁中世紀角色。這些建議的一部分已經包含在Unicode中。

腳本編碼主動性

伯克利分校的黛博拉·安德森（Deborah Anderson）經營的劇本編碼計劃成立於2002年，目的是為尚未在標準中編碼的腳本提供資金。近年來，該項目已成為該標準提議增加的主要來源。

版本

在Unicode標準的首次出版後，Unicode聯盟與ISO一起開發了共享曲目：Unicode和ISO的通用編碼字符集（UCS）使用相同的字符名稱和代碼點。但是，Unicode版本的確與它們的ISO等效物不同。

雖然UCS是一個簡單的字符映射，但Unicode指定了在不同平台和語言之間實現互操作性所需的規則，算法和屬性。因此， Unicode標準包括更多信息，涵蓋了深入的主題，例如位編碼，整理和渲染。它還提供了一個全面的角色屬性目錄，包括支持雙向文本所需的字符，以及可視圖表和參考數據集以幫助實施者。以前， Unicode標準是作為包含完整核心規範，標準附件和代碼圖表的打印卷出售。但是，2006年發布的5.0版是以這種方式打印的最後一個版本。從版本5.2開始，只能購買作為按需打印的平裝本發布的核心規範。另一方面，全文在Unicode網站上以免費的PDF發表。

這種出版物方法的實際原因突出了UCS和UNICODE之間的第二個重要差異，即發布更新版本的頻率並添加了新字符。 Unicode標準已定期發布年度擴展版本，偶爾在一個日曆年內發布了多個版本，並且很少有預定版本必須推遲。例如，在2020年4月，即版本13.0發布一個月後，Unicode財團宣布他們已更改了版本14.0版的預期發布日期，將其推遲到2021年9月，這是由於1921年9月1921年。

Unicode 15.1（最新版本）於2023年9月12日發布。這是版本15.0的次要版本更新 - 於2022年9月13日發布，總共增加了4,489個新字符，包括兩個新腳本， cjk unified的擴展意識形態塊，並在現有塊中增加了多個添加。添加了33個新的表情符號，例如“無線”（網絡）符號和其他彩色心臟。

到目前為止，已發布了以下Unicode標準版本。更新版本不包含對字符曲目的任何更改，由第三個數字表示（例如“ 4.0.1版”），並在下表中省略。

Unicode版本歷史記錄以及角色和腳本的顯著更改
版本日期書UCS版全部的細節
腳本人物
1.0.01991年10月ISBN 0-201-56788-1
（第1卷）
—247129涵蓋的初始劇本：阿拉伯語，亞美尼亞人，孟加拉語，博波莫福，西里爾，德瓦納加里，喬治亞語，希臘語和科普特，古吉拉特語，古吉拉特語，古爾穆克（Gurmukhi）， hangul ，希伯來語，希拉加納，卡納達語，卡納達山， katakana ， katakana ， katakana ，lao，lao，lao，lao，lain，latin，latin，telai，telai， temil，telai， thai ， temil ， telue ，thai，thai， telugu ， telugu ，teluguu，teluguuu， teluguu ，teluguuu， teluguuu ，和藏族
1.0.11992年6月ISBN 0-201-60845-6
（第2卷）
2528327+21204
−6		最初的20,902 CJK統一意識形圖
1.11993年6月—ISO/IEC 10646 -1：1993

2434168+5963
−9		33重新分類為控製字符。 4,306個孔室音節，藏族刪除
2.01996年7月ISBN 0-201-48345-92538885+11373
−6656		刪除了原始的掛吊燈音節，在新位置添加了11,172個孔孔音節的新集合，藏族在新位置中添加了又有不同的角色曲目，定義了替代特徵機制，平面15和平面16私人使用區域分配了
2.11998年5月—38887+2
U+20AC €歐元標誌， u+fffc對象更換字符
3.01999年9月ISBN 0-201-61633-5ISO/IEC 10646-1：20003849194+10307
切諾基，蓋氏，高棉，蒙古人，緬甸，奧格姆，符文，僧伽羅，敘利亞，敘利亞， thaana ，加拿大原住民教學大學和YI音節，盲文圖案
3.12001年3月—ISO/IEC 10646-1：2000
ISO/IEC 10646-2：2001		4194140+44946
Deseret ，哥特式和古老的斜體，西方和拜占庭音樂的符號，42,711額外的CJK統一意識形態
3.22002年3月4595156+1016
菲律賓劇本（ Buhid ， Hanunoo ， Tagalog和Tagbanwa ）
4.02003年4月ISBN 0-321-18578-1ISO/IEC 10646：2003

5296382+1226
Cypriot音節， Limbu ， Linear B ， Osmanya ， Shavian ， Tai Le和Ugaritic ， Hexagram符號
4.12005年3月—5997655+1273
引入了Buginese ， Glagolitic ， Kharosthi ， New Tai Lue ， Old Persian ， Sylheti Nagri和Tifinagh ， Coptic與希臘語，古希臘語數字和音樂符號雜亂無章。
5.02006年7月ISBN 0-321-48091-06499024+1369
巴厘島，楔形文字， n'ko ， tphags-pa ，腓尼基人
5.12008年4月—75100648+1624
Carian ， Cham ， Kayah Li ， Lepcha ， Lycian ， Lydian ， Ol Chiki ， Rejang ，Saurashtra， Saurashtra ， Sundanese和vai ，用於Phaistos Disc的一組符號拉丁文字母夏普
5.22009年10月ISBN 978-1-936213-00-990107296+6648
Avestan ， Bamum ，Gardiner的埃及象形文字名單，帝國阿拉姆語，銘文帕哈維，銘文帕蒂安，爪哇人， Kaithi，Lisu ，Lisu ，Meetei Mayek，Meetei Mayek， Old South Arabian ，Old South Arabian， Old Turkic ，Old Turkic，Samaritan，Samaritan， Tai Tai Tai Tai Tai Tai Tai Tai and Tai Viet ，其他CJK UNIFIED IEDIFIED IEDIFIED IEDAMPORPOR， JAMOCHS ，JAMOCOPRAPTER，JAMOCOPRAPTER，JAMOOMOO，JAMOO，JAMOOO。對於舊的hangul，吠陀梵語
6.02010年10月ISBN 978-1-936213-01-6ISO/IEC 10646：2010

93109384+2088
Batak ， Brahmi ， Mandaic ，撲克牌符號，運輸和地圖符號，煉金術符號，表情符號和表情符號CJK統一意識形態
6.12012年1月ISBN 978-1-936213-02-3ISO/IEC 10646：2012

100110116+732
chakma ， meroitic的草皮， meroitic象形文字， Miao ， Sharada ， Sora Sompeng和Takri
6.22012年9月ISBN 978-1-936213-07-8110117+1
u+20ba₺土耳其里拉標誌
6.32013年九月ISBN 978-1-936213-08-5110122+5
5個雙向格式字符
7.02014年6月ISBN 978-1-936213-09-2123112956+2834
Bassa Vah , Caucasian Albanian , Duployan , Elbasan , Grantha , Khojki , Khudawadi , Linear A , Mahajani , Manichaean , Mende Kikakui , Modi , Mro , Nabataean , Old North Arabian , Old Permic , Pahawh Hmong , Palmyrene , Pau Cin Hau , Psalter Pahlavi ，西德漢姆，蒂魯塔，瓦朗花旗和丁巴特
8.02015年6月ISBN 978-1-936213-10-8ISO/IEC 10646：2014

129120672+7716
Ahom ， Anatolian象形文字， Hatran ， Multani ， Old Hungarian ，簽名，其他CJK統一的意識形態，切諾基小寫字母，5個表情符號膚色修飾符
9.02016年6月ISBN 978-1-936213-13-9135128172+7500
Adlam ， Bhaiksuki ， Marchen ， Newa ， Osage ， Tangut ，72 Emoji
10.02017年6月ISBN 978-1-936213-16-0ISO/IEC 10646：2017

139136690+8518
Zanabazar Square ， Soyombo ， Masaram Gondi ， Nüshu ， Hentaigana ，7,494 CJK統一的意識形態，56表情符號，比特幣符號
11.02018年6月ISBN 978-1-936213-19-1146137374+684
Dogra ， Georgian Mtavruli大寫字母， Gunjala Gondi ， Hanifi Rohingya ， Indic Siyaq編號， Makasar ， Medefaidrin ， Old Sogdian和Sogdian ， Maya Numerals ，5 CJK Unified Itified Indified Itified Intialified， Xiangqi和Xiangqi和145 Emoji的符號
12.02019年3月ISBN 978-1-936213-22-1150137928+554
Elymaic ， Nandinagari ， Nyiakeng Puachue hmong ， Wancho ， Miao腳本，Hiragana和Katakana小字母，泰米爾語歷史分數和符號， pali的老撾信件，拉丁字母，埃及學和ugaritic spransliteration and ugaritic promplliteration，Hieroglyph格式，Hieroglyph格式， 61 Emoji emoji emoji emoji emoji emoji emoji
12.12019年5月ISBN 978-1-936213-25-2137929+1
u+32ff㋿正方形時代名稱reiwa
13.02020年3月ISBN 978-1-936213-26-9ISO/IEC 10646：2020

154143859+5930
Chorasmian ， Dhives Akuru ， Khitan小型劇本， Yezidi ，4,969個CJK意識形態，阿拉伯語劇本，用於撰寫Hausa ， Wolof和其他非洲語言，用於在Pakistan，Bopomofo for Cantonese，創造性的通訊符號，創造性的通訊錄，用來撰寫印地語和Punjabi ，與Teletext和家用計算機系統兼容的圖形字符，55 emoji
14.02021年9月ISBN 978-1-936213-29-0159144697+838
Toto ， Cypro-Minoan ， Vithkuqi ， Old Uyghur ， Tangsa ，擴展的IPA，阿拉伯文字添加添加在非洲以及伊朗，伊朗，巴基斯坦，馬來西亞，印度尼西亞，爪哇和波斯尼亞，支持榮譽和Quranic使用的補充，北美，菲律賓，印度和蒙古的語言， u+ 20c0⃀som標誌， znamenny音樂符號，37表情符號
15.02022年9月ISBN 978-1-936213-32-0161149186+4489
Kawi和Mundari ，20 Emoji，4,192個CJK意識形態，埃及象形文字的控製字符
15.12023年9月ISBN 978-1-936213-33-7149813+627
其他CJK意識形態
  1. 圖形和格式字符的總數，不包括私人使用字符，控製字符，非字符和替代代碼點）。
    • 2.0添加修正案5、6和7
    • 2.1添加了修正案18中的兩個字符。
  3. 3.2添加了修正案1。
    • 4.1添加修正案1
    • 5.0添加了修正案2以及修正案3中的四個字符
    • 5.1添加了修正案4
    • 5.2添加了修正案5和6
  5. 加上印度盧比標誌
  7. 加上修正案1，以及Lari標誌，九個CJK統一的意識形態和41個表情符號；
    9.0添加了修正案2，以及Adlam，Newa，日本電視符號和74個表情符號和符號。
    • 加上56個表情符號，285個Hentaigana角色和3個Zanabazar Square角色
    • 11.0添加了46個Mtavruli Georgian資本信件，5個CJK統一意識形態和66個表情符號
    • 12.0增加了62個其他字符。

投影版本

Unicode財團通常每年一次或偶爾每年兩次發布新版本的Unicode標準版本。版本16.0是下一個主要版本，計劃於2024年發布，預計將包括六個新腳本（Todhri，Sunuwar，Gurung Khema，Kirat Rai，Garay和Ol Onal），Shan和Mon，Mon，Mon，Mon，Mon， Mon，shan and Mon，傳統計算的其他符號，以及尚未確定的新表情符號。

建築和術語

另請參閱：通用字符集字符

代碼和代碼點

Unicode標准定義了一個代碼空間：一個名為代碼點的整數序列，涵蓋了間隔，根據標準為U+0000 – U+10FFFF。代碼空間是Unicode標準的系統，獨立於體系結構的表示。實際文本通過幾種UNICODE編碼之一（例如UTF-8）作為二進制數據處理。

在此規範性符號中，兩個字符的前綴U+始終先於書面代碼點，而代碼點本身則是十六進制數字。始終至少編寫四個十六進制數字，並根據需要進行領先的零。

例如，代碼點u+00f7÷除法符號用兩個領先的零填充，但是U+13254𓉔埃及象形文字o004（）未填充。

總共有（17×2 16 ）-2 11 = 1 112 064代碼空間內的有效代碼點。即使在使用UTF-8編碼許多字符時使用了4個字節，但由於UTF-16使用替代配對而產生的限制，首先腮紅可能允許代碼點最高為u+ffffffff 。 2048年範圍內的代碼點U+D800 – U+DFFF以及所有代碼點U+110000及更高版本對於編碼字符永久無法使用。

  1. 有關UTF編碼的工作方式，請參見#mapping和編碼。

代碼平面和塊

主要文章：平面（Unicode）

Unicode代碼空間分為17架，編號為0到16。平面0是基本的多語言平面（BMP），並包含最常用的字符。 BMP中的所有代碼點均作為UTF-16編碼中的單個代碼單元訪問，並且可以在UTF-8中的一個，兩個或三個字節中編碼。飛機1至16（補充平面）中的代碼點作為UTF-16中的代理對訪問，並在UTF-8中的四個字節中編碼。

在每個平面中，字符被分配在相關字符的命名塊中。塊的大小始終是16個倍數，通常是128的倍數，但否則是任意的。給定腳本所需的字符可以分佈在代碼空間內的幾個不同的，潛在的分離塊上。

一般類別屬性

每個代碼點都分類為分類，列出為代碼點的一般類別屬性。在這裡，在最高級別的代碼點被歸類為字母，標記，數字，標點，符號，分離器或其他方面之一。在每個類別下，每個代碼點都會進一步分類。在大多數情況下，必須使用其他屬性來充分描述任何給定代碼點的所有特徵。

一般類別（Unicode字符屬性）
價值大專業，未成年人基本類型分配的字符數數
（截至15.1）		評論
L ，信； LC ，Cased Letter （LU，LL和LT）
魯信，大寫形象的特點1,831
二信，小寫形象的特點2,233
上尉字母，滴定酶形象的特點31結紮或二十張含有大寫酶，然後是小寫部分（例如， dž ， lj ， nj和dz ）
LM字母，修飾符形象的特點397修改器字母
LO信，其他形象的特點132,234意識形態或單個字母中的字母
M ，馬克
Mn馬克，非上方形象的特點1,985
MC馬克，間距組合形象的特點452
我標記，封閉形象的特點13
n ，數字
ND數字，十進制數字形象的特點680所有這些，只有這些，具有數字類型= de
NL號碼，信件形象的特點236由字母或字母式符號組成的數字（例如，羅馬數字）
不數字，其他形象的特點915例如，庸俗的分數，上標和下標數字
P ，標點符號
個人電腦標點符號，連接器形象的特點10包括間距下劃線字符，例如“ _”和其他間距領帶字符。與其他標點字符不同，這些字符可能被正則表達式庫歸類為“單詞”字符。
PD標點符號，破折號形象的特點26包括幾個連字符
PS標點符號，開放形象的特點79打開括號字符
PE標點符號，關閉形象的特點77關閉括號字符
pi標點符號，初始報價形象的特點12開頭報價標記。不包括ASCII“中性”引號。根據使用情況的行為可能像PS或PE
pf標點符號，最終報價形象的特點10關閉引號標記。根據使用情況的行為可能像PS或PE
po標點符號，其他形象的特點628
S ，符號
SM符號，數學形象的特點948數學符號（例如， + ， - ， = ， × ， ÷ ， √ ， ∊ ， ≠ ）。不包括類別PS和PE的括號和括號。也不包括！ ， * ， -或 /或 /或/或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/ /或/”主要被認為是“標點符號”。
sc符號，貨幣形象的特點63貨幣符號
SK符號，修飾符形象的特點125
所以符號，其他形象的特點6,639
Z ，分離器
ZS分離器，空間形象的特點17包括cc的空間，但不包括tab ， cr或lf
ZL分離器，線格式特點1僅U+2028線分離器（LSEP）
ZP分離器，段落格式特點1僅U+2029段落分隔符（PSEP）
C ，其他
CC其他，控制控制特點65（永遠不會改變）沒有名字，<控制>
CF其他，格式格式特點170包括軟連字符，連接控製字符（ ZWNJ和ZWJ ），支持雙向文本的控製字符以及語言標籤字符
CS其他，代理代理不（僅在UTF-16中使用）2,048（永遠不會改變）沒有名字，<替代>
公司其他私人用途私人使用角色（但沒有指定的解釋）總計137,468（永遠不會更改）（ BMP中有6,400 ，飛機131,068 15-16 ）沒有名字，<私人使用>
CN其他，未分配非特徵不是66（除非擴展Unicode代碼點的範圍，否則不會更改）沒有名字，<非character>
預訂的不是824,652沒有名字，<保留>
  1. “表4-4：常規類別” （PDF） 。 Unicode標準。 Unicode財團。 2022年9月。
  2. “表2-3：代碼點的類型” （PDF） 。 Unicode標準。 Unicode財團。 2022年9月。
  3. “ derivedGeneralCategory.txt” 。 Unicode聯盟。 2022-04-26。
  4. “ 5.7.1一般類別值” 。 UTR＃44：Unicode字符數據庫。 Unicode財團。 2020-03-04。
  5. Unicode字符編碼穩定性策略：屬性價值穩定性穩定性策略：某些GC組將永遠不會改變。 GC = ND對應於數字類型= DE（DECIMAL）。
  6. “附件C：兼容性屬性（§字）” 。 Unicode正則表達式。版本23. Unicode財團。 2022-02-08。 Unicode技術標準＃18。
  7. “表4-9：代碼點標籤的構建” （PDF） 。 Unicode標準。 Unicode財團。 2022年9月。代碼點標籤可用於識別無名代碼點。例如<Control- HHH >，<Control-0088>。該名稱仍然為空白，可以在文檔中無意中替換具有真實控制代碼的控件名稱。 Unicode還將<不是字符>用於<nonCharacter>。

這範圍內的1024點U+D800 - U+DBFF被稱為高溶劑代碼點，範圍內的代碼點U+DC00 - U+DFFF （U+DFFF）（ 1024代碼點）稱為低溶劑代碼點。高溶劑的代碼點，然後是低溶劑的代碼點，在UTF-16中形成替代對，以表示代碼點大於u+ffff 。原則上，這些代碼點不能否則使用，儘管實際上通常會忽略此規則，尤其是在不使用UTF-16時。

儘管第三方可以自行決定獨立使用它們，但絕不會將一小部分代碼點分配給角色。這些非特徵中有66個： u+fdd0 - u+fdef ，任何代碼點都以表示結尾FFFE或者FFFF（例如u+fffe ， u+ffff ， u+1fffe ， u+1ffff ，... u+10fffe等）。一組非特徵是穩定的，並且不會定義任何新的非特徵。像替代物一樣，儘管字節訂單標記的操作假定U+FFFE永遠不會是文本中的第一個代碼點，但通常會忽略這些規則。替代物和非特徵的排除葉1 111 998代碼點可供使用。

私有使用代碼點被認為是分配的，但是它們故意沒有由Unicode標準指定的解釋，因此此類代碼點的任何互換都需要發件人和接收者之間的獨立協議，以便對其解釋進行獨立協定. Unicode Codespace中有三個私人用途區域：

  • 私人使用區域： U+E000 - U+F8FF （ 6400個字符），
  • 補充私人使用區域-A： U+F0000 - U+FFFFD （ 65 534個字符），
  • 補充私人使用區域B： U+100000 - U+10FFFD （ 65 534個字符）。

圖形字符是由Unicode標準定義的，具有特定的語義，具有可見的字形形狀或表示可見空間。從Unicode 15.1開始149 641圖形字符。

格式字符是字符沒有可見的外觀，但可能會影響相鄰字符的外觀或行為。例如，可以使用U+200C零寬度非通路和U+200D零寬度木器來改變相鄰字符的默認形狀行為（例如抑制連接或請求結紮形成）。 Unicode 15.1中有172個格式字符。

65代碼點，範圍U+0000 - U+001F和U+007F - U+009F ，保留為控制代碼，對應於ISO/IEC 6429中定義的C0和C1控制代碼。 U+0089線路製表， U+008A線饋電和U+000D的返回返回，在使用Unicode的文本中廣泛使用。在一種稱為Mojibake的現像中，根據Windows-1252 CodePage（以前在西歐情況下廣泛使用的Windows-1252代碼）進行了不當解碼。

圖形，格式，控制代碼和私人使用字符共同稱為分配的字符。預留的代碼點是有效且可使用但尚未分配的代碼點。從Unicode 15.1開始824 652預留代碼點。

抽象字符

更多信息：通用字符設置字符§字符，譜系簇和字形

由Unicode定義的圖形和格式字符集並不直接與Unicode下代表的抽象字符的曲目相對應。 Unicode通過將抽象字符與特定代碼點關聯來編碼字符。但是，並非所有的抽象字符都被編碼為單個Unicode字符，並且某些抽象字符可以用兩個或多個字符的順序在Unicode中表示。例如，拉丁小字母“ i”，帶有ogonek ，上方的點，而在立陶宛語中需要的急性口音則由字符序列u+012f表示。 U+0307 ; U+0301 。 Unicode保留了未直接在Unicode中直接編碼的抽象字符的唯一命名的字符序列列表。

所有分配的字符都有一個唯一且不可變的名稱，可以通過這些名稱來識別它們。自Unicode標準的2.0版以來，已通過其名稱穩定性策略保證了這種不變性。如果一個名稱嚴重有缺陷且誤導性或嚴重的印刷錯誤，則可以定義正式的別名，以鼓勵應用程序代替正式角色名稱。例如， u+a015 yi音節WU具有正式的別名yi音節迭代標記，並且垂直右右胸骨胸罩kc et （ SIC ）的u+fe18 fe18 fe18 the呈現形式具有用於垂直右右邊膜狀胸骨bra ck的正式別名呈現形式等。

現成的與復合字符

Unicode包括一種修改字符的機制，該機制極大地擴展了受支持的字形曲目。這涵蓋了用戶可以在基本字符之後添加的組合標記的使用。多個組合變量可能會同時應用於同一特徵。 Unicode還包含正常使用中大多數字母/變性組合組合的預先複雜版本。這些使與舊版編碼的轉換更簡單，並允許應用程序將Unicode用作內部文本格式，而無需實現組合字符。例如，é可以在Unicode中表示為U+0065 E拉丁字母E ，然後是U+0301 ◌́結合急性重音），並將其等效地當作預先構成的字符u+00e9é拉丁文小字母E與急性。因此，用戶通常具有多種編碼相同字符的方式。 Unicode標準內規範等效的機制可確保這些等效編碼的實際互換性。

韓國字母hangul ：Unicode提供了一個例子，它提供了一種從其單獨的hangul Jamo子組件中構成孔音節的機制。但是，它也提供了11 172由最常見的jamo製成的預先組合的音節組合。

CJK字符目前僅具有無法構成的自由基和預先構成的形式的代碼。大多數han字符是故意由更簡單的拼字元素組成的，或重建為稱為激素的組成，因此原則上，Unicode可以像hangul一樣啟用其構圖。儘管這可能會大大減少所需的代碼點的數量，並允許許多任意新字符的算法綜合，但字符詞源的複雜性和自由基系統的事後性質的複雜性為提案增添了巨大的複雜性。的確，由於漢字不像漢庫爾（Hangul）那樣簡單或定期分解的現實，試圖根據構圖設計CJK編碼的嘗試遇到了困難。

CJK激方值補充塊分配給U+2E80 - U+2eff範圍，並將Kangxi自由基分配給U+2F00 - U+2FDF 。意識形態描述序列塊涵蓋範圍u+2ff0 - u+2ffb ，但是Unicode標準警告不要將其字符作為對其他地方編碼的字符的替代表示：

這個過程與意識形態的形式編碼不同。沒有對未編碼的意識形態的規範描述；沒有分配的語義分配給所描述的意識形圖。對於描述的意識形態，沒有定義的等效性。從概念上講，意識形態描述更類似於英語短語“ an e'具有急性重音”，而不是字符序列<u+0065，u+0301>。

結紮

Janasanskritsans的devanāgarīddhrya -ligatial （द
阿拉伯語Lām - alif綁紮（蕾中+ ا = 。 ）

許多腳本，包括阿拉伯語和Devanāgarī ，都有特殊的拼寫規則，需要將某些字母形式組合為特殊的綁紮形式。控制結紮形成的規則可能非常複雜，需要特殊的腳本整形技術，例如ACE（1980年代解釋的阿拉伯語書法引擎，並用於在Unicode標準的印刷版中生成所有阿拉伯語示例），這成為了證明Opentype （ Adobe and Microsoft），石墨（ SIL International ）或AAT （由Apple）的概念。

指令還嵌入字體中，以告訴操作系統如何正確輸出不同的字符序列。組合標記或變音符號的放置的一個簡單解決方案是將標記分配為零的寬度，並將字形本身放置在左側側背的左側或右側（取決於腳本的方向，它們旨在與他們一起使用）。以這種方式處理的標記將出現在任何角色之前的任何角色上，但不會根據基本雕文的寬度或高度調整其位置。它可能在視覺上很尷尬，並且可能重疊一些字形。真正的堆疊是不可能的，但可以在有限的情況下近似（例如，泰國頂級元音和音調標記可能只是在不同的高度開始）。通常，這種方法僅在單型字體中有效，但在更複雜的方法失敗時可以用作後備渲染方法。

標準化子集

Unicode的幾個子集是標準化的：Microsoft Windows，因為Windows NT 4.0支持具有657個字符的WGL-4 ，該字符被認為可以使用拉丁語，希臘語或西里爾腳本來支持所有當代歐洲語言。 Unicode的其他標準化子集包括多語言的歐洲子集：MES-1（僅拉丁文腳本，335個字符），Mes-2（拉丁語，希臘語和西里爾1062個字符）和MES​​-3A＆MES -3B（兩個較大的子集，不是兩個較大的子集此處顯示）。 MES-2包括MES-1和WGL-4中的每個字符。

標準DIN 91379指定了Unicode字母，特殊字符和字母和大聲符號序列的子集，以允許正確的名稱表示並簡化歐洲的數據交換。該標準支持所有歐盟國家的所有官方語言，以及德國少數族裔語言以及冰島，列支敦士登，挪威和瑞士的官方語言。為了根據相關的ISO標准允許其他寫作系統中的名稱對拉​​丁腳本進行音調，提供了基本字母和大聲符號的所有必要組合。

WGL-4 ， MES-1和MES-2
排細胞範圍
0020–7e基本拉丁語（00–7F）
A0 –ff拉丁-1補充（80 –ff）
0100–13，14–15，16–2b ， 2c – 2d， 2e – 4d， 4e – 4f， 50–7e， 7f拉丁語擴展-A （00–7F）
8f， 92， b7，de-ef， fa – ff拉丁語擴展-B （80 –ff ... ）
0218–1b，1e – 1f拉丁擴展-B（ ... 00–4F）
59、7C，92IPA擴展（50– AF）
BB – BD， C6， C7， C9， D6， D8 – DB， DC， DD， DF，EE間距修飾符字母（B0 – FF）
0374–75，7a，7e， 84–8a，8c，8e – A1，A3 – ce， d7，da – e1希臘語（70 –ff）
0400–5F，90–91，92 – C4，C7 – C8，CB – CC，D0 – EB，EE – F5，F8 – F9西里爾（00 – FF）
1e02–03，0a – 0b，1e – 1f，40–41，56–57，60–61，6a – 6b， 80–85，9b， 9b， f2 – f3拉丁語擴展額外（00 – FF）
1f00–15、18–1d，20–45、48–4d，50-57、59、59、5d，5d，5f – 7d，80 – B4，B6 – C4，C6 – d3，d6 – d6 – d6 – db，dd -ef，dd -ef，dd -ef，dd – ef， F2 – F4，F6 – fe希臘擴展（00 – FF）
2013-14、15、17、18-19、1a – 1b， 1c – 1d， 1e，20–22、26、30、32-33、39-3A，3C，3C，3E，44、4a一般標點符號（00-6F）
7f ，82上標和下標（70-9F）
A3 – A4，A7， AC， AF貨幣符號（A0 – CF）
2105、13、16、22、26、2e字母符號（00–4F）
5b – 5e數字表格（50–8F）
90–93，94–95 ，A8箭頭（90 –ff）
2200，02，03，06，08-09，0f， 0f ，11-12，15，13，1A，1E -1F， 27-28，29，2a，2a ， 2a，2b，48，48，59， 59，64-61，64-61，64-65 ， 82-83、95、97數學運算符（00 – FF）
2302，0a，20–21，29–2a雜項技術（00 – FF）
2500，02，0C，10，14，18，1c，24，2c，34，3c，50–6c盒子圖（00–7F）
80、84、88、8C，90–93塊元素（80–9f）
A0 – A1，AA – AC，B2，BA，BC，C4，CA – CB，CF，D8 – D9，E6幾何形狀（A0 – FF）
263a – 3c，40，42，60，63，65-66，6a ，6b其他符號（00 – FF）
F0(01–02)私人使用區域（00 –ff ...）
fb01–02字母呈現形式（00-4F）
fffd特價

無法正確處理Unicode字符的渲染軟件通常以開放矩形或u+fffd表示，以表示未識別字符的位置。一些系統已嘗試提供有關此類角色的更多信息。蘋果的最後一個度假字體將顯示一個替代字形，指示該角色的Unicode範圍，而SIL International的Unicode HalliCode Font將顯示一個盒子，顯示角色的十六進制標量值。

映射和編碼

已經指定了將一系列代碼點存儲為一系列字節的幾種機制。

Unicode定義了兩種映射方法： Unicode轉換格式（UTF）編碼和通用編碼的字符集（UCS）編碼。一個編碼地圖（可能是一個子集）Unicode代碼的範圍指向某些固定尺寸範圍內的值序列，稱為代碼單位。所有UTF編碼地圖代碼指向一個唯一的字節序列。編碼名稱中的數字表示每個代碼單元的位數（對於UTF編碼）或每個代碼單元的字節數（對於UCS編碼和UTF-1 ）。 UTF-8和UTF-16是最常用的編碼。 UCS-2是UTF-16的過時子集； UCS-4和UTF-32在功能上是等效的。

UTF編碼包括：

  • UTF-8 ，每個代碼使用一到四個字節，並且與ASCII具有最大兼容性
  • UTF-16 ，每個代碼點使用一個或兩個16位單元，但不能編碼替代
  • UTF-32 ，每個代碼點使用一個32位單元
  • UTF-EBCDIC ，未指定為UNICODE標準的一部分，該標準使用1到五個字節，旨在最大化與EBCDIC的兼容性

UTF-8使用每個代碼點一到四個字節，並且與拉丁文腳本和兼容ASCII兼容的緊湊型，為Unicode文本的互換提供了事實上的標準編碼。 FreeBSD和最新的Linux發行版將其用作一般文本處理中的舊版編碼的直接替換。

UCS-2和UTF-16編碼指定在文本文件的開始時使用的UNICODE字節訂單標記（BOM），該文件可用於字節級檢測（或字節eNDIANNESS檢測）。 BOM編碼為U+FEFF字節訂單標記，無論使用哪種UNICODE編碼，都具有字節重新排列的不具態度的重要屬性； u+fffe （字節交換u+feff的結果）不等於法律角色，而在文本開始以外的其他地方，u+feff傳達了零寬度的非爆發空間（一個沒有外觀和外觀和除了防止結紮的形成之外，沒有其他作用）。

轉換為UTF-8的相同字符變為字節序列EF BB BF。 Unicode標準允許BOM“可以用作未標記字符集的UTF-8編碼文本的簽名”。一些軟件開發人員已將其用於包括UTF-8在內的其他編碼，以試圖將UTF-8與本地8位代碼頁面區分開。但是，UTF-8標準RFC 3629建議使用UTF-8的協議中禁止字節訂單標記，但討論了可能無法實現的情況。此外，對UTF-8中可能模式的大限制（例如，沒有任何具有高鑽頭的單字節）意味著應該可以將UTF-8與其他字符編碼區分開而不依賴BOM。

在UTF-32和UCS-4中，一個32位代碼單元可作為任何角色代碼點的相當直接表示（儘管跨不同平台變化的Endianness會影響代碼單元表現為字節序列的方式）。在其他編碼中，每個代碼點可以用可變數量的代碼單元表示。 UTF-32被廣泛用作程序中文本的內部表示（而不是存儲或傳輸文本），因為每個使用GCC編譯器生成軟件的UNIX操作系統都將其用作標準的“寬字符”編碼。一些編程語言（例如SEED7 ）使用UTF-32作為字符串和字符的內部表示形式。 Python編程語言的最新版本（以2.2開頭）也可以配置為使用UTF-32作為UNICODE字符串的表示形式，從而有效地在高級編碼軟件中傳播了此類編碼。

PunyCode是另一種編碼形式，可以將Unicode字符串編碼為由ASCII基於ASCII的域名系統（DNS）支持的有限字符集。該編碼被用作IDNA的一部分，IDNA是一個系統，可以在Unicode支持的所有腳本中使用國際化域名。較早和現在的歷史建議包括UTF-5和UTF-6 。

GB18030是來自中國標準化管理的Unicode的另一種編碼形式。這是中華人民共和國（PRC）的官方角色集。 BOCU-1和SCSU是Unicode壓縮方案。 2005年四月的愚人節RFC指定了兩個模仿UTF編碼UTF-9和UTF-18 。

採用

另請參閱： UTF-8§

Unicode以UTF-8的形式是自2008年以來最常見的全球網絡編碼。它幾乎採用了全世界的採用，並且在其他Unicode編碼中可以找到許多非UTF-8內容，例如UTF，例如UTF -16 。截至2023年，UTF-8平均佔所有網頁的97.8％（以及排名最高的最高網頁的987個）。儘管許多頁面僅使用ASCII字符顯示內容，但UTF-8的設計為8位ASCII作為子集，幾乎沒有網站聲明其編碼僅為ASCII而不是UTF-8。跟踪的三分之一以上的語言具有100％的UTF-8使用。

自1998年出版RFC 2277以來，所有由Internet工程工作組維護的Internet協議都需要對UTF- 8的支持，該協議指定所有IETF協議“必須能夠使用UTF-8 CharSet”。

作業系統

Unicode已成為文本內部處理和存儲的主要方案。儘管仍然存儲了大量文本中的舊版編碼，但Unicode幾乎專門用於構建新的信息處理系統。早期採用者傾向於使用UCS-2 （UTF-16的固定長度兩字節過時的前體），然後遷移到UTF-16 （可變長度當前標準），因為這是增加對支持的最小破壞方法非BMP字符。最著名的系統是Windows NT （及其後代， 2000 ， XP ， Vista ， 7、8、10和11 ），它使用UTF- 16作為唯一的內部字符編碼。 Java和.NET字節碼環境， MACOS和KDE也將其用於內部表示。可以通過Microsoft層在Windows 9X上安裝對Unicode的部分支持。

UTF-8 （最初是為計劃9開發的）已成為大多數Unix式操作系統（儘管其他庫也使用了其他操作系統）上的主要存儲編碼，因為它是傳統的擴展擴展ASCII角色集的相對容易替換。 UTF-8也是萬維網上HTML文檔中使用的最常見的Unicode編碼。

使用Unicode的多語言文本渲染引擎包括Micosoft Windows的Uniscribe和DirectWrite ， ATSUI和MACOS的核心文本以及GTK+和GNOME桌面的Pango 。

輸入方法

主要文章： Unicode輸入

由於鍵盤佈局不能為所有角色具有簡單的鍵組合，因此幾個操作系統提供了允許訪問整個曲目的替代輸入方法。

ISO/IEC 14755標準化了從其代碼點輸入Unicode字符的方法，指定了幾種方法。有一個基本方法，其中開始序列之後是代碼點和結尾序列的十六進製表示。還有一個指定的屏幕選擇條目方法，其中字符在屏幕上的表中列出，例如字符映射程序。

在線查找已知角色代碼點的在線工具包括Jonathan Hedley的Unicode查找和Benjamin Milde的ShapeCatcher。在Unicode查找中，一個人輸入搜索鍵（例如“分數”），並返回了帶有代碼點的相應字符列表。在ShapeCatcher中，基於形狀上下文，返回了一個框中的字符，並返回了近似圖形的字符列表，並返回了及其代碼點。

電子郵件

主要文章： Unicode和電子郵件

Mime定義了在電子郵件中編碼非ASCII字符的兩種不同機制，具體取決於字符是否在電子郵件標題中（例如“主題：”），還是在郵件的文本主體中；在這兩種情況下，都確定了原始字符集以及傳輸編碼。對於Unicode的電子郵件傳輸，建議使用UTF-8字符集和Base64或引用的打印機傳輸編碼，具體取決於大部分消息是由ASCII字符組成的。這兩種不同機制的詳細信息在MIME標準中指定，通常隱藏在電子郵件軟件的用戶中。

IETF已使用UTF-8定義了國際電子郵件的框架，並根據該框架更新了多個協議。

在電子郵件中採用Unicode非常慢。某些東亞文本仍在編碼中編碼，例如ISO-2022 ，一些設備（例如手機）仍無法正確處理Unicode數據。但是，支持一直在改善。許多主要的免費郵件提供商，例如Yahoo！郵件， gmail和outlook.com支持它。

網絡

主要文章： Unicode和HTML

自HTML 4.0以來，所有W3C建議都將Unicode用作其文檔字符集。 Web瀏覽器已支持Unicode，尤其是UTF-8，多年來。曾經有主要來自與字體相關的問題產生的顯示問題；例如，Microsoft Internet Explorer的V6及以上的V6及以上的代碼點不會呈現許多代碼點，除非明確告知使用包含它們的字體。

儘管語法規則可能會影響允許字符出現的順序，但XML （包括XHTML ）文檔，根據定義，構成了大多數Unicode代碼點的字符，除了：

  • FFFE或FFFF。
  • 大多數C0控制代碼，
  • 永久未分配的代碼點D800 – DFFF，

HTML字符可以根據文檔的編碼直接表現為字節，如果編碼支持它們，或者用戶可以根據字符的Unicode代碼點將其寫入數字字符引用。例如，引用&#916;,&#1049;,&#1511;,&#1605;,&#3671;,&#12354;,&#21494;,&#33865;， 和&#47568;（或在十六進制中表達的相同數字值，&#x由於前綴）應顯示在所有瀏覽器上，例如δ，й，ק，ק，๗，あ，葉，葉和말。

當指定URI時，例如，作為HTTP請求中的URL ，必須對非ASCII字符進行編碼。

字體

主要文章： Unicode字體

Unicode原則上與字體本身無關，將其視為實施選擇。從更常見的大膽，斜體和基本字母形式到復雜的裝飾風格，任何給定的角色都可能具有許多分類。如果可以使用Unicode標準中定義的代碼點訪問字體中的字形，則字體為“ Unicode符合”。該標準未指定必須在字體中包含的最小字符。一些字體的曲目很小。

基於Unicode的免費和零售字體可廣泛使用，因為TrueType和Opentype支持Unicode（以及Web Open Open Font格式（Woff和Woff2 ）基於這些）。這些字體格式將Unicode代碼指向字形，但Opentype和TrueType字體文件僅限於65,535個字形。收集文件提供了一種“間隙模式”機制，用於在單個字體文件中克服此限制。 （但是，該集合中的每種字體仍然具有65,535的限制。）TrueType集合文件通常具有“ .ttc”的文件擴展名。

市場上存在成千上萬個字體，但少於十幾個字體（有時被稱為“ pan-unicode”字體）來支持Unicode的大多數角色曲目。取而代之的是，基於Unicode的字體通常專注於僅支持基本的ASCII和特定腳本或字符或符號集。幾個原因證明了這種方法：應用程序和文檔很少需要從一個或兩個寫作系統中呈現字符；字體傾向於在計算環境中需要資源；操作系統和應用程序顯示，根據需要從單獨的字體文件中獲取字形信息，即替代字體替換方面的智能越來越大。此外，設計一套一致的針對成千上萬個字形的渲染指令構成了一項艱鉅的任務。這樣的冒險經歷了大多數字體的回報減少點。

新線

Unicode部分解決了嘗試在不同平台上讀取文本文件時發生的新線問題。 Unicode定義了符合應用程序的大量字符應識別為線路終止器。

在Newline方面，Unicode引入了U+2028行分隔符和U+2029段落分隔符。這是一種嘗試提供一個Unicode解決方案，以語義上編碼段落和線條，並有可能替代所有各種平台解決方案。這樣一來，Unicode確實提供了一種與歷史平台相關的解決方案的方法。但是，很少有Unicode解決方案採用這些Unicode線和段落分隔符作為唯一的規範線結束字符。但是，解決此問題的常見方法是通過Newline歸一化。這是通過Mac OS X中的可可文本系統以及W3C XML和HTML建議來實現的。在這種方法中，每個可能的newline字符都會在內部轉換為一個通用的新線（這並不重要，因為它只是用於渲染的內部操作）。換句話說，無論輸入的實際編碼如何，文本系統都可以正確地將字符視為新線。

問題

角色統一

漢統一

主要文章：漢統一

意識形態研究小組（IRG）的任務是就HAN統一或Unihan的聯盟和ISO提供建議，尤其是在曲目中進一步添加CJK Unified和兼容性意識形態。 IRG由來自歷史上使用漢字的每個地區的專家組成。然而，儘管委員會內部進行了審議，但漢統一的始終是自項目起源以來Unicode標準中最有爭議的方面之一。

由於標準的編碼語義而不是風格變體的原則，Unicode因未分配某些稀有和古老的漢字變體的代碼點而受到批評，這可能會使古代日本名稱的處理變得複雜。 Han Unification有時會導致人們認為寫作系統本身正在合併，而不僅僅是基本角色表示。有幾項嘗試起草替代編碼，以保留區域性角色形式之間的各種風格差異，這與Unihan範式相反。一個例子是一些用戶對處理歷史日本文本的青睞，儘管日本公眾沒有被廣泛採用。

最早的Unicode版本的曲目少於21,000個漢字，很大程度上僅限於相對常見的現代用法。從版本15.1開始，該標準現在編碼了97,000多個HAN字符，並且工作正在繼續增加數千個（在整個Sinophere中使用的歷史和方言變體）。

現代字體提供了一種方法，以解決描繪具有各種區域圖形表示的統一漢字的一些實際問題。 “ locl” Opentype表允許渲染器根據文本語言環境為每個代碼點選擇一個不同的字形。 Unicode變化序列還可以為所需的字形選擇提供文本註釋；但是，尚未標準化han字符的此類序列。

西里爾語中的斜體或草書

帶有直立，傾斜和斜體替代形式的各種西里爾字符

如果相同腳本中的角色的適當字形僅在斜體上有所不同，那麼Unicode通常已經統一了它們，正如一組七個字符的斜體字形之間可以看到的那樣，通常出現在俄羅斯，傳統的保加利亞語，馬其頓語中，右邊的塞爾維亞文字，這意味著差異是通過智能字體技術或手動更改字體顯示的。使用相同的Opentype“ locl”技術。

映射到遺產角色集

Unicode旨在提供逐代碼點的代碼點往返格式的轉換，從任何先前存在的字符編碼轉換，以便可以將較舊字符集中的文本文件轉換為Unicode，然後返回並返回相同的文件，返回相同的文件，不採用與上下文有關的解釋。這意味著不一致的遺產體系結構（例如結合音節和預先組合的字符）都存在於Unicode中，提供了多種代表某些文本的方法。這在韓國hangul的三種不同編碼形式中最為明顯。由於版本3.0，因此無法再添加到已經存在的字符組合序列的任何預先組合的字符中，以使用不同版本的Unicode在軟件之間保持互操作性。

必須在現有舊字符集中的字符和Unicode中的字符之間提供注入性映射，以促進轉換為Unicode，並允許與舊軟件的互操作性。在較早的日語編碼（例如shift-jis或euc-jp和unicode）之間缺乏一致性，導致往返格式轉換不匹配，尤其是字符jis x 0208'〜'〜'''（1-33，wave dash）的映射，在舊數據庫數據中大量用於u+ ff5e〜fullwidth tilde （在Microsoft Windows中）或U+301C〜wave Dash （其他供應商）。

一些日本計算機程序員反對Unicode，因為它要求他們將U+005C \ ReverseSSIDUS （BackSlash）和U+00A5 ¥ YEN符號分開，該標誌在JIS X 0201中映射到0x5C，並且存在許多遺產代碼使用這種用法。 （此編碼還用Macron''（現在為0xaf）代替了Tilde'〜'0x7e。）這些字符的分離存在於ISO 8859-1中，與Unicode之前很久以前。

指示腳本

諸如泰米爾語和Devanagari之類的指示腳本僅分配128個代碼點，與ISCII標準匹配。 Unicode指示文本的正確渲染需要將存儲的邏輯字符轉換為視覺順序，並從組件中形成連接（也稱為conjuncts）。一些本地學者主張將Unicode代碼點分配到這些連接的分配，這違背了其他寫作系統的實踐，儘管Unicode僅包含一些阿拉伯語和其他連接，僅用於向後兼容。不可能發生Unicode中任何新的連接的編碼，部分原因是，連接集取決於字體，並且Unicode是獨立於字體變化的編碼。 2003年，藏族腳本出現了同樣的問題，當時中國的標準化管理提議編碼956個預先構成的藏族音節，但這些藏書是由相關ISO委員會（ ISO/IEC JTC 1/SC 2 ）拒絕編碼的。

泰語字母的支持因其對泰語角色的訂購而受到批評。與其他指示腳本的Unicode表示不同，在前面輔音的左側寫的元音เ，แ，โ，ใ，ไ，ไ，ไ，ไ，ไ，ไ，ไ，ไ這種並發症是由於Unicode繼承了以相同方式工作的泰國工業標準620 ，並且是泰語一直寫在鍵盤上的方式。這個排序問題使Unicode的整理過程變得複雜，需要表格查找才能重新排序泰語字符進行整理。即使Unicode根據口頭命令採用了編碼，以字典順序統一單詞仍然存在問題。例如，這個詞แสดง [sa dɛːŋ] “表演”以輔音群集“สด”（帶有輔音“ส”的固有元音），元音แ-，以口語順序出現，但在詞典中，單詞被整理為它是編寫的，元音跟隨ส。

結合字符

主要文章：結合角色
另請參閱： Unicode歸一化§歸一化

帶有變節標記的字符通常可以表示為單個預先組成的字符，也可以表示為基本字母的分解序列以及一個或多個非間隔標記。例如，應相同渲染（在上面使用Macron和急性E）和ḗ（e後面的Macron和上面的Macron組合）應相同渲染，兩者都以Macron （◌̄）和急性口音為E （◌）（◌ ） ́），但實際上，它們的外觀可能會有所不同，具體取決於使用哪些渲染引擎和字體來顯示角色。同樣，根據需要的羅馬化，通常會錯誤地放置下來。通常可以使用專業的Unicode字體（例如使用石墨， Opentype （'gsub'）或AAT技術來解決高級渲染功能的專家Unicode字體。

異常

主要文章： Unicode別名名稱和縮寫

Unicode標準施加了旨在確保穩定性的規則。根據規則的嚴格性，可以禁止或允許進行更改。例如，給出代碼點的“名稱”不能也不會更改。但是，根據Unicode自己的規則，“腳本”屬性更加靈活。在版本2.0中，Unicode從版本1中更改了許多代碼點“名稱”。同時，Unicode表示，從那時起，將分配的名稱轉換為代碼點永遠不會更改。這意味著，即使出現錯誤，這些錯誤也無法糾正，即使它們很瑣碎（就像一個實例中，帶有字符名稱中的括號的拼寫brakcet發生了）。在2006年，首次發布了字符名稱中的異常列表，截至2021年6月，有104個字符，有確定的問題：例如：

  • U+034F͏組合素木器：不連接素數。
  • u+2118℘腳本資本P ：這是一封小字母。資本為u+1d4ab𝒫數學腳本資本p 。
  • U+A015 Yi音節WU ：這不是Yi音節，而是Yi迭代標記。
  • U+Fe18 feartical右側透明膜布拉克塞的演示形式：括號拼寫不正確。 （通過使用Unicode別名名稱來解決拼寫錯誤。）

雖然Unicode將腳本指定器（名稱）定義為“ phags_pa ”，但在該腳本的字符名稱中，添加了連字符： u+a840 ꡀ phags-phags-pa letter ka 。但是，這不是異常，而是規則：連字符被腳本指定者中的下劃線取代。

安全

Unicode具有大量同素字體，其中許多看起來與ASCII字母非常相似或相同。這些替換可以製造出看起來正確的標識符或URL，但可以將其引導到與預期的不同位置。此外，同與同源物也可用於操縱自然語言處理（NLP）系統的輸出。緩解需要不承擔這些角色，以不同的方式顯示它們，或者要求它們解析為同一標識符；由於角色集巨大，不斷變化的人物集，所有這些都變得複雜。

兩名研究人員於2021年發布了一項安全諮詢，一名來自劍橋大學，另一位來自愛丁堡大學，他們斷言可以使用比迪商標來使大型代碼與他們看起來不同的事情做些不同的事情。去做。這個問題被命名為“特洛伊木馬來源”。作為響應，代碼編輯器開始突出顯示標記以指示強製文本方向更改。

也可以看看