Unicode与JavaScript详解

作者: 阮一峰

日期: 2014年12月11日

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

一、Unicode是什么?

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

它从0开始,为每个符号指定一个编号,这叫做"码点"(code point)。比如,码点0的符号就是null(表示所有二进制位都是0)。


U+0000 = null

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

目前,Unicode的最新版本是7.0版,一共收入了109449个符号,其中的中日韩文字为74500个。可以近似认为,全世界现有的符号当中,三分之二以上来自东亚文字。比如,中文"好"的码点是十六进制的597D。


U+597D = 好

这么多符号,Unicode不是一次性定义的,而是分区定义。每个区可以存放65536个(216)字符,称为一个平面(plane)。目前,一共有17个(25)平面,也就是说,整个Unicode字符集的大小现在是221

最前面的65536个字符位,称为基本平面(缩写BMP),它的码点范围是从0一直到216-1,写成16进制就是从U+0000到U+FFFF。所有最常见的字符都放在这个平面,这是Unicode最先定义和公布的一个平面。

剩下的字符都放在辅助平面(缩写SMP),码点范围从U+010000一直到U+10FFFF。

二、UTF-32与UTF-8

Unicode只规定了每个字符的码点,到底用什么样的字节序表示这个码点,就涉及到编码方法。

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


U+0000 = 0x0000 0000

U+597D = 0x0000 597D

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

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

编号范围字节
0x0000 - 0x007F1
0x0080 - 0x07FF2
0x0800 - 0xFFFF3
0x010000 - 0x10FFFF4

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

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

以字符为例,它是一个辅助平面字符,码点为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?这就需要讲一点历史。

互联网还没出现的年代,曾经有两个团队,不约而同想搞统一字符集。一个是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个字节的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

关于ES6的更多介绍,请看《ECMAScript 6入门》

==========================

我的讲稿就是上面这些内容,当天的PPT请看这里

(完)

留言(53条)

哈哈,博主也是Futurama爱好者吗

最后的「以字符」是什么意思,是不是没写完?

头图是B52么

@paster:

文章贴出来才发现,这个blog程序会自动截断辅助平面的字符。

手忙脚乱得收拾了半天,把该文字都换成了图片……

应试是
U+0000 = 0x00 00 00 00

U+597D = 0x00 00 59 7D
吧?

@秣马儿:谢谢指出,确实写错了,已经改过来了。

挺好的,感谢科普

1988年成立的UCS团队 这个时间和图片里的时间不一致啊。

看了博主很多文章都不错,能分享下博主的学习规划吗,是怎么安排的

赞!简单易懂,学习了!

JavaScript允许直接用码点表示Unicode字符,写法是"斜杠+u+码点"。
应该是反斜杠吧阮兄。

@李之若:谢谢指出已经改过来了。

> 一个是1988年成立的UCS团队,另一个是1989年成立的Unicode团队。
这句与你Slides里的时间,刚好相反。

@Owen:

谢谢指出,已经改正了。

大哥,我转载了你的文章,都标注了作者。之前转的一些,在文章后留下了来源信息。请问这样有问题吗?转载似乎是有规则的,我才做博客两个月,不懂,那天看到一篇批评转载的文章,诚惶诚恐,求指教。

“目前,一共有17个(2^5)平面”,17是怎么来的?是不是应为32?

阮老师的PPT我看了,简洁明了,很高大上。因为日常中经常演讲展示,我想学习一下PPT的做法,阮老师可以提供这个PPT下载吗?我邮箱地址[email protected]。PS.我的这种行为不妥,阮老师也可以拒绝,我仍然感谢。

很赞啊,正需要这个知识

终于知道以前那个恶魔般的js乱码和执行异常的问题是怎么回事了!
感谢。

博主你好,我现在是一名高中生,突然发现自己对计算机比较感兴趣。刚刚开始自学计算机语言,是学的Java语言。请问可以先学Java语言吗?我应该注意些什么呢?刚才无意中搜到了您的个人blog,读了几篇文章,对我很有启发,谢谢!

引用bbx的发言:

博主你好,我现在是一名高中生,突然发现自己对计算机比较感兴趣。刚刚开始自学计算机语言,是学的Java语言。请问可以先学Java语言吗?我应该注意些什么呢?刚才无意中搜到了您的个人blog,读了几篇文章,对我很有启发,谢谢!

1. 没什么不可以的,编程就像写作文或是解数学题,如果你作文就没好过,解数学题的思路也一般般,及时放弃,干干别的吧

