JS基础-字符-Unicode编码（中）

Unicode和ISO/IEC 10646 的想法就是单纯的把世界范围内的所有有使用价值的字符放到一张表上，从0开始（可以是10进制、16进制），一直往后排...

ISO/IEC 10646是最开始工作的，他整理了一张表，收录了世界上大部分国家常用的字符，表的范围是0 - 65535 ，也就是能容纳 2^16^ 个字符。但是这个表必须要有一个与之对应的编码解码标准，因为这些编号最终还是要在计算机上使用的，所以随后就出台了UCS-2的编码标准。 UCS-2使用固定2字节，这样计算机就可以直接每2字节分段，不用像GB2312一样需要判断开头是不是1，很方便。 虽然UCS-2也把ASCII编码原封不动的放在里面，并且对应的编号也一样，比如A，他在ASCII上的10进制编号是65，在ISO/IEC 10646上依然是65，但是由于UCS-2的编码规则，他要把A编码成2字节，并且计算机解析UCS-2的规则也是固定的，直接2字节分段。所以不兼容ASCII。

比如有ASCII编码的二进制为 01000001 01100001， 使用ASCII解码解析成Aa 如果使用UCS-2来解码，就只能解析成一个字符了， 01000001 01100001 = 16737(10进制编号) = UCS-2的䅡

UCS-2颁布不久，另一头Unicode也发不了1.0版本，与ISO/IEC 10646设计思路基本一致，但是没有发布对应的编码解码标准。两边都嗅到了对方，于是开始商量合并编码的问题。原因很简单，大家都不想再创造一个多标准编码规范的世界！

此后的编码我将以Unicode为准说明，因为ISO/IEC 10646和Unicode合并后编码规则是一样的，双方共进退。这也挺好的，因为编码这种东西，一旦定义，就很难更改，因为要是改动大了，使用原来编码的用户就该哭爹喊娘了，所以2个组织总比一个组织想的周全吧。

但是在合并后不久，新问题又出现了，由于收录的字符越来越多，2^16^ 个字符范围已经不够用了，那只能开辟新的编码表了，为了便于管理，把量词“表”变成“平面”，增加至17个平面，也就是17个表，每一个平面都容纳2^16^ 个字符。

白色表示未使用的码位，蓝色代表已经使用的码位，绿色表示私有区域，红色代表代理区域（utf-16使用）

第一平面部分，也就是最开始0 - 65535的部分称之为基本平面（BMP） 其他的16个平面，都称之为辅助平面（都有自己独立的英文缩写），辅助吗，顾名思义就是相对于基本平面不太重要，因为不常用。这也说得通，因为最开始收录的字符都是各个国家的“刚需字符”，也就是最常用的字符，使用频率最高。

1-3平面使用率，颜色越深，说明使用的频率越高

虽然对应的字符编号都造出来了，但是还有一个问题就是，如何编码这多出来的编号呢？UCS-2的最大表示也就到65536个，所以UCS-2肯定是不行了，这时候出现两个分支， 一个是全部使用4字节编码，UCS-4编码，之后的UTF-32与UCS-4编码规则完全一致 UCS-4/UTF-32

原本ISO 10646标准定义了一个32位的编码形式，称作UCS-4，通用字符集（UCS）的每一个字符由0到十六进制的7FFFFFFF的31位数 值表示（符号位未使用且零）。UCS-4足以用来表示所有的Unicode的字码空间，其最大的码位为十六进制的7FFFFFFF，所以其空间约20亿个码位。 2003年11月，由于UTF-16编码形式的限制，RFC 3629标准将Unicode限制为仅支持U+10FFFF以内的码位（另外U+D800到U+DFFF范围内也被保留使用） 。虽然在之前的ISO标准（1998年的Unicode 2.1）中0xE00000到0xFFFFFF和0x60000000到0x7FFFFFFF这些区域被分配给“保留私人使用”，但这些区 域也在后续版本中被删除。在 ISO/IEC JTC 1/SC 2 WG2申明中规定UCS-4将来所有的字符分配将被限制在Unicode范围内，所以UTF-32和UCS4能表示的字符是相同的。

另一个是使用2字节或4字节的动态编码，也就是UTF-16 UTF-16

以JavaScript为例说明 如： Unicode编码为 1f60d 高位 = Math.floor((0x1f60d-0x10000) / 0x400)+0xD800 = 55357 = 0xD83D 低位 = (0x1f60d - 0x10000) % 0x400 + 0xDC00 = 56845 = 0xDE0D UTF-16编码后的 （16进制）= D83D DE0D UTF-16编码后的 （2进制）= 11011000 00111101 11011110 00001101

这个计算公式是由下通用公式变形而来，可以当成算法题练习一下

V = 0x1f60d
Vx = V - 0x10000
= 0xf60d
= 0000 1111 0110 0000 1101

// Vx的高位部份的10 bits
Vh = 00 0011 1101 
 // Vx的低位部份的10 bits
Vl = 10 0000 1101
//结果的前16位元初始值
w1 = 0xD800 = 1101 1000 0000 0000
//结果的后16位元初始值
w2 = 0xDC00 = 1101 1100 0000 0000

w1 = w1 | Vh
= 1101 1000 0000 0000 | 00 0011 1101
= 1101 1000 0011 1101 
= 0xD83D

w2 = w2 | Vl
= 1101 1100 0000 0000 | 10 0000 1101
= 1101 1110 0000 1101
= 0xDE0D

'\ud83d\ude0d' = "😍"

