如何理解Unicode与JavaScript

如何理解Unicode和JavaScript，相信很多没有经验的人都不知所措。因此，本文总结了出现问题的原因和解决方法，希望大家可以通过本文来解决这个问题。

上个月做了一个分享，详细介绍了Unicode字符集，以及JavaScript语言对它的支持。以下是这次要分享的讲座。

一、Unicode 是什么？

Unicode源于一个简单的想法：世界上所有的字符都包含在一个集合中。只要电脑支持这个字符集，所有字符都可以显示，不会再有乱码了。

从0开始，它给每个符号分配一个数字，称为“码点”。例如，代码点0的符号为空(表示所有二进制位都为0)。

U 0000=null在上面的公式中，u表示紧跟其后的十六进制数是Unicode的代码点。

目前，Unicode * * *版为7.0版，总收入109，449个符号，其中中日韩字符7.45万个。粗略地说，世界上现存的符号有三分之二以上来自东亚文字。比如中文“好”的码位是十六进制的597D。

U 597D=这么多符号，Unicode不是一次定义，而是分区定义。每个区域可以存储65，536 (216)个字符，称为平面。目前有17 (25)个平面，也就是说现在整个Unicode字符集的大小是221。

前65，536个字符位被称为基本平面(缩写为BMP)，其码位范围从0到216-1，并以十六进制编写，即从U 0000到U FFFF。所有最常见的字符都放在这个平面中，这个平面是定义和发布Unicode ***的平面。

剩下的字符放在辅助平面(简称SMP)，码点从U 010000到U 10FFFF。

二、UTF-32 与 UTF-8

Unicode只指定每个字符的代码点。用什么样的字节顺序来表示这个码点，这就涉及到编码方式。

最直观的编码方式是每个码点用四个字节表示，字节内容与码点一一对应。这种编码方法称为UTF-32。例如，码点0由四个字节的零表示，码点597D之前是两个字节的零。

u 0000=0x 0000000 u 597d=0x 0000597d

UTF-32具有转换规则简单直观、搜索效率高的优点。缺点是浪费空间。内容相同的英文文本将比ASCII编码大四倍。这个缺点是致命的，这导致实际上没有人使用这种编码方法。HTML 5标准明确规定网页不应编码为UTF-32。

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

数字字节0x 0000-0x 007 f 10080-0x 07 ff 200800-0x ffff 30 x 010000-0x 10 ffff 4

三

、UTF-16 简介

由于 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 是一个空段，即这些码点不对应任何字符。因此，这个空段可以用来映射辅助平面的字符。

具体来说，辅助平面的字符位共有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 + 0xDC0

以字符为例，它是一个辅助平面字符，码点为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

看完上述内容，你们掌握如何理解Unicode与JavaScript的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！