Unicode是涵蓋世界上大多數書寫系統。用在網絡,大多數操作系統,JAVA和.NET的標準編碼等。
在Unicode誕生之前,都有自己的編碼,它們都不同,而且不兼容編碼。而Unicode是幾乎所有字符的超集,因此可以用于互換信息。
它誕生至今30多年了。
在開始下文之前,如果遇到查詢unicode代碼的,可以使用工具類網站https://unicode.yunser.com/unicode
Unicode 為每個字符(例如a,ã, ?,不和?)定義一個代碼/數字。從Unicode 6.2開始(http://www.unicode.org/versions/Unicode6.2.0/),共有109,976個代碼!
它還包括組合字符,諸如??之類,這些字符可以添加到其他字符中;這樣,Unicode不需要字母和重音的每種可能組合設置一個代碼。另一方面,Unicode的一般不關心字體或風格上的區別:比如下面兩個是同一種字符:
Unicode不只是字符集合。它還涵蓋了諸如UTF-8之類的標準編碼。小寫/大寫/標題大小寫映射,整理(排序),換行符,從右到左的腳本的渲染處理等。
通用歸一化/消除重復性
因為Unicode是其他編碼的超集,所以它有時包括同一個字符,但是卻有多個不同的代碼,例如,以下三個:
- 帶環的Å 拉丁大寫字母A(U + 00C5)
- 一個長度計量單位,一單位等于0.1nm(U + 212B)
- u'\u0041\u030a' , 大寫拉丁字母 A(U + 0041) + ?? 組合鍵(U + 030A)
Python輸出
為了使它們在相等性測試等中被視為相同的字符串,您應該通過Unicode規范(http://unicode.org/reports/tr15/)運行所有輸入。最常見的形式是 NFC(Normalisation Form C),它盡可能使用預先組合字符,并如果存在多個,則一個嚴格的順序定義這變音符號。NFD D(Normalisation Form D)則盡可能撰寫1個字符。只要您保持一致,使用哪種形式都沒有關系。NFD通常更快(代碼點更少),建議通過NFD運行輸入,并通過NFC輸出。
Compatibility decomposition/兼容性分解(NFKC,compatibility decomposition + canonical composition)會把?,Ⅸ和甚至?映射為為“FFI”,“IX”和“5”分別。搜索文本時,這種NFKC規范化功能會起到幫助。
大小寫折疊
在Unicode世界中,大小寫并不是那么簡單:
- 有些字符串在更改大小寫時實際上會更改長度:ß將大寫字母更改為“ SS”。
- 小號拉丁小寫字母渴望著應為“s”和“S”在不區分大小寫的比較被看作是相等的。
- Σ希臘大寫字母 Sigma有兩種小寫形式: 單詞的開頭或中間寫成σ,以及 ς在單詞的結尾。
- 在希臘語中,若一個單字的最末一個字母是sigma,要把該字母寫成 ς。大寫Σ可以表示: 數學上的求和符號。 粒子物理學中的一類重子。 小寫σ可以表示: σ鍵
- 外殼大多是在地區之間基本一致,但土耳其是個例外:它既有一個點線和帶點我,在這兩個小寫和大寫。
為了確保您的代碼能夠處理這些情況以及任何新的情況,Unicode提供了 一種單向 “ casefold”操作,該操作允許不區分大小寫的比較。
排序
排序(或排序規則)是特定于語言環境的,并且像大小寫一樣充滿特殊性:
- 德國和瑞典都有 ä和ö,但是它們排序不同。德國將它們視為相同的字母變體沒有變音符號(即“aä bcdefghijklmno öpqrstuvwxyz”),而瑞典認為在年底這些新的字母,并把它們放在最后('ABCDEFGHIJKLMNOPQRSTUVWXYZ äö)務必按照用戶期望的順序對事物進行排序。
- 排序也因應用程序而異;例如,電話簿的排序方式通常與書本索引不同。
- 對于漢字和其他表意文字,有許多可能的順序,例如拼音(注音),按筆劃計數等。
- 可以根據用戶偏好(例如,大寫優先還是小寫優先)來排序。
僅通過二進制比較進行排序是不夠的。而且,代碼點通常也不是明智的。幸運的是,Unicode指定了一種 可高度自定義的歸類算法,該算法涵蓋了所有邊緣情況,并且做了一些巧妙的工作以使其變得相當快。這是一個示例:2
該UCA可以把“10”和“2”視為數值,如排序“10”“放在“2”后面?” 。把“?”視為字符串“問號”。
編碼方式
大端序有UTF-8,UTF-16和UTF-32。每種編碼都保證幾乎每個碼點和字節序列的可逆映射。
- UTF-32非常簡單:每個代碼點用四個字節。占用大量空間,不建議用作信息互換。
- UTF-8在網絡上非常常見。它是面向字節的(無字節序問題),處理得很好,與ASCII兼容,并且對于大多數為ASCII(例如html)的文本占用最小的空間。U + 0800和U + FFFF之間的代碼點(包括常用的CJKV 字符/ 中國日本韓國越南)將占用3個字節而不是2個字節。因此,UTF-16可能更節省空間。ASCII兼容性有助于允許UTF-8在不支持Unicode的腳本和進程也能運行。但是,如果這樣的系統嘗試對數據執行任何操作(大小寫轉換,子字符串,正則表達式),則該數據會被損壞。
- Java,.NET和windows使用UTF-16。它使用2個字節(16位)表示最常見的63K代碼點,并使用4個字節表示不常見的1M代碼點(使用兩個“代理”代碼點)。與通常的做法相反,UTF-16不是固定寬度的編碼。但是,只要不包含代理代碼點,就可以將其視為一個獨立,從而可以加快字符串操作。UTF-16流通常以U + FEFF開頭,以檢測流的字節序(字節順序)。否則,您可以通過'UTF-16BE'或'UTF-16LE'顯式編碼或解碼以指定字節序。
Unicode和國際化域名
國際字符 給域名帶來了一個大問題。就像 I (I 0049 拉丁文大寫 I)和 l(l 006C拉丁L的小寫) 看起來很相似一樣,Unicode除了增加了許多不可見的控制字符,空格字符和從右到左的文本外,還將這個問題放大很多。
瀏覽器和注冊商已針對此采取了幾種措施:
- 許多頂級域名限制可以在域名中使用哪些字符。
- 如果域包含來自多個腳本的字符和/或不屬于用戶首選語言之一的字符,則瀏覽器可以使用Punycode顯示該域(請參見下文)。
- 國際化的國家/地區代碼,例如.рф(俄羅斯),僅接受西里爾字母名稱。
名稱準備/字符串準備
RFC 3491定義了nameprep,一種在字符串可以在域名中使用之前對字符串進行大小寫折疊,規范化和清理的機制。如果使用了禁止的代碼點,這將刪除許多不可見的字符并拋出異常。
Punycode/域名代碼
出于傳統原因,DNS不允許ASCII之外的擴展字符,因此Punycode是ASCII兼容的編碼方案。例如,café.com變為xn--caf-dma.com。所有Punycode編碼的域組件都可以通過其xn--前綴立即識別。
這也適用于頂級域名 :比如中國的代碼為xn-fiqs8s。
“用戶腳本”的問題
在Perl至少,一切(substr,length,index,reverse...)操作是以代碼點為準。但這通常不是你想要的,因為用戶認為像?這樣的字符實際上是兩個代碼點(y + ??)。
甚至看似沒問題的東西,例如printf "%-10s", $str完全中斷組合字符,全角字符(例如中文/日文)或零角字符的操作。
換行
一旦涉及到Unicode ,換行(或自動換行)就變得異常復雜。您必須考慮各種不間斷和不間斷的控制和空格字符,每種語言中的標點符號(例如«和»引號或數字中使用的句號或逗號)以及每個字符的寬度。
文件系統
當您使用Unicode字符串作為文件或目錄名稱時,所有操作都不好用。使用什么編碼?使用什么API?(Windows有兩種,一種使用Unicode,另一種嘗試使用與語言環境相關的編碼)。mac OSX文件系統則會執行規范化,例如對文件名執行NFD。如果您的平臺不了解分解后的Unicode,則可能會出現問題。
漢字統一
漢字是中文,日文(漢字)以及韓文和越南文的共同特征。根據腳本的不同,許多腳本都有獨特的視覺外觀,但是Unicode出于簡化和性能的原因將它們統一為一個代碼點(示例)。
這引起了爭議,因為角色的視覺形式可能有意義;可能不會向用戶顯示他們的國家/地區版本,而是其他國家/地區的版本。在某些情況下,它們看起來可能非常不同(例如,直)。正如西方名稱的變化(例如“ John”或“ Jon”)一樣,日語名稱可能使用Unicode無法提供的特定字形變體,因此人們實際上無法以自己喜歡的方式來寫自己的名字!
實際上,用戶選擇一種字體以其想要的樣式呈現字形,無論是日語還是中文。變體選擇器(參見下文)是解決該問題的另一種方法。
由于政治和遺留原因(與舊字符集兼容),Unicode不會嘗試統一簡體和繁體中文。
表情符號
Unicode 6.0版增加了722個“表情符號”字符,這些表情符號通常在日語手機上使用,但最近在Mac OS X(Lion),Gmail,iphone和Windows Phone 7中使用。某些字體可能選擇將其呈現為全彩色表情符號。 ; 有些則可能根本不支持他們。
表情符號的Unicode表示,包含你熟悉的LOVE HOTEL 和PILE OF POO
區域國旗符號
Unicode 6.0的表情符號為許多國家(地區)標志引入了符號,但并不是全部國家。作為一種可選方案,范圍U + 1F1E6 .. U + 1F1FF 定義了從A到Z的符號。如果該范圍中的兩個符號形成了ISO-3166-1國家代碼(例如,法國的“ FR”),則渲染器可以顯示為國旗!
變體選擇器
變體選擇器是代碼點,可更改渲染字符之前的字符方式。有256個,它們占據的范圍為U + FE00 .. U + FE0F 和U + E0100.. U + E01EF加上U + 180B,U + 180C和U + 180D。
它們對于蒙古語腳本來說是必不可少的,蒙古語腳本具有不同的字形形式,具體取決于其在單詞中的位置,單詞的性別,附近有哪些字母,單詞是否為外國單詞以及現代與傳統拼字法(詳細信息)。
預計這些將用于提供由Han Unification統一的字形的變體。
它們還用于更深奧的事物,例如數學運算符的襯線版本。