U+0000 = null 

目前，Unicode 的***版本是 7.0 版，一共收入了 109449 個(gè)符號，其中的中日韓文字為 74500 個(gè)?？梢越普J(rèn)為，全世界現(xiàn)有的符號當(dāng)中，三分之二以上來自東亞文字。比如，中文"好"的碼點(diǎn)是十六進(jìn)制的 597D。

U+597D = 好 

這么多符號，Unicode 不是一次性定義的，而是分區(qū)定義。每個(gè)區(qū)可以存放 65536 個(gè)（216）字符，稱為一個(gè)平面（plane）。目前，一共有 17 個(gè)（25）平面，也就是說，整個(gè) Unicode 字符集的大小現(xiàn)在是221。

最前面的 65536 個(gè)字符位，稱為基本平面（縮寫 BMP），它的碼點(diǎn)范圍是從 0 一直到216-1，寫成 16 進(jìn)制就是從U+0000 到U+FFFF。所有最常見的字符都放在這個(gè)平面，這是 Unicode ***定義和公布的一個(gè)平面。

剩下的字符都放在輔助平面（縮寫 SMP），碼點(diǎn)范圍從U+010000 一直到U+10FFFF。

二、UTF-32 與 UTF-8

Unicode 只規(guī)定了每個(gè)字符的碼點(diǎn)，到底用什么樣的字節(jié)序表示這個(gè)碼點(diǎn)，就涉及到編碼方法。

最直觀的編碼方法是，每個(gè)碼點(diǎn)使用四個(gè)字節(jié)表示，字節(jié)內(nèi)容一一對應(yīng)碼點(diǎn)。這種編碼方法就叫做 UTF-32。比如，碼點(diǎn) 0 就用四個(gè)字節(jié)的 0 表示，碼點(diǎn) 597D 就在前面加兩個(gè)字節(jié)的0。

U+0000 = 0x0000 0000 
U+597D = 0x0000 597D 

UTF-32 的優(yōu)點(diǎn)在于，轉(zhuǎn)換規(guī)則簡單直觀，查找效率高。缺點(diǎn)在于浪費(fèi)空間，同樣內(nèi)容的英語文本，它會(huì)比 ASCII 編碼大四倍。這個(gè)缺點(diǎn)很致命，導(dǎo)致實(shí)際上沒有人使用這種編碼方法，HTML 5 標(biāo)準(zhǔn)就明文規(guī)定，網(wǎng)頁不得編碼成 UTF-32。

[[124342]]

人們真正需要的是一種節(jié)省空間的編碼方法，這導(dǎo)致了 UTF-8 的誕生。UTF-8 是一種變長的編碼方法，字符長度從 1 個(gè)字節(jié)到 4 個(gè)字節(jié)不等。越是常用的字符，字節(jié)越短，最前面的 128 個(gè)字符，只使用 1 個(gè)字節(jié)表示，與 ASCII 碼完全相同。

編號范圍	字節(jié)
0x0000 - 0x007F	1
0x0080 - 0x07FF	2
0x0800 - 0xFFFF	3
0x010000 - 0x10FFFF	4

三、UTF-16 簡介

由于 UTF-8 這種節(jié)省空間的特性，導(dǎo)致它成為互聯(lián)網(wǎng)上最常見的網(wǎng)頁編碼。不過，它跟今天的主題關(guān)系不大，我就不深入了，具體的轉(zhuǎn)碼方法，可以參考我多年前寫的《字符編碼筆記》。

UTF-16 編碼介于 UTF-32 與 UTF-8 之間，同時(shí)結(jié)合了定長和變長兩種編碼方法的特點(diǎn)。

它的編碼規(guī)則很簡單：基本平面的字符占用 2 個(gè)字節(jié)，輔助平面的字符占用 4 個(gè)字節(jié)。也就是說，UTF-16 的編碼長度要么是 2 個(gè)字節(jié)（U+0000 到U+FFFF），要么是 4 個(gè)字節(jié)（U+010000 到U+10FFFF）。

于是就有一個(gè)問題，當(dāng)我們遇到兩個(gè)字節(jié)，怎么看出它本身是一個(gè)字符，還是需要跟其他兩個(gè)字節(jié)放在一起解讀？

說來很巧妙，我也不知道是不是故意的設(shè)計(jì)，在基本平面內(nèi)，從U+D800 到U+DFFF 是一個(gè)空段，即這些碼點(diǎn)不對應(yīng)任何字符。因此，這個(gè)空段可以用來映射輔助平面的字符。

具體來說，輔助平面的字符位共有220個(gè)，也就是說，對應(yīng)這些字符至少需要 20 個(gè)二進(jìn)制位。UTF-16 將這 20 位拆成兩半，前 10 位映射在U+D800 到U+DBFF（空間大小210），稱為高位（H），后 10 位映射在U+DC00 到U+DFFF（空間大小210），稱為低位（L）。這意味著，一個(gè)輔助平面的字符，被拆成兩個(gè)基本平面的字符表示。

