Unicode与JavaScript详解

摘要：本文大部分内容转自阮一峰前辈的文章，更新了部分内容并加入了部分自己的理解。字符串处理函数新增了几个专门处理字节码点的函数。参考链接阮一峰与详解辅助平面入门

本文大部分内容转自 阮一峰前辈的文章，更新了部分内容并加入了部分自己的理解。

Unicode源于一个很简单的想法：将全世界所有的字符包含在一个集合里，计算机只要支持这一个字符集，就能显示所有的字符，再也不会有乱码了。

它从0开始，为每个符号指定一个4个字节的编号，这叫做"码点"（code point）。比如，码点0的符号就是null（表示所有二进制位都是0），中文"好"的码点是十六进制的597D。

U+0000 = null
U+597D = 好

上式中，U+表示紧跟在后面的十六进制数是`Unicode的码点。

目前，Unicode的最新版本是10.0版，一共收入了136690个符号，这么多符号，Unicode不是一次性定义的，而是分区定义。每个区可以存放65536个（2¹⁶）字符，称为一个平面（plane），定义了17个平面，目前Unicode字符集的大小是1,114,112（17*2¹⁶）。

最前面的65536个字符位，称为基本平面（缩写BMP），它的码点范围是从0一直到2¹⁶-1，写成16进制就是从U+0000到U+FFFF。所有最常见的字符都放在这个平面，这是Unicode最先定义和公布的一个平面。剩下的字符都放在辅助平面（缩写SMP），码点范围从U+010000一直到U+10FFFF。

16个辅助平面目前只用了6个：

第一辅助平面（SMP），摆放拼音文字（主要为现时已不再使用的文字）及符号。范围在 U+10000 ~ U+1FFFD。

第二辅助平面（SIP），整个范围在 U+20000 ~ U+2FFFD。现时摆放“中日韩统一表意文字扩展B区”，共43,253个汉字，以及中日韩兼容表意文字增补 (CJK Compatibility Ideographs Supplement)。

第三 ~ 十三辅助平面，暂未使用。

第十四辅助平面（SSP），摆放 Language tags 和 Variation Selectors ，它们都是控制字符。范围在 U+E0000 ~ U+E01FF。

第十五 ~ 十六辅助平面都是私人使用区。它们的范围是 U+F0000 ~ U+FFFFD 及 U+100000 ~ U+1000FD。

Unicode只是一个符号集，它只规定了符号的二进制代码（码点），却没有规定到底用什么样的字节序表示这个码点，所以出现了不同的编码方式---UTF-32,UTF-16,UTF-8

由于每个码点为4个字节，所以最直观的编码方法是使用4个字节表示，字节内容一一对应码点。这种编码方法就叫做UTF-32。比如，码点0就用四个字节的0表示，码点597D就在前面加两个字节的0。

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

UTF-32的优点在于，转换规则简单直观，查找效率高。
缺点在于浪费空间，同样内容的英语文本，它会比ASCII编码大四倍。这个缺点很致命，导致实际上没有人使用这种编码方法，HTML5标准就明文规定，网页不能编码成UTF-32。

人们真正需要的是一种节省空间的编码方法，这导致了UTF-8的诞生。UTF-8是一种变长的编码方法，字符长度从1个字节到4个字节不等。越是常用的字符，字节越短，最前面的128个字符，只使用1个字节表示，与ASCII码完全相同。

由于UTF-8这种节省空间的特性，导致它成为互联网上最常见的网页编码。

UTF-16编码介于UTF-32与UTF-8之间，同时结合了定长和变长两种编码方法的特点。
它的编码规则很简单：

基本平面的字符占用2个字节；

辅助平面的字符占用4个字节。

也就是说，UTF-16的编码长度要么是2个字节（U+0000~U+FFFF），要么是4个字节（U+010000~U+10FFFF）。

于是就有一个问题，当我们遇到两个字节，怎么看出它本身是一个字符，还是需要跟其他两个字节放在一起解读？
说来很巧妙，不知道是不是故意的设计，在基本平面内，从U+D800~U+DFFF是一个空段，即这些码点不对应任何字符。因此，这个空段可以用来映射辅助平面的字符。
具体如下，先来计算一下辅助平面的码点共有多少个:

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

再计算一下需要多少个二进制位，2²⁰个码点，意味着最后一个码点对应于（从0开始所以要减1）：
$$2^{20} - 1 $$

转换为16进制便是0xFFFFF，对应的二进制位数为20位，也就是说，对应这些字符至少需要20个二进制位。

UTF-16将这20位拆成两半，前10位映射在U+D800~U+DBFF（空间大小2¹⁰），称为高位（H），后10位映射在U+DC00到U+DFFF（空间大小2¹⁰），称为低位（L）。这意味着，一个辅助平面的字符，被拆成两个基本平面的字符表示。

所以，当我们遇到两个字节，发现它的码点在U+D800~U+DBFF之间，就可以断定，紧跟在后面的两个字节的码点，应该在U+DC00~U+DFFF之间，这四个字节必须放在一起解读。

Unicode码点转成UTF-16的时候，首先区分这是基本平面字符，还是辅助平面字符。如果是前者，直接将码点转为对应的十六进制形式，长度为两字节。

U+597D = 0x597D

如果是辅助平面字符，Unicode 3.0版给出了转码公式，对于码点c：

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

以字符?为例，它是一个辅助平面字符，码点为U+20BB7，将其转为UTF-16的计算过程如下。

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

所以，?字符的UTF-16编码就是0xD842DFB7，长度为四个字节。

JavaScript语言采用Unicode字符集，但是只支持一种编码方法。

这种编码既不是UTF-16，也不是UTF-8，更不是UTF-32。上面那些编码方法，JavaScript都不用。JavaScript用的是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不选择更高级的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`只能处理UCS-2编码，造成所有字符在这门语言中都是2个字节，如果是4个字节的字符，会当作两个双字节的字符处理。JavaScript的字符函数都受到这一点的影响，无法返回正确结果。