2. 你说你对计算机感兴趣,说说为什么,喜欢一件事情总是可以说出很多原因的,别脑子短路想不到。

3. 注意的地方

a. 不要为了编程而编程,语言只是一个工具,用来解决实际遇到的问题的,

b. 数学很重要,趁年轻多学点

c. 趁年轻多读读小说,

d. 外语也挺重要,趁年轻多学点

e. 朋友也挺重要,别没事一个人窝着

f. 锻炼身体这件事最重要,别荒废了

g. 看了就会的东西,不能成为竞争力,学了依旧不会,这才是竞争力,社会挺浮躁,学会能够让自己安静下来。

引用阮一峰的发言:

@秣马儿:谢谢指出,确实写错了,已经改过来了。

阮老师,您的博客简洁清晰突出内容,想问一下您的blog程序是什么?

基本平面只需要16位,辅助平面就是加了8,共24位,剩下还有8位,应该是utf-24比较自然吧

引用feng smith的发言:

“目前,一共有17个(2^5)平面”,17是怎么来的?是不是应为32?

目前只定义了17个,其他都没用使用

深入理解了,感谢好文章。

非常好的文章,很有帮助

character + string.charAt(++index)
为什么加起来就可以转换?

几个建议:

code point不妨译为码位.

0xD8XX那一段实在写的不清楚,建议改成二进制表示:UTF16首字前6位为110110,次字前6位为110111

UTF16的转码公式实在奇怪,为什么要用除0x400来表示右移10位呢?
firstword = (unicode >>> 10) + 0xD800;
secondword = (unicode & 0x3ff) + 0xDC00;

引用xinwendashibaike的发言:

基本平面只需要16位,辅助平面就是加了8,共24位,剩下还有8位,应该是utf-24比较自然吧


是啊.这里我也想不通。三个字节就可以容纳Unicode的所有码点了,这样一来感觉UTF-24比UTF-32要更加科学。阮老师能否解释下。

最近正在看rapidJSON,对里面的编码搞得一塌糊涂,幸亏看到了阮哥这篇文章,受教了!

引用leezq的发言:


是啊.这里我也想不通。三个字节就可以容纳Unicode的所有码点了,这样一来感觉UTF-24比UTF-32要更加科学。阮老师能否解释下。

如果单单是比较Unicode码点的大小,使用UTF-24的确可以表示全部的Unicode码点,但是必须得让js知道这是UTF-24的编码,就涉及到具体编码了,比如就可以像UTF-8一样添加标识位,但是去除了标志位之后,剩下的编码位又不足以表示所有的码点。如果你能找到UTF-24的具体编码方式,那你就是大牛了,嘿嘿

Array.from(string).length 在 node --harmony下提示找不到定义。

> 这么多符号,Unicode不是一次性定义的,而是分区定义。每个区可以存放65536个(2^16)字符,称为一个平面(plane)。
> 目前,一共有17个(25)平面,也就是说,整个Unicode字符集的大小现在是2^21。

*这里有点错误,如果是17个平面的话,整个Unicode字符集的大小是(2^20+2^16)。*


引用一页笔记的发言:

大哥,我转载了你的文章,都标注了作者。之前转的一些,在文章后留下了来源信息。请问这样有问题吗?转载似乎是有规则的,我才做博客两个月,不懂,那天看到一篇批评转载的文章,诚惶诚恐,求指教。

版权声明:自由转载 - 非商用 - 非衍生 - 保持署名(创意共享 3.0 许可证)

http://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

js还算运气好核心字符集有ucs2可选,比js早那么两年出生的python可就惨了,不得不在phton3.0版本改变核心字符集设计使得对以前py1,py2有很大不兼容,导致py3的推广大大受阻

阮老师你好,关注你很久了,请问图片是咋个做的?好棒啊 !另外,有一张图里的平面的英文单词Plane写错成了plain。 希望告知下做图片的软件。

那Js后面不改用UTF-8的原因是因为兼容性?
还是UTF-16比UTF-8更适合内部字符串实现(如性能更好?)?

您的文章排版都特别好看!

实现utf32只需要3个字节也就是2^24位就可以了,多的那一个字节就一直空着?

阮老大的文章真好,坚持读,一定收获多多

软老大, 有个疑问呀。你看到的时候,麻烦老大,抽空给回复下。谢谢先。


