本文大部分内容转自 阮一峰前辈的文章,更新了部分内容并加入了部分自己的理解。
Unicode是什么?
Unicode
源于一个很简单的想法:将全世界所有的字符包含在一个集合里,计算机只要支持这一个字符集,就能显示所有的字符,再也不会有乱码了。
它从0开始,为每个符号指定一个4
个字节的编号,这叫做"码点"(code point
)。比如,码点0的符号就是null
(表示所有二进制位都是0),中文"好"的码点是十六进制的597D
。
U+0000 = null
U+597D = 好
上式中,U+
表示紧跟在后面的十六进制数是`Unicode的码点。
目前,Unicode
的最新版本是10.0
版,一共收入了136690
个符号,这么多符号,Unicode
不是一次性定义的,而是分区定义。每个区可以存放65536
个(216)字符,称为一个平面(plane
),定义了17
个平面,目前Unicode
字符集的大小是1,114,112
(17*216)。
最前面的65536
个字符位,称为基本平面(缩写BMP
),它的码点范围是从0
一直到216-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
UTF-32与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
码完全相同。
码点范围 | 字节数 | 可容纳字符个数 |
---|---|---|
0x0000 ~ 0x007F
|
1 | 128 |
0x0080 ~ 0x07FF
|
2 | 1920 |
0x0800 ~ 0xFFFF
|
3 | 63488 |
0x010000 ~ 0x10FFFF
|
4 | 1048575 |
由于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
是一个空段,即这些码点不对应任何字符。因此,这个空段可以用来映射辅助平面的字符。
具体如下,先来计算一下辅助平面的码点共有多少个:
$$17*2^{16} - 2^{16} = 2^{16} * 2^4 = 2^{20}$$
再计算一下需要多少个二进制位,220个码点,意味着最后一个码点对应于(从0开始所以要减1):
$$2^{20} - 1 $$
转换为16进制便是0xFFFFF
,对应的二进制位数为20
位,也就是说,对应这些字符至少需要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
版给出了转码公式,对于码点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使用哪一种编码?
JavaScript
语言采用Unicode
字符集,但是只支持一种编码方法。
这种编码既不是UTF-16
,也不是UTF-8
,更不是UTF-32
。上面那些编码方法,JavaScript
都不用。JavaScript
用的是UCS-2
!
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的诞生背景
那么,为什么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
个字节的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
字节的码点,就必须逐一部署自己的版本,判断一下当前字符的码点范围。
ECMAScript 6
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'==='\u004F\u030C' //false
ES6
提供了normalize
方法,允许"Unicode
正规化",即将两种方法转为同样的序列。'\u01D1'.normalize()==='\u004F\u030C'.normalize() // true
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。