这个公式非常的巧妙，我们统计一下，17个平面，每个平面表示 2^16^个数，17个平面总计就是2^16^ * 17 = 1114112。 代理区D800-DBFF可以表示 2^10^ 种状态。 代理区DC00-DFFF可以表示 2^10^ 种状态。 那么两个代理区能代表的组合数为 2^10^ * 2^10^ = 2^20^ =1048576种状态 = 2^16^ * 16（16个辅助平面，每个平面也是2^16^个字符） 所以代理区正好表示了16个辅助平面。 再加上2字节的 基础平面 2^16^ 2^16^ * 16（辅助平面）+ 2^16^（基础平面） =2^16^ * 17 = 1114112。 2字节4字节动态编码通过代理区，正好表示完17个平面的所有字符。不得不佩服这帮工作人员的智慧。 但是如果将来出现18，19，...平面，UTF-16不是又挂了吗？不用担心，看到第一个平面的私人区域（文章第二张图中的红色方块）了吗，那个区域现在给私人使用，等到出现新的平面时，Unicode就要把这些区域收回自己使用了。

为什么说UTF-16不兼容ASCII？因为ASCII全是1字节，UTF-16最少2字节

ASCII编码AB转化二进制：01000001 01000010 UTF-16编码AB转化二进制：00000000 01000001 00000000 01000010

为什么4个字节的UTF-16编码需要这么复杂，需要去使用一个代理区域？为什么不直接用普通的 方式映射到4个字节上（就像UCS-4或UTF-32那样）？？？

摘自https://juejin.im/entry/59ae0bd7518825241e224c06?from=message&isappinstalled=0 答案是，如果直接用普通的方式将辅助平面的码位（U+10000到U+10FFFF）映射到4个字节， 而BMP平面（从U+0000至U+FFFF）继续使用2个字节，那么，最终在解析UTF-16的文件时， 我们就无法知道字符之间的边界了，不知道哪里是使用2个字节表示一个字符，哪里是使用4个字节表示一个字符， 但是，借助了代理区域之后，我们会发现，上面的低位代理和高位代理，这两个值的范围分别是0xD800到0xDBFF和0xDC00到0xDFFF， 而它们总的范围就是0xD800到0xDFFF，刚好就是代理区域的区间，所以，4个字节的UTF-16，高位两个字节范围处于代理区域， 而低位两个字节范围是不占用代理区域的。至此，我们就可以很容易识别出UTF-16的2个字节的码位和4个字节的码位。

UTF-16的动态编码 优点： 相比UCS-4(UTF-32)更节省空间。 相比于UCS-2能表示除基础平面的其他平面的字符。 缺点： 不能兼容ASCII编码

#####貌似丢了一个重量级的编码方式，那就是UTF-8 UTF-8编码实际上1992年就定义出来了，比UTF-16还早，但是一直没受到重视。直到2009才得到普及，这其中的故事那是相当曲折。之所以出现这种现象可能就是UCS-2的锅，因为UCS-2出现的太早了，以至于很多数码产品都是建立在它的基础之上的，为了平滑过渡到多平面，使用UTF-16无疑是最好的选择。

当然我们现在都使用UTF-8，在现代编码世界，它几乎无处不在。 他是怎么编码的？ UTF-8

它也是动态编码，不过比GB2312和UTF-16都要疯狂一些，他是1字节|2字节|3字节|4字节的动态编码，如果有需要，使用5,6,7....字节都是可以的，这种表示方式计算机也可以很好识别，

1字节编码的，字节开头就是0 2字节编码的，字节开头就是110, 3字节编码的，字节开头就是1110 4字节编码的，字节开头就是11110

其他字节已10开头，方便计算机识别这是不是一个完整的编码，有点类似于之前说过的奇偶校验。10被用掉了，所以其他动态编码类型的开头只能是从110开始了。真会玩

以“汉”为例，把它转化成以utf-8编码你就可以了解它的编码过程：

//第一步
"汉".charCodeAt() // 27721
//第二部
27721 在 2048 - 65535区间，所以为3字节表示
取 1110xxxx 10xxxxxx 10xxxxxx
//第三部，转化2进制
(27721).toString(2)  //110110001001001
//第四部
把 110 110001 001001
填充到1110xxxx 10xxxxxx 10xxxxxx 的x中，
从右到左，不够位补0
得：
11100110 10110001 10001001

UTF-8最大的优点就是 1.完全兼容ASCII编码，所以那些很古老的文档可以正常查看 2.从国际角度来说，使用拉丁字母的国家居多，所以很节省存储空间。

但是东亚地区的国家，比如说我们，就悲剧了，比如“汉”这个字符 GB2312编码后的2进制为 10111010 10111010 UTF-16编码后的二进制为 01101100 01001001 UTF-8编码后的二进制为 11100110 10110001 10001001 我们最常用的字符用UTF-8表示都变成了3字节，原来可都是2字节。哎。但是为了国际大局，我们也只能忍了。

#####下一篇，将会介绍前端开发涉及到的编码问题 *补充 以Unicode时间轴为主线，列出Unicode，ISO10646，以及JavaScript的发展。 时间轴.png

辅助平⾯到底是Unicode2.0之定义还是Unicode3.1定义？ 很明显，维基百科展示了Unicode辅助平⾯是2.0定义的，而百度词条表示是3.1定义的，为了找到答案，我翻找了Unicode官网资料。以下摘自Unicode统计。

unicode统计.png 这张图明确指出，在2.0时，码点已经达到178500 + 935612 = 1114112 个码点，也就是存在了基础平面之外的其他16个平面。为什么要确定什么时间点定义辅助平面呢？ 只有定义了辅助平面，UTF-16才有被创造出来的意义，因为UCS-2固定2字节不⽀持辅助平面，UTF-16的动态4字节才支持。