所以，當(dāng)我們遇到兩個(gè)字節(jié)，發(fā)現(xiàn)它的碼點(diǎn)在U+D800 到U+DBFF 之間，就可以斷定，緊跟在后面的兩個(gè)字節(jié)的碼點(diǎn)，應(yīng)該在U+DC00 到U+DFFF 之間，這四個(gè)字節(jié)必須放在一起解讀。

四、UTF-16 的轉(zhuǎn)碼公式

Unicode 碼點(diǎn)轉(zhuǎn)成 UTF-16 的時(shí)候，首先區(qū)分這是基本平面字符，還是輔助平面字符。如果是前者，直接將碼點(diǎn)轉(zhuǎn)為對應(yīng)的十六進(jìn)制形式，長度為兩字節(jié)。

U+597D = 0x597D　　 

如果是輔助平面字符，Unicode 3.0 版給出了轉(zhuǎn)碼公式。

H = Math.floor ((c-0x10000) / 0x400)+0xD800 
L = (c - 0x10000) % 0x400 + 0xDC0 

[[124343]]

以字符[[124344]]為例，它是一個(gè)輔助平面字符，碼點(diǎn)為U+1D306，將其轉(zhuǎn)為 UTF-16 的計(jì)算過程如下。

H = Math.floor ((0x1D306-0x10000)/0x400)+0xD800 = 0xD834 
L = (0x1D306-0x10000) % 0x400+0xDC00 = 0xDF06 

所以，字符[[124345]]的 UTF-16 編碼就是 0xD834 DF06，長度為四個(gè)字節(jié)。

#p#

五、JavaScript 使用哪一種編碼？

[[124346]]

JavaScript 語言采用 Unicode 字符集，但是只支持一種編碼方法。

這種編碼既不是 UTF-16，也不是 UTF-8，更不是 UTF-32。上面那些編碼方法，JavaScript 都不用。

JavaScript 用的是 UCS-2！

[[124347]]

六、UCS-2 編碼

怎么突然殺出一個(gè) UCS-2？這就需要講一點(diǎn)歷史。

互聯(lián)網(wǎng)還沒出現(xiàn)的年代，曾經(jīng)有兩個(gè)團(tuán)隊(duì)，不約而同想搞統(tǒng)一字符集。一個(gè)是 1989 年成立的 Unicode 團(tuán)隊(duì)，另一個(gè)是更早的、1988 年成立的 UCS 團(tuán)隊(duì)。等到他們發(fā)現(xiàn)了對方的存在，很快就達(dá)成一致：世界上不需要兩套統(tǒng)一字符集。

1991 年 10 月，兩個(gè)團(tuán)隊(duì)決定合并字符集。也就是說，從今以后只發(fā)布一套字符集，就是 Unicode，并且修訂此前發(fā)布的字符集，UCS 的碼點(diǎn)將與 Unicode 完全一致。

當(dāng)時(shí)的實(shí)際情況是，UCS 的開發(fā)進(jìn)度快于 Unicode，早在 1990 年，就公布了***套編碼方法 UCS-2，使用 2 個(gè)字節(jié)表示已經(jīng)有碼點(diǎn)的字符。（那個(gè)時(shí)候只有一個(gè)平面，就是基本平面，所以 2 個(gè)字節(jié)就夠用了。）UTF-16 編碼遲至 1996 年 7 月才公布，明確宣布是 UCS-2 的超集，即基本平面字符沿用 UCS-2 編碼，輔助平面字符定義了 4 個(gè)字節(jié)的表示方法。

兩者的關(guān)系簡單說，就是 UTF-16 取代了 UCS-2，或者說 UCS-2 整合進(jìn)了 UTF-16。所以，現(xiàn)在只有 UTF-16，沒有 UCS-2。

七、JavaScript 的誕生背景

那么，為什么 JavaScript 不選擇更高級的 UTF-16，而用了已經(jīng)被淘汰的 UCS-2 呢？

答案很簡單：非不想也，是不能也。因?yàn)樵?JavaScript 語言出現(xiàn)的時(shí)候，還沒有 UTF-16 編碼。

1995 年 5 月，Brendan Eich 用了 10 天設(shè)計(jì)了 JavaScript 語言；10 月，***個(gè)解釋引擎問世；次年 11 月，Netscape 正式向 ECMA 提交語言標(biāo)準(zhǔn)（整個(gè)過程詳見《JavaScript 誕生記》）。對比 UTF-16 的發(fā)布時(shí)間（1996 年 7 月），就會(huì)明白 Netscape 公司那時(shí)沒有其他選擇，只有 UCS-2 一種編碼方法可用！

八、JavaScript 字符函數(shù)的局限

由于 JavaScript 只能處理 UCS-2 編碼，造成所有字符在這門語言中都是 2 個(gè)字節(jié)，如果是 4 個(gè)字節(jié)的字符，會(huì)當(dāng)作兩個(gè)雙字節(jié)的字符處理。JavaScript 的字符函數(shù)都受到這一點(diǎn)的影響，無法返回正確結(jié)果。

