上個月,我做了一次分享,詳細介紹了Unicode字符集,以及JavaScript語言對它的支持。下面就是這次分享的講稿。
一、Unicode是什么?
Unicode源于一個很簡單的想法:將全世界所有的字符包含在一個集合里,計算機只要支持這一個字符集,就能顯示所有的字符,再也不會有亂碼了。
它從0開始,為每個符號指定一個編號,這叫做"碼點"(code point)。比如,碼點0的符號就是null(表示所有二進制位都是0)。
U+0000 = null
上式中,U+表示緊跟在后面的十六進制數是Unicode的碼點。
目前,Unicode的最新版本是7.0版,一共收入了109449個符號,其中的中日韓文字為74500個。可以近似認為,全世界現有的符號當中,三分之二以上來自東亞文字。比如,中文"好"的碼點是十六進制的597D。
U+597D = 好
這么多符號,Unicode不是一次性定義的,而是分區定義。每個區可以存放65536個(216)字符,稱為一個平面(plane)。目前,一共有17個(25)平面,也就是說,整個Unicode字符集的大小現在是221。
最前面的65536個字符位,稱為基本平面(縮寫BMP),它的碼點范圍是從0一直到216-1,寫成16進制就是從U+0000到U+FFFF。所有最常見的字符都放在這個平面,這是Unicode最先定義和公布的一個平面。
剩下的字符都放在輔助平面(縮寫SMP),碼點范圍從U+010000一直到U+10FFFF。
二、UTF-32與UTF-8
Unicode只規定了每個字符的碼點,到底用什么樣的字節序表示這個碼點,就涉及到編碼方法。
最直觀的編碼方法是,每個碼點使用四個字節表示,字節內容一一對應碼點。這種編碼方法就叫做UTF-32。比如,碼點0就用四個字節的0表示,碼點597D就在前面加兩個字節的0。
U+0000 = 0x0000 0000 U+597D = 0x0000 597D
UTF-32的優點在于,轉換規則簡單直觀,查找效率高。缺點在于浪費空間,同樣內容的英語文本,它會比ASCII編碼大四倍。這個缺點很致命,導致實際上沒有人使用這種編碼方法,HTML 5標準就明文規定,網頁不得編碼成UTF-32。
人們真正需要的是一種節省空間的編碼方法,這導致了UTF-8的誕生。UTF-8是一種變長的編碼方法,字符長度從1個字節到4個字節不等。越是常用的字符,字節越短,最前面的128個字符,只使用1個字節表示,與ASCII碼完全相同。
編號范圍 | 字節 |
0x0000 - 0x007F | 1 |
0x0080 - 0x07FF | 2 |
0x0800 - 0xFFFF | 3 |
0x010000 - 0x10FFFF | 4 |
由于UTF-8這種節省空間的特性,導致它成為互聯網上最常見的網頁編碼。不過,它跟今天的主題關系不大,我就不深入了,具體的轉碼方法,可以參考我多年前寫的《字符編碼筆記》。
三、UTF-16簡介
UTF-16編碼介于UTF-32與UTF-8之間,同時結合了定長和變長兩種編碼方法的特點。
它的編碼規則很簡單:基本平面的字符占用2個字節,輔助平面的字符占用4個字節。也就是說,UTF-16的編碼長度要么是2個字節(U+0000到U+FFFF),要么是4個字節(U+010000到U+10FFFF)。
于是就有一個問題,當我們遇到兩個字節,怎么看出它本身是一個字符,還是需要跟其他兩個字節放在一起解讀?
說來很巧妙,我也不知道是不是故意的設計,在基本平面內,從U+D800到U+DFFF是一個空段,即這些碼點不對應任何字符。因此,這個空段可以用來映射輔助平面的字符。
具體來說,輔助平面的字符位共有220個,也就是說,對應這些字符至少需要20個二進制位。UTF-16將這20位拆成兩半,前10位映射在U+D800到U+DBFF(空間大小210),稱為高位(H),后10位映射在U+DC00到U+DFFF(空間大小210),稱為低位(L)。這意味著,一個輔助平面的字符,被拆成兩個基本平面的字符表示。
所以,當我們遇到兩個字節,發現它的碼點在U+D800到U+DBFF之間,就可以斷定,緊跟在后面的兩個字節的碼點,應該在U+DC00到U+DFFF之間,這四個字節必須放在一起解讀。
四、UTF-16的轉碼公式
Unicode碼點轉成UTF-16的時候,首先區分這是基本平面字符,還是輔助平面字符。如果是前者,直接將碼點轉為對應的十六進制形式,長度為兩字節。
U+597D = 0x597D
如果是輔助平面字符,Unicode 3.0版給出了轉碼公式。
H = Math.floor((c-0x10000) / 0x400)+0xD800 L = (c - 0x10000) % 0x400 + 0xDC00
以字符為例,它是一個輔助平面字符,碼點為U+1D306,將其轉為UTF-16的計算過程如下。
H = Math.floor((0x1D306-0x10000)/0x400)+0xD800 = 0xD834 L = (0x1D306-0x10000) % 0x400+0xDC00 = 0xDF06
所以,字符的UTF-16編碼就是0xD834 DF06,長度為四個字節。
五、JavaScript使用哪一種編碼?
JavaScript語言采用Unicode字符集,但是只支持一種編碼方法。
這種編碼既不是UTF-16,也不是UTF-8,更不是UTF-32。上面那些編碼方法,JavaScript都不用。
JavaScript用的是UCS-2!
六、UCS-2編碼
怎么突然殺出一個UCS-2?這就需要講一點歷史。
互聯網還沒出現的年代,曾經有兩個團隊,不約而同想搞統一字符集。一個是1988年成立的Unicode團隊,另一個是1989年成立的UCS團隊。等到他們發現了對方的存在,很快就達成一致:世界上不需要兩套統一字符集。
1991年10月,兩個團隊決定合并字符集。也就是說,從今以后只發布一套字符集,就是Unicode,并且修訂此前發布的字符集,UCS的碼點將與Unicode完全一致。
UCS的開發進度快于Unicode,1990年就公布了第一套編碼方法UCS-2,使用2個字節表示已經有碼點的字符。(那個時候只有一個平面,就是基本平面,所以2個字節就夠用了。)UTF-16編碼遲至1996年7月才公布,明確宣布是UCS-2的超集,即基本平面字符沿用UCS-2編碼,輔助平面字符定義了4個字節的表示方法。
兩者的關系簡單說,就是UTF-16取代了UCS-2,或者說UCS-2整合進了UTF-16。所以,現在只有UTF-16,沒有UCS-2。
七、JavaScript的誕生背景
那么,為什么JavaScript不選擇更高級的UTF-16,而用了已經被淘汰的UCS-2呢?
答案很簡單:非不想也,是不能也。因為在JavaScript語言出現的時候,還沒有UTF-16編碼。
1995年5月,Brendan Eich用了10天設計了JavaScript語言;10月,第一個解釋引擎問世;次年11月,Netscape正式向ECMA提交語言標準(整個過程詳見《JavaScript誕生記》)。對比UTF-16的發布時間(1996年7月),就會明白Netscape公司那時沒有其他選擇,只有UCS-2一種編碼方法可用!
八、JavaScript字符函數的局限
由于JavaScript只能處理UCS-2編碼,造成所有字符在這門語言中都是2個字節,如果是4個字節的字符,會當作兩個雙字節的字符處理。JavaScript的字符函數都受到這一點的影響,無法返回正確結果。
還是以字符為例,它的UTF-16編碼是4個字節的0xD834 DF06。問題就來了,4個字節的編碼不屬于UCS-2,JavaScript不認識,只會把它看作單獨的兩個字符U+D834和U+DF06。前面說過,這兩個碼點是空的,所以JavaScript會認為
是兩個空字符組成的字符串!
上面代碼表示,JavaScript認為字符的長度是2,取到的第一個字符是空字符,取到的第一個字符的碼點是0xDB34。這些結果都不正確!
解決這個問題,必須對碼點做一個判斷,然后手動調整。下面是正確的遍歷字符串的寫法。
while (++index < length) { // ... if (charCode >= 0xD800 && charCode <= 0xDBFF) { output.push(character + string.charAt(++index)); } else { output.push(character); } }
上面代碼表示,遍歷字符串的時候,必須對碼點做一個判斷,只要落在0xD800到0xDBFF的區間,就要連同后面2個字節一起讀取。
類似的問題存在于所有的JavaScript字符操作函數。
- String.prototype.replace()
- String.prototype.substring()
- String.prototype.slice()
- ...
上面的函數都只對2字節的碼點有效。要正確處理4字節的碼點,就必須逐一部署自己的版本,判斷一下當前字符的碼點范圍。
九、ECMAScript 6
JavaScript的下一個版本ECMAScript 6(簡稱ES6),大幅增強了Unicode支持,基本上解決了這個問題。
(1)正確識別字符
ES6可以自動識別4字節的碼點。因此,遍歷字符串就簡單多了。
for (let s of string ) { // ... }
但是,為了保持兼容,length屬性還是原來的行為方式。為了得到字符串的正確長度,可以用下面的方式。
Array.from(string).length
(2)碼點表示法
JavaScript允許直接用碼點表示Unicode字符,寫法是"反斜杠+u+碼點"。
'好' === '\u597D' // true
但是,這種表示法對4字節的碼點無效。ES6修正了這個問題,只要將碼點放在大括號內,就能正確識別。
(3)字符串處理函數
ES6新增了幾個專門處理4字節碼點的函數。
- String.fromCodePoint():從Unicode碼點返回對應字符
- String.prototype.codePointAt():從字符返回對應的碼點
- String.prototype.at():返回字符串給定位置的字符
(4)正則表達式
ES6提供了u修飾符,對正則表達式添加4字節碼點的支持。
(5)Unicode正規化
有些字符除了字母以外,還有附加符號。比如,漢語拼音的ǒ,字母上面的聲調就是附加符號。對于許多歐洲語言來說,聲調符號是非常重要的。
Unicode提供了兩種表示方法。一種是帶附加符號的單個字符,即一個碼點表示一個字符,比如ǒ的碼點是U+01D1;另一種是將附加符號單獨作為一個碼點,與主體字符復合顯示,即兩個碼點表示一個字符,比如ǒ可以寫成O(U+004F) + ˇ(U+030C)。
// 方法一 '\u01D1' // 'ǒ' // 方法二 '\u004F\u030C' // 'ǒ'
這兩種表示方法,視覺和語義都完全一樣,理應作為等同情況處理。但是,JavaScript無法辨別。
'\u01D1'==='\u004F\u030C' //false
ES6提供了normalize方法,允許"Unicode正規化",即將兩種方法轉為同樣的序列。
'\u01D1'.normalize() === '\u004F\u030C'.normalize() // true
關于ES6的更多介紹,請看《ECMAScript 6入門》。
==========================
我的講稿就是上面這些內容,當天的PPT請看這里。
(完)
passer 說:
哈哈,博主也是Futurama愛好者嗎
2014年12月11日 14:03 | # | 引用
paster 說:
最后的「以字符」是什么意思,是不是沒寫完?
2014年12月11日 14:21 | # | 引用
holyzfy 說:
頭圖是B52么
2014年12月11日 14:53 | # | 引用
阮一峰 說:
@paster:
文章貼出來才發現,這個blog程序會自動截斷輔助平面的字符。
手忙腳亂得收拾了半天,把該文字都換成了圖片……
2014年12月11日 14:57 | # | 引用
秣馬兒 說:
應試是
U+0000 = 0x00 00 00 00
U+597D = 0x00 00 59 7D
吧?
2014年12月11日 15:08 | # | 引用
阮一峰 說:
@秣馬兒:謝謝指出,確實寫錯了,已經改過來了。
2014年12月11日 15:19 | # | 引用
Dennis Gao 說:
挺好的,感謝科普
2014年12月11日 16:13 | # | 引用
iceli 說:
1988年成立的UCS團隊 這個時間和圖片里的時間不一致啊。
2014年12月11日 17:47 | # | 引用
Henry 說:
看了博主很多文章都不錯,能分享下博主的學習規劃嗎,是怎么安排的
2014年12月12日 08:37 | # | 引用
wind-stone 說:
贊!簡單易懂,學習了!
2014年12月12日 09:38 | # | 引用
李之若 說:
JavaScript允許直接用碼點表示Unicode字符,寫法是"斜杠+u+碼點"。
應該是反斜杠吧阮兄。
2014年12月13日 01:54 | # | 引用
阮一峰 說:
@李之若:謝謝指出已經改過來了。
2014年12月13日 10:10 | # | 引用
Owen 說:
> 一個是1988年成立的UCS團隊,另一個是1989年成立的Unicode團隊。
這句與你Slides里的時間,剛好相反。
2014年12月13日 10:23 | # | 引用
阮一峰 說:
@Owen:
謝謝指出,已經改正了。
2014年12月13日 14:59 | # | 引用
一頁筆記 說:
大哥,我轉載了你的文章,都標注了作者。之前轉的一些,在文章后留下了來源信息。請問這樣有問題嗎?轉載似乎是有規則的,我才做博客兩個月,不懂,那天看到一篇批評轉載的文章,誠惶誠恐,求指教。
2014年12月13日 19:09 | # | 引用
feng smith 說:
“目前,一共有17個(2^5)平面”,17是怎么來的?是不是應為32?
2014年12月16日 14:29 | # | 引用
Purity 說:
阮老師的PPT我看了,簡潔明了,很高大上。因為日常中經常演講展示,我想學習一下PPT的做法,阮老師可以提供這個PPT下載嗎?我郵箱地址[email protected]。PS.我的這種行為不妥,阮老師也可以拒絕,我仍然感謝。
2014年12月17日 12:33 | # | 引用
yanhaijing 說:
很贊啊,正需要這個知識
2014年12月17日 14:02 | # | 引用
iwbpm 說:
終于知道以前那個惡魔般的js亂碼和執行異常的問題是怎么回事了!
感謝。
2014年12月17日 20:35 | # | 引用
bbx 說:
博主你好,我現在是一名高中生,突然發現自己對計算機比較感興趣。剛剛開始自學計算機語言,是學的Java語言。請問可以先學Java語言嗎?我應該注意些什么呢?剛才無意中搜到了您的個人blog,讀了幾篇文章,對我很有啟發,謝謝!
2014年12月18日 09:30 | # | 引用
江楓 說:
1. 沒什么不可以的,編程就像寫作文或是解數學題,如果你作文就沒好過,解數學題的思路也一般般,及時放棄,干干別的吧
2. 你說你對計算機感興趣,說說為什么,喜歡一件事情總是可以說出很多原因的,別腦子短路想不到。
3. 注意的地方
a. 不要為了編程而編程,語言只是一個工具,用來解決實際遇到的問題的,
b. 數學很重要,趁年輕多學點
c. 趁年輕多讀讀小說,
d. 外語也挺重要,趁年輕多學點
e. 朋友也挺重要,別沒事一個人窩著
f. 鍛煉身體這件事最重要,別荒廢了
g. 看了就會的東西,不能成為競爭力,學了依舊不會,這才是競爭力,社會挺浮躁,學會能夠讓自己安靜下來。
2014年12月27日 22:44 | # | 引用
xiaorui 說:
阮老師,您的博客簡潔清晰突出內容,想問一下您的blog程序是什么?
2014年12月29日 16:34 | # | 引用
xinwendashibaike 說:
基本平面只需要16位,輔助平面就是加了8,共24位,剩下還有8位,應該是utf-24比較自然吧
2015年1月 7日 13:15 | # | 引用
xinwendashibaike 說:
目前只定義了17個,其他都沒用使用
2015年1月 7日 13:17 | # | 引用
linchen 說:
深入理解了,感謝好文章。
2015年1月12日 00:41 | # | 引用
hhjh 說:
非常好的文章,很有幫助
2015年1月18日 11:23 | # | 引用
xinwendashibaike 說:
character + string.charAt(++index)
為什么加起來就可以轉換?
2015年1月27日 14:07 | # | 引用
anthony 說:
幾個建議:
code point不妨譯為碼位.
0xD8XX那一段實在寫的不清楚,建議改成二進制表示:UTF16首字前6位為110110,次字前6位為110111
UTF16的轉碼公式實在奇怪,為什么要用除0x400來表示右移10位呢?
firstword = (unicode >>> 10) + 0xD800;
secondword = (unicode & 0x3ff) + 0xDC00;
2015年1月29日 15:39 | # | 引用
leezq 說:
是啊.這里我也想不通。三個字節就可以容納Unicode的所有碼點了,這樣一來感覺UTF-24比UTF-32要更加科學。阮老師能否解釋下。
2015年5月22日 11:33 | # | 引用
mihooke 說:
最近正在看rapidJSON,對里面的編碼搞得一塌糊涂,幸虧看到了阮哥這篇文章,受教了!
2015年6月11日 11:49 | # | 引用
前端愛好者 說:
2015年6月17日 09:50 | # | 引用
fuadam1982 說:
Array.from(string).length 在 node --harmony下提示找不到定義。
2015年7月31日 16:43 | # | 引用
Jerry 說:
> 這么多符號,Unicode不是一次性定義的,而是分區定義。每個區可以存放65536個(2^16)字符,稱為一個平面(plane)。
> 目前,一共有17個(25)平面,也就是說,整個Unicode字符集的大小現在是2^21。
*這里有點錯誤,如果是17個平面的話,整個Unicode字符集的大小是(2^20+2^16)。*
2016年4月14日 14:48 | # | 引用
jadecoder 說:
版權聲明:自由轉載 - 非商用 - 非衍生 - 保持署名(創意共享 3.0 許可證)
http://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh
2016年5月19日 14:38 | # | 引用
waiting 說:
js還算運氣好核心字符集有ucs2可選,比js早那么兩年出生的python可就慘了,不得不在phton3.0版本改變核心字符集設計使得對以前py1,py2有很大不兼容,導致py3的推廣大大受阻
2016年6月21日 20:28 | # | 引用
JackZhouMine 說:
阮老師你好,關注你很久了,請問圖片是咋個做的?好棒啊 !另外,有一張圖里的平面的英文單詞Plane寫錯成了plain。 希望告知下做圖片的軟件。
2016年6月22日 20:53 | # | 引用
Viky 說:
那Js后面不改用UTF-8的原因是因為兼容性?
還是UTF-16比UTF-8更適合內部字符串實現(如性能更好?)?
2016年10月10日 09:15 | # | 引用
ja 說:
您的文章排版都特別好看!
2017年1月 6日 20:46 | # | 引用
chappie 說:
實現utf32只需要3個字節也就是2^24位就可以了,多的那一個字節就一直空著?
2017年1月20日 13:17 | # | 引用
Johnson 說:
阮老大的文章真好,堅持讀,一定收獲多多
2017年2月 8日 14:44 | # | 引用
abc 說:
軟老大, 有個疑問呀。你看到的時候,麻煩老大,抽空給回復下。謝謝先。
就是 js采用ucs2 編碼 字符串, 我的頁面是 UTF8編碼, 后臺服務器也是UTF8編碼。
那 為什么 不會亂碼呢?
真不懂啊。老大給科普下吧。謝謝啦。
2017年4月28日 09:46 | # | 引用
mark 說:
js算不錯了至少有ucs2可用。比js早幾年誕生的python就悲催了,核心是ascii的結果導致py2和py3的分裂
2017年7月21日 00:14 | # | 引用
云庫網 說:
看完了還有很沒看明白,腦子有點亂了,不過確實寫得很詳細,很給力。
2017年11月20日 22:46 | # | 引用
ma.nong 說:
1??2??3??4??5??6??7??8??9??0??
這種怎么解? 這其實是一個表情字符串,用js怎么判斷它是一個表情字符呢?
2017年12月14日 18:39 | # | 引用
minging 說:
阮老師,ǒ好像是'\u01D2'
2018年1月21日 22:57 | # | 引用
bear 說:
如果是輔助平面字符,Unicode 3.0版給出了轉碼公式。
H = Math.floor((c-0x10000) / 0x400)+0xD800
L = (c - 0x10000) % 0x400 + 0xDC00
這個公式應該怎么理解,為什么這樣計算就可以轉換成功
2018年6月26日 17:44 | # | 引用
icymind 說:
感謝阮老師幫我梳理了編碼的知識.
我根據阮老師的文章也寫了一篇博客, 希望可以幫助到有需要的朋友.
地址在: icymind.com/sizeof/
博文涵蓋了:
1. UTF-32 明明24bit 就綽綽有余的情況下為什么還是用了4個字節
2. UTF-16 的編碼公式為什么是這樣?
3. 通過自己設計一個unicode 編碼格式來了解 UTF-8
2018年12月15日 23:34 | # | 引用
Nfboys 說:
找了一天資料,直到發現這篇,終于懂了……
2019年5月30日 11:43 | # | 引用
zhangxin 說:
阮老師,我有一個疑問。希望您能看到
關于原文八、JavaScript字符函數的局限這章
`????` 字符的 Unicode 編碼是 `\u{1d306}`,`"????".charCodeAt(0)`的返回值是 `U+D834`。既然 JS 是不支持 UTF-16 的,那么怎么會返回字符的 UTF-16 編碼的前兩個字節呢?這個字符的 UTF-16 編碼 JS 是怎么獲得的呢?要返回前兩個字節首先要獲得完整的 UTF-16 編碼吧。如果 JS 只支持 UCS-2,個人認為這個邏輯是說不通的。
mdn關于`charCodeAt()`是這么說的。
> charCodeAt()** 方法返回0到65535之間的整數,表示給定索引處的UTF-16代碼單元 (在 Unicode 編碼單元表示一個單一的 UTF-16 編碼單元的情況下,UTF-16 編碼單元匹配 Unicode 編碼單元。但在——例如 Unicode 編碼單元 > 0x10000 的這種——不能被一個 UTF-16 編碼單元單獨表示的情況下,只能匹配 Unicode 代理對的第一個編碼單元) 。如果你想要整個代碼點的值,使用 **codePointAt**()。
2019年8月12日 20:44 | # | 引用
CatY 說:
utf-16是usc-2的超級,utf-8也可以表示utf-16的所有字符,那usc-2的字符,不都可以用uft-8編碼方式表示了?我的理解。
2019年10月12日 17:21 | # | 引用