摘要：本文大部分內(nèi)容轉(zhuǎn)自阮一峰前輩的文章，更新了部分內(nèi)容并加入了部分自己的理解。字符串處理函數(shù)新增了幾個(gè)專門處理字節(jié)碼點(diǎn)的函數(shù)。參考鏈接阮一峰與詳解輔助平面入門

本文大部分內(nèi)容轉(zhuǎn)自 阮一峰前輩的文章，更新了部分內(nèi)容并加入了部分自己的理解。

Unicode源于一個(gè)很簡(jiǎn)單的想法：將全世界所有的字符包含在一個(gè)集合里，計(jì)算機(jī)只要支持這一個(gè)字符集，就能顯示所有的字符，再也不會(huì)有亂碼了。

它從0開始，為每個(gè)符號(hào)指定一個(gè)4個(gè)字節(jié)的編號(hào)，這叫做"碼點(diǎn)"（code point）。比如，碼點(diǎn)0的符號(hào)就是null（表示所有二進(jìn)制位都是0），中文"好"的碼點(diǎn)是十六進(jìn)制的597D。

U+0000 = null
U+597D = 好

上式中，U+表示緊跟在后面的十六進(jìn)制數(shù)是`Unicode的碼點(diǎn)。

目前，Unicode的最新版本是10.0版，一共收入了136690個(gè)符號(hào)，這么多符號(hào)，Unicode不是一次性定義的，而是分區(qū)定義。每個(gè)區(qū)可以存放65536個(gè)（2¹⁶）字符，稱為一個(gè)平面（plane），定義了17個(gè)平面，目前Unicode字符集的大小是1,114,112（17*2¹⁶）。

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

16個(gè)輔助平面目前只用了6個(gè)：

第一輔助平面（SMP），擺放拼音文字（主要為現(xiàn)時(shí)已不再使用的文字）及符號(hào)。范圍在 U+10000 ~ U+1FFFD。

第二輔助平面（SIP），整個(gè)范圍在 U+20000 ~ U+2FFFD?，F(xiàn)時(shí)擺放“中日韓統(tǒng)一表意文字?jǐn)U展B區(qū)”，共43,253個(gè)漢字，以及中日韓兼容表意文字增補(bǔ) (CJK Compatibility Ideographs Supplement)。

第三 ~ 十三輔助平面，暫未使用。

第十四輔助平面（SSP），擺放 Language tags 和 Variation Selectors ，它們都是控制字符。范圍在 U+E0000 ~ U+E01FF。

第十五 ~ 十六輔助平面都是私人使用區(qū)。它們的范圍是 U+F0000 ~ U+FFFFD 及 U+100000 ~ U+1000FD。

Unicode只是一個(gè)符號(hào)集，它只規(guī)定了符號(hào)的二進(jìn)制代碼（碼點(diǎn)），卻沒有規(guī)定到底用什么樣的字節(jié)序表示這個(gè)碼點(diǎn)，所以出現(xiàn)了不同的編碼方式---UTF-32,UTF-16,UTF-8

由于每個(gè)碼點(diǎn)為4個(gè)字節(jié)，所以最直觀的編碼方法是使用4個(gè)字節(jié)表示，字節(jié)內(nèi)容一一對(duì)應(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ī)則簡(jiǎn)單直觀，查找效率高。
缺點(diǎn)在于浪費(fèi)空間，同樣內(nèi)容的英語文本，它會(huì)比ASCII編碼大四倍。這個(gè)缺點(diǎn)很致命，導(dǎo)致實(shí)際上沒有人使用這種編碼方法，HTML5標(biāo)準(zhǔn)就明文規(guī)定，網(wǎng)頁(yè)不能編碼成UTF-32。

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

由于UTF-8這種節(jié)省空間的特性，導(dǎo)致它成為互聯(lián)網(wǎng)上最常見的網(wǎng)頁(yè)編碼。

UTF-16編碼介于UTF-32與UTF-8之間，同時(shí)結(jié)合了定長(zhǎng)和變長(zhǎng)兩種編碼方法的特點(diǎn)。
它的編碼規(guī)則很簡(jiǎn)單：

基本平面的字符占用2個(gè)字節(jié)；

輔助平面的字符占用4個(gè)字節(jié)。

也就是說，UTF-16的編碼長(zhǎng)度要么是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)不對(duì)應(yīng)任何字符。因此，這個(gè)空段可以用來映射輔助平面的字符。
具體如下，先來計(jì)算一下輔助平面的碼點(diǎn)共有多少個(gè):

$$17*2^{16} - 2^{16} = 2^{16} * 2^4 = 2^{20}$$

再計(jì)算一下需要多少個(gè)二進(jìn)制位，2²⁰個(gè)碼點(diǎn)，意味著最后一個(gè)碼點(diǎn)對(duì)應(yīng)于（從0開始所以要減1）：
$$2^{20} - 1 $$

轉(zhuǎn)換為16進(jìn)制便是0xFFFFF，對(duì)應(yīng)的二進(jìn)制位數(shù)為20位，也就是說，對(duì)應(yīng)這些字符至少需要20個(gè)二進(jìn)制位。

UTF-16將這20位拆成兩半，前10位映射在U+D800~U+DBFF（空間大小2¹⁰），稱為高位（H），后10位映射在U+DC00到U+DFFF（空間大小2¹⁰），稱為低位（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é)必須放在一起解讀。

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

U+597D = 0x597D

如果是輔助平面字符，Unicode 3.0版給出了轉(zhuǎn)碼公式，對(duì)于碼點(diǎn)c：

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

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

H = Math.floor((0x20BB7 - 0x10000) / 0x400) + 0xD800 = 0xD842
L = (0x20BB7 - 0x10000) % 0x400 + 0xDC00 = 0xDFB7

所以，?字符的UTF-16編碼就是0xD842DFB7，長(zhǎng)度為四個(gè)字節(jié)。

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

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

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

互聯(lián)網(wǎng)還沒出現(xiàn)的年代，曾經(jīng)有兩個(gè)團(tuán)隊(duì)，不約而同想搞統(tǒng)一字符集。一個(gè)是1988年成立的Unicode團(tuán)隊(duì)，另一個(gè)是1989年成立的UCS團(tuán)隊(duì)。等到他們發(fā)現(xiàn)了對(duì)方的存在，很快就達(dá)成一致：世界上不需要兩套統(tǒng)一字符集。
1991年10月，兩個(gè)團(tuán)隊(duì)決定合并字符集。也就是說，從今以后只發(fā)布一套字符集，就是Unicode，并且修訂此前發(fā)布的字符集，UCS的碼點(diǎn)將與Unicode完全一致。

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)系簡(jiǎn)單說，就是UTF-16取代了UCS-2，或者說UCS-2整合進(jìn)了UTF-16。所以，現(xiàn)在只有UTF-16，沒有UCS-2。

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

答案很簡(jiǎn)單：非不想也，是不能也。因?yàn)樵?b>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誕生記》）。對(duì)比UTF-16的發(fā)布時(shí)間（1996年7月），就會(huì)明白Netscape公司那時(shí)沒有其他選擇，只有UCS-2一種編碼方法可用！

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

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

`?`.length //2
`?` === "u20BB7" //false
`?`.charAt(0) // "?"
`?`.charCodeAt(0) // 55362(0xD842)

上面代碼表示，JavaScript認(rèn)為字符?的長(zhǎng)度是2，取到的第一個(gè)字符是"?"字符，取到的第一個(gè)字符的碼點(diǎn)是0xD842。這些結(jié)果都不正確！

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

var index = -1;
var string = "?12";
var length = string.length;
var output = [];
while (++index < length) {
  var charCode = string.charCodeAt(index);
  var character = string.charAt(index);
  if (charCode >= 55296 && charCode <= 56319) {
    output.push(character + string.charAt(++index));
  } else {
    output.push(character);
  }
}
console.log(output) //["?", "1", "2"]

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

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

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

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

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

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

let s = "?12";
let output = [];
for(let s of string ){ 
    output.push(s)
}
console.log(output) //["?", "1", "2"]

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

Array.from(string).length

碼點(diǎn)表示法
JavaScript一直允許直接用碼點(diǎn)表示Unicode字符，寫法是uxxxx形式，其中xxxx表示字符的Unicode 碼點(diǎn)。

"好"==="u597D" // true

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

"?" === "u20BB7" //false
"?" === "u{20BB7}" //true

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

String.fromCodePoint()：對(duì)應(yīng)于String.fromCharCode()，從Unicode碼點(diǎn)返回對(duì)應(yīng)字符

String.prototype.codePointAt()：對(duì)應(yīng)于String.prototype.charCodeAt()，從字符返回對(duì)應(yīng)的Unicode碼點(diǎn)

String.prototype.at()：對(duì)應(yīng)于String.prototype.charAt()，返回字符串給定位置的字符

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

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

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

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

"u01D1"==="u004Fu030C" //false

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

"u01D1".normalize()==="u004Fu030C".normalize() // true

阮一峰--Unicode與JavaScript詳解
輔助平面
ECMAScript 6 入門