就是 js采用ucs2 编码 字符串, 我的页面是 UTF8编码, 后台服务器也是UTF8编码。

那 为什么 不会乱码呢?

真不懂啊。老大给科普下吧。谢谢啦。

js算不错了至少有ucs2可用。比js早几年诞生的python就悲催了,核心是ascii的结果导致py2和py3的分裂

看完了还有很没看明白,脑子有点乱了,不过确实写得很详细,很给力。

1️⃣2️⃣3️⃣4️⃣5️⃣6️⃣7️⃣8️⃣9️⃣0️⃣
这种怎么解? 这其实是一个表情字符串,用js怎么判断它是一个表情字符呢?

阮老师,ǒ好像是'\u01D2'

如果是辅助平面字符,Unicode 3.0版给出了转码公式。

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

L = (c - 0x10000) % 0x400 + 0xDC00

这个公式应该怎么理解,为什么这样计算就可以转换成功

感谢阮老师帮我梳理了编码的知识.

我根据阮老师的文章也写了一篇博客, 希望可以帮助到有需要的朋友.

地址在: icymind.com/sizeof/

博文涵盖了:
1. UTF-32 明明24bit 就绰绰有余的情况下为什么还是用了4个字节
2. UTF-16 的编码公式为什么是这样?
3. 通过自己设计一个unicode 编码格式来了解 UTF-8

找了一天资料,直到发现这篇,终于懂了……

阮老师,我有一个疑问。希望您能看到

关于原文八、JavaScript字符函数的局限这章

`????` 字符的 Unicode 编码是 `\u{1d306}`,`"????".charCodeAt(0)`的返回值是 `U+D834`。既然 JS 是不支持 UTF-16 的,那么怎么会返回字符的 UTF-16 编码的前两个字节呢?这个字符的 UTF-16 编码 JS 是怎么获得的呢?要返回前两个字节首先要获得完整的 UTF-16 编码吧。如果 JS 只支持 UCS-2,个人认为这个逻辑是说不通的。

mdn关于`charCodeAt()`是这么说的。
> charCodeAt()** 方法返回0到65535之间的整数,表示给定索引处的UTF-16代码单元 (在 Unicode 编码单元表示一个单一的 UTF-16 编码单元的情况下,UTF-16 编码单元匹配 Unicode 编码单元。但在——例如 Unicode 编码单元 > 0x10000 的这种——不能被一个 UTF-16 编码单元单独表示的情况下,只能匹配 Unicode 代理对的第一个编码单元) 。如果你想要整个代码点的值,使用 **codePointAt**()。

引用abc的发言:

软老大, 有个疑问呀。你看到的时候,麻烦老大,抽空给回复下。谢谢先。


就是 js采用ucs2编码 字符串, 我的页面是 UTF8编码, 后台服务器也是UTF8编码。

那 为什么 不会乱码呢?

真不懂啊。老大给科普下吧。谢谢啦。

utf-16是usc-2的超级,utf-8也可以表示utf-16的所有字符,那usc-2的字符,不都可以用uft-8编码方式表示了?我的理解。

能否补上完整代码呢?尤其是这个特殊符号。方便一目了然的验证

UTF-16简介那一节,我读了一千遍才明白你的意思,因为我忘记区分“基本平面”和“辅助平面”了,我心说为啥说B800-BFFF是空段啊?那不明明是L段和H段吗?看半天才反应过来。

其实我觉得不如说:读取一个USHORT,如果值在0000-B7FF之间,那么这个USHORT本身就是一个双字节字符(基本平面内的字符);如果值大于等于B800,则它是一个四字节字符的前一半,需要再读取一个USHORT与它凑成一个完整字符(辅助平面字符)。

当然这样的解释不如原文更有数学课本的味道。

引用anthony的发言:

几个建议:

code point不妨译为码位.

0xD8XX那一段实在写的不清楚,建议改成二进制表示:UTF16首字前6位为110110,次字前6位为110111

UTF16的转码公式实在奇怪,为什么要用除0x400来表示右移10位呢?
firstword = (unicode >>> 10) + 0xD800;
secondword = (unicode & 0x3ff) + 0xDC00;

你那个位运算,也是我的第一反应,但是貌似不可以!效果不一样。不信你用文章里的那个“超级大队长四道杠”符号1D306试一试。按照你说的算法,出来的是D874和DF06!而且正确的是DB34,给人感觉是1D306里的1给扔了。我也不知道为什么。

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接