Unicode與JavaScript詳解
作者： 阮一峰
上個月，我做了一次分享，詳細介紹了 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？這就需要講一點歷史。
互聯網還沒出現的年代，曾經有兩個團隊，不約而同想搞統一字符集。一個是 1989 年成立的 Unicode 團隊，另一個是更早的、1988 年成立的 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 請看這里。