JavaScript的內部字符編碼是UCS-2還是UTF-16
對于 JavaScript 使用的是 UCS-2 還是 UTF-16 這個問題，我找了很久，沒有發現一個權威的回答，我決定自己研究一下它。這個回答來自于你對 JavaScript 引擎或者對 JavaScript 語言的理解。
一、著名的 BMP(Basic Multilingual Plane)
Unicode 標識符通過一個明確的名字和一個整數來作為它的碼位(code point).比如，“©” 字符的碼位可以用“版權標志”和U+00A9(0xA9，也可以寫作十進制 169)來表示。
Unicode 字符分為 17 組平面，每個平面擁有 2^16 (65,536)個碼位.有一些碼位沒有分配字符，也有一些碼位被保留，成為私有的，也有一些碼位是永遠被保留的，作為無字符的標志。每一個碼位都可以用 16 進制 xy0000 到 xyFFFF 來表示，這里的 xy 是表示一個 16 進制的值，從 00 到 10。
這第一個位置(當 xy 是 00 的時候)被稱為 BMP (基本多文種平面, Basic Multilingual Plane)。它包含了最常用的碼位從 U+0000 到 U+FFFF。
這里需要補充一點額外的平面知識，以及術語的表格。
引用自：wikipedia
其余 16號平面(U+100000 到 U+10FFFF)稱為補充的平面。這里我將不討論它;只需要記住兩個概念：BMP 字符和非 BMP 字符，后者也被稱為補充字符。
二、UCS-2 和 UTF-16 之間的不同
UCS-2 和 UTF-16 都是 Unicode 的字符編碼方式。
UCS-2(2個字節的通用字符集)是一種固定長度的編碼格式，只需要使用編碼為 16 字節編碼單元來表示碼位。這樣的表示結果將和 UTF-16 在 0 到 0xFFFF (BMP)范圍內大多數的結果一樣。
UTF-16(16 位 Unicode 轉換格式)是對 UCS-2 的一個擴展，它允許表示比 BMP 范圍內更多的字符。它是一種可變長度格式，它的每個碼位能夠使用 1 位或者 2 位 16字節編碼單元來表示。這種方式能夠編碼的碼位在 0 到 0x10FFFF 之間。
比如，在 UCS-2 和 UTF-16 中，對于 BMP 字符 U+00A9 版權標志(©)都能被編碼為：0x00A9。
這里補充一下 UCS-2、UCS-4、BMP
CPU 處理多字節數的方式分為：“大尾”(big endian)和“小尾”(little endian)，簡單的理解就是一個 Unicode 編碼，比如6C49，寫到文件里面 6C 49 或者 49 6C，兩種方式，前者就叫“大尾”，后者就叫“小尾”。
UCS 可以分為兩種格式：UCS-2 和 UCS-4。UCS-2 使用兩個字節編碼，UCS-4 使用4個字節(實際只有 31 位，最高位必須是 0)編碼。
轉換關系：UCS-4 中高兩個字節為 0 的碼位稱為 BMP;UCS-4 的 BMP 去掉前面兩個零字節就得到 UCS-2;UCS-2 加上兩個零字節就得到 UCS-4 中的 BMP。
三、代理對(Surrogate pairs)
對于 BMP 之外的字符，比如 U+1D306 四條線居中(其實不好翻譯：tetragram for centre，?)，只能使用 UTF-16 中兩個 16 字節來編碼：0xD834 0XDF06。這種就被稱為代理對。值得注意的是一個代理對只代表一個單字符。
補充一下代理對的概念
實際上就是指上面的一個 UTF-16 編碼，使用 2 個 16 字節來編碼。那是因為一個 UTF-16 編碼不夠，然后就應該使用 2 個 UTF-16 編碼來表示更多的字符。然后這樣就會出現：之前 2 個字節的空間表示一個字符，就會變成 4 個字節的空間。所以就規定只有一定范圍內使用 2 個 UTF-16 編碼來表示一個字符，這樣的方式就叫代理對，其余的依然使用 2 個字節來表示。
代理對中的第一個字符單元總是在 0xD800 到 0xDBFF 之間，稱為高位代理或者頂部代理(high surrogate or lead surrogate，暫時這樣，查到專業術語再翻譯)。第二個字符單元總是處于 0xDC00 到 0xDFFF 之間，稱為低位代理或者尾部代理(low surrogate or trail surrogate)。
UCS-2 是缺乏對代理對的支持的，所以要表示之前的字符需要使用 2 個分隔的字符。
四、碼位(code points)和代理對(surrogate pairs)之間的轉換
Section 3.7 of The Unicode Standard 3.0(pdf) 中定義了一個轉換算法。
假設：一個碼位 C 大于 0xFFFF 的編碼使用代理對 <H, L> 來表示的公式為：
- H = Math.floor((C - 0x10000) / 0x400) + 0xD800
- L = (C - 0x10000) % 0x400 + 0xDC00
轉換公式變換后，比如從代理對 <H, L> 轉換成一個 Unicode 碼位 C，可以使用公式：
- C = (H - 0xD800) * 0x400 + L - 0xDC00 + 0x10000
五、Ok，那么關于 JavaScript 的編碼問題呢?
在 ECMAScript 中定義來怎樣解釋字符的問題.
在 level 3 或者更高等級的實現中，遵循國際標準，與 Unicode 3.0 標準或者更新的標準，以及 ISO/IEC 10646-1，和 UCS-2 或者 UTF-16 作為編碼格式。如果采用的 ISO/IEC 10646-1 自己未被指定，它被認定為 BMP 的自己，集合 300(這里沒懂)。如果沒有采用其它的編碼格式，那么將按照 UTF-16 進行編碼。
換句話說，JavaScript 引擎是允許使用 UCS-2 或者 UTF-16 進行編碼的。
然后按照 specific parts 規定，認為引擎里面的編碼需要一些 UTF-16 的知識。
當然，內部引擎對于大多數 JavaScript 開發者來說沒有實際影響。對于更多有趣的發現JavaScript 是如何考慮字符的 中，有一段：
盡管在本文檔的其它部分中，表示字符單元和文字字符將使用 16 位的無符號值，用來表示單個 16 位文本單元。Unicode 字符將使用抽象的語言或印刷單元(可超過16位，因此可以由多個代碼單元)來表示。碼位可以用 Unicode 標準值來表示。一個組合字符序列的成分可以有個別“Unicode 字符”，即使一個用戶可能會認為整個序列是單個字符。
可能需要重新翻譯，原文
Throughout the rest of this document, the phrase code unit and the word character will be used to refer to a 16-bit unsigned value used to represent a single 16-bit unit of text.
The phrase Unicode character will be used to refer to the abstract linguistic or typographical unit represented by a single Unicode scalar value (which may be longer than 16 bits and thus may be represented by more than one code unit).
The phrase code point refers to such a Unicode scalar value.
Unicode character only refers to entities represented by single Unicode scalar values: the components of a combining character sequence are still individual “Unicode characters”, even though a user might think of the whole sequence as a single character.
JavaScript 使用單獨字符來處理字符單元，然后人們通常認為是一組 Unicode 字符。當使用 BMP 范圍外 Unicode 字符的時候，這樣會有一些不好的結果。比如代理對使用 2 個字符單元組成：'?'.length == 2，即使這里是只有一個 Unicode 字符。如果是字符，代理對將暴露一部分：'?' == '\uD834\uDF06'。
在這里你想到了什么呢?對于這種方式，至少是 UCS-2 的替代方式(不同的地方是，UCS-2 不允許有代理字符，然后 JavaScript 字符串是這樣做的)。
你可以認為它像 UTF-16 一樣在工作，特別是分成兩部分的方式是被允許的，代理的這種錯誤排序是被允許的，代理被暴露成了分離的字符。我認為你將更容易的理解成這種行為叫“UCS-2 的代理方式”(UCS-2 with surrogates，不好翻譯，也可以理解成伴隨著代理的 UCS-2)。
類似 UCS-2 的行為對整個語言更有影響，比如 補充字符范圍的正則表達式 比那些支持 UTF-16 的語言要更難寫。
代理對只是為了顯示在瀏覽器中(layout 的時候)，對單個 Unicode 字符的重新組合。這發生在 JavaScript 引擎的影響范圍之外。為了證明這個，你能在 document.write() 的時候分開寫一個高位代理和地位代理字符.
- document.write('\uD834');
- document.write('\uDF06');
在結束后也將被渲染成一個圖案：?。
六、結論
JavaScript 引擎內部是自由的使用 UCS-2 或者 UTF-16。我所知道的大多數引擎使用的是 UTF-16，無論它們使用什么方式實現，它只是一個具體的實現，這不將影響到語言的特性。
然后對于 ECMAScript/JavaScript 語言本身，實現的效果是通過 UCS-2，而非 UTF-16。
如果你在任何時候需要 編碼一個 Unicode 字符, 在必要的時候能夠替換成分離的代理，也可以免費試用我的 JavaScript escaper 工具。
如果你想在一個 JavaScript 字符串中獲取 Unicode 字符的長度，或者創建一個基于 non-BMP Unicode 碼位的字符串，你能使用Punycode.js 的工具方法，將 UCS-2 字符串轉換成 UTF-16 碼位。
- // `String.length` 只是統計所以 Unicode 字符
- punycode.ucs2.decode('?').length; // 1
- // `String.fromCharCode` 能夠讓你直接使用非分離的代理
- punycode.ucs2.encode([0x1D306]); // '?'
- punycode.ucs2.encode([119558]); // '?'
ECMAScript 6 在字符串中將支持一些新的編碼序列(現在看來已經 ok 了，可以查看一下資料簡單了解下)，名為 Unicode code point escapes 比如：\u{1D306}。另外，它將定義 String.fromCodePoint 和 String#codePointAt，這兩個方法都接受碼位(code points) 而不是字符單元(code units)
感謝：Jonas ‘nlogax’ Westerlund, Andrew ‘bobince’ Clover 以及 Tab Atkins Jr.。他們給了我調查的靈感和幫助我。
提示：如果你喜歡閱讀關于 JavaScript 的內部字符編碼，可以 check out JavaScript has a Unicode problem，這里更詳細解釋了實際的問題，以及提供了解決方法。