還是以字符[[124349]]為例，它的 UTF-16 編碼是 4 個(gè)字節(jié)的 0xD834 DF06。問題就來了，4 個(gè)字節(jié)的編碼不屬于 UCS-2，JavaScript 不認(rèn)識(shí)，只會(huì)把它看作單獨(dú)的兩個(gè)字符U+D834 和U+DF06。前面說過，這兩個(gè)碼點(diǎn)是空的，所以 JavaScript 會(huì)認(rèn)為[[124350]]是兩個(gè)空字符組成的字符串！

上面代碼表示，JavaScript 認(rèn)為字符[[124351]]的長度是2，取到的***個(gè)字符是空字符，取到的***個(gè)字符的碼點(diǎn)是 0xDB34。這些結(jié)果都不正確！

[[124352]]

解決這個(gè)問題，必須對碼點(diǎn)做一個(gè)判斷，然后手動(dòng)調(diào)整。下面是正確的遍歷字符串的寫法。

while (++index < length) { 
  // ... if (charCode >= 0xD800 && charCode <= 0xDBFF) { 
    output.push (character + string.charAt (++index)); 
  } else { 
    output.push (character); 
  } 
} 

上面代碼表示，遍歷字符串的時(shí)候，必須對碼點(diǎn)做一個(gè)判斷，只要落在 0xD800 到 0xDBFF 的區(qū)間，就要連同后面 2 個(gè)字節(jié)一起讀取。

類似的問題存在于所有的 JavaScript 字符操作函數(shù)。　

String.prototype.replace () 
String.prototype.substring () 
String.prototype.slice () 
...　　　　 

上面的函數(shù)都只對 2 字節(jié)的碼點(diǎn)有效。要正確處理 4 字節(jié)的碼點(diǎn)，就必須逐一部署自己的版本，判斷一下當(dāng)前字符的碼點(diǎn)范圍。

九、ECMAScript 6

[[124353]]

JavaScript 的下一個(gè)版本 ECMAScript 6（簡稱 ES6），大幅增強(qiáng)了 Unicode 支持，基本上解決了這個(gè)問題。

（1）正確識(shí)別字符

ES6 可以自動(dòng)識(shí)別 4 字節(jié)的碼點(diǎn)。因此，遍歷字符串就簡單多了。

for (let s of string ) { 
  // ... } 

但是，為了保持兼容，length 屬性還是原來的行為方式。為了得到字符串的正確長度，可以用下面的方式。

Array.from(string) .length　　 

（2）碼點(diǎn)表示法

JavaScript 允許直接用碼點(diǎn)表示 Unicode 字符，寫法是"斜杠 +u+ 碼點(diǎn)"。

'好' === '\u597D' // true 

但是，這種表示法對 4 字節(jié)的碼點(diǎn)無效。ES6 修正了這個(gè)問題，只要將碼點(diǎn)放在大括號內(nèi)，就能正確識(shí)別。

（3）字符串處理函數(shù)

ES6 新增了幾個(gè)專門處理 4 字節(jié)碼點(diǎn)的函數(shù)。

String.fromCodePoint ()：從 Unicode 碼點(diǎn)返回對應(yīng)字符 
String.prototype.codePointAt ()：從字符返回對應(yīng)的碼點(diǎn) 
String.prototype.at ()：返回字符串給定位置的字符　　 　

（4）正則表達(dá)式

ES6 提供了u修飾符，對正則表達(dá)式添加 4 字節(jié)碼點(diǎn)的支持。

（5）Unicode 正規(guī)化

有些字符除了字母以外，還有附加符號。比如，漢語拼音的ǒ，字母上面的聲調(diào)就是附加符號。對于許多歐洲語言來說，聲調(diào)符號是非常重要的。

Unicode 提供了兩種表示方法。一種是帶附加符號的單個(gè)字符，即一個(gè)碼點(diǎn)表示一個(gè)字符，比如ǒ的碼點(diǎn)是U+01D1；另一種是將附加符號單獨(dú)作為一個(gè)碼點(diǎn)，與主體字符復(fù)合顯示，即兩個(gè)碼點(diǎn)表示一個(gè)字符，比如ǒ可以寫成O（U+004F） + ˇ（U+030C）。

// 方法一 '\u01D1' // 'ǒ' 
 
// 方法二 '\u004F\u030C' // 'ǒ' 

這兩種表示方法，視覺和語義都完全一樣，理應(yīng)作為等同情況處理。但是，JavaScript 無法辨別。

'\u01D1'==='\u004F\u030C'  
//false　　 

ES6 提供了 normalize 方法，允許"Unicode 正規(guī)化"，即將兩種方法轉(zhuǎn)為同樣的序列。

'\u01D1'.normalize () === '\u004F\u030C'.normalize ()  
 // true 

關(guān)于 ES6 的更多介紹，請看《ECMAScript 6 入門》。

==========================

[[124357]]

我的講稿就是上面這些內(nèi)容，當(dāng)天的 PPT 請看這里。

原文鏈接：http://www.ruanyifeng.com/blog/2014/12/unicode.html