还是以?字符为例，它的UTF-16编码是4个字节的0xD842DFB7。问题就来了，4个字节的编码不属于UCS-2，JavaScript不认识，只会把它看作多带带的两个字符U+D842和U+DFB7。前面说过，这两个码点是空的，所以JavaScript会认为是两个空字符组成的字符串！

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

上面代码表示，JavaScript认为字符?的长度是2，取到的第一个字符是"�"字符，取到的第一个字符的码点是0xD842。这些结果都不正确！

解决这个问题，必须对码点做一个判断，然后手动调整。下面是正确的遍历字符串的写法。

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"]

上面代码表示，遍历字符串的时候，必须对码点做一个判断，只要落在55296~56319(0xD800~0xDBFF)的区间，就要连同后面2个字节一起读取。

类似的问题存在于所有的JavaScript字符操作函数。

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

上面的函数都只对2字节的码点有效。要正确处理4字节的码点，就必须逐一部署自己的版本，判断一下当前字符的码点范围。

JavaScript的ECMAScript 6版本（简称ES6），大幅增强了Unicode支持，基本上解决了这个问题。

正确识别字符
ES6可以自动识别4字节的码点。因此，遍历字符串就简单多了。

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

但是，为了保持兼容，length属性还是原来的行为方式。为了得到字符串的正确长度，可以用下面的方式。

Array.from(string).length

码点表示法
JavaScript一直允许直接用码点表示Unicode字符，写法是uxxxx形式，其中xxxx表示字符的Unicode 码点。

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

但是，这种表示法对4字节的码点无效。ES6修正了这个问题，只要将码点放在大括号内，就能正确识别。

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

字符串处理函数
ES6新增了几个专门处理4字节码点的函数。

String.fromCodePoint()：对应于String.fromCharCode()，从Unicode码点返回对应字符

String.prototype.codePointAt()：对应于String.prototype.charCodeAt()，从字符返回对应的Unicode码点

String.prototype.at()：对应于String.prototype.charAt()，返回字符串给定位置的字符

正则表达式
ES6提供了u修饰符，含义为Unicode模式，对正则表达式添加4字节码点的支持。

Unicode正规化
有些字符除了字母以外，还有附加符号。比如，汉语拼音的Ǒ，字母上面的声调就是附加符号。对于许多欧洲语言来说，声调符号是非常重要的。

Unicode提供了两种表示方法，一种是带附加符号的单个字符，即一个码点表示一个字符，比如Ǒ的码点是U+01D1；另一种是将附加符号多带带作为一个码点，与主体字符复合显示，即两个码点表示一个字符，比如Ǒ可以写成O(U+004F)+ˇ(U+030C)。

这两种表示方法，视觉和语义都完全一样，理应作为等同情况处理。但是，JavaScript无法辨别。

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

ES6提供了normalize方法，允许"Unicode正规化"，即将两种方法转为同样的序列。

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

阮一峰--Unicode与JavaScript详解
辅助平面
ECMAScript 6 入门