10.unicode

Unicode是一个字符集，旨在收录全世界的每个字符，并为这些字符统一编号（注意是编号，不是编码）。

编码方式：

将世上所有字符按一定的依据，分为17个大的组别。官方话语里将每一个组别称为一个平面（plane）。
每个平面上有2^16 = 65536个位置，依次编号0000-FFFF，理论上可以用来保存65536个字符。
这17个平面分别为 0~16号平面，用16进制数分别表示为0-10。这样世上的每一个字符就有了一个编号。如：
编号 U+0000 表示第一平面（0号平面）的第一个字符（注意不是U+00000）
编号 U+1FFFF 表示第二平面（1号平面）的最后一个字符
某个字符的统一编号叫做这个字符的码点或码位（code point）
0号平面称为基本多文种平面，包含了各种语言最常用的字符。如其4E00-9FFF段为中日韩统一表意文字。每个平面的基本信息如下图：

实现方式

Unicode只提供了字符集和每个字符的编码，但在计算机中每个字符的Unicode编码如何存储，先后产生了多种不同的实现方式，如目前流行的UTF-8。

UTF-8

是一种变长的编码方式，使用1-6个字节来保存字符的Unicode编码（"8"是指表示一个字符最少需要8个比特位）。意思就是说表示某个字符的二进制串可能是1字节、2字节、3字节、...6字节。如：
字符a 的Unicode编码为U+0061 ，也就是0号平面的第97个字符。计算机只需要存下它的序号97，即：0000 0000 0110 0001的有效部分110 0001，用1字节即可存储。
但是如果一个字符如ř，U+0159，二进制为0000 0001 0101 1001，其有效部分是9位，那该如何表示呢？自然最少要两个字节。如果简单粗暴的直接用0000 0001 0101 1001表示，又会带来其他麻烦，比如：当遇到一个连续的二进制串 0110 0001 0000 0001 0101 1001，原想表达的是ař，可机器怎么知道你是0110 0001，0000 0001 0101 1001而不是0110 0001，0000 0001， 0101 1001。所以这就需要有一种手段告诉机器，哪几个字节是用来一起表示一个字符的。utf8的方式是在每个字节前加固定标识：

单个字节标识一个字符的，其首位固定为 0
n个字节标识一个字符的，其首字节以n个1接一个0开头，该字符剩下的字节以10开头
除去标识部分剩下的比特位，才是真正可用来有效部分的（所以不妨称为有效位）

即（其中x是有效比）：
单字节字符： 0xxxxxxx
二字节字符： 110xxxxx 10xxxxxx
三字节字符： 1110xxxx 10xxxxxx 10xxxxxx
...

最初美国人制定了ascii字符集，共128个字符，一个字节最多能表示2^8=256个字符，而它只需要用128个，用 00000000~01111111就能表示完。所以最初的ascii编码是0xxxxxxx的形式，有最高位的 0是浪费着没用的。后来西欧各国利用高位未用的 0，把自己的字符也加进去了，如法语中的 é 编码为10000010，也是一个字节就能表示一个字符，这就是扩展后的ascii码。

注意到utf8里要求单字节字符的第一位是0，这意味着，在 utf8里 ascii拓展后的西欧各国的字符不会再是单字节了，拓展前的美国人最常用的字符，仍然还是单字节。

若n（n>1）个字节表示一个字符，除去标识部分后，有效位位数是5n+1

以汉字“赵”为例，详细说明其编码转换过程。

由'赵'.charCodeAt(); //36213 可以得到，“赵”的码点为U+8d75，转化成二进制就是1000 1101 0111 0101。那么需要存储的就是16个比特位，根据5n+1，得出需要3个字节。所以“赵”的utf8编码格式是：
1110xxxx 10xxxxxx 10xxxxxx
在占位符上填入'赵'的二进制码点，得到赵的utf8编码：
11101000 10110101 10110101

UTF-16

utf16和utf8很像，也是变长编码，"16"是指表示一个字符最少需要16个比特位。-

对于基本多文种平面的字符：编码直接就是原码点。xxxxxxxx xxxxxxxx，二字节
对于其他平面的字符：码点减去0x10000，然后填入到 110110xx xxxxxxxx 110111xx xxxxxxxx形式中，四字节

这里有两个问题：

1.为什么要减去0x10000?
因为四字节形式中，最多可以有20个bit来存数据。对于第十七平面的字符（U+100000~U+10FFFF）有21个字节，显然是存不下的。所以对于四字节的字符直接把平面数-1，U+10xxxx变成U+Fxxxx，U+Fxxxx变成U+Exxxx，就刚好可以存。
2.如果文本里有两个基本平面的字符一起出现，110110xx xxxxxxxx、110111xx xxxxxxxx，不会和其他平面的某个四字节字符冲突？
Unicode标准规定U+D800...U+DFFF的值不对应于任何字符。这两个mark串就选自这个范围。

当字符为0号平面上的字符时，直接用其码点是二进制码表示。如：
“赵” U+8d75 用 1000 1101 0111 0101表示。

当字符不是0号平面上的字符时，转换算法如下：
以汉字"" U+20021为例，

码点减去 0x10000，得到0x10021
转换成二进制 得到0001 0000 0000 0010 0001
把上步得到的20个比特位，按110110xx xxxxxxxx 110111xx xxxxxxxx格式填入
得到11011000 01000000 11011100 00100001

其前两个字节 11011000 01000000 = 55360，所以''.charCodeAt(0) === 55360
后两个字节11011100 00100001= 56353，所以''.charCodeAt(1) === 56353

值得一提的是，js内部使用的是utf16储存字符（JavaScript 引擎内部是自由的使用 UCS-2 或者 UTF-16。大多数引擎使用的是 UTF-16），1个字符2个字节，并规定2个字节的length为1，所以'赵'.length === 1，0号平面以外的字符，如''.length === 2。

提个问题：js如何准确判断字符串长度？`'ab好'.length`?

function countString(str): number {
  let count = 0;
  for (let i = 0; i < str.length; i++) {
    if (isFirstPlainUnicode(str.charCodeAt(i))) {
      count++;
      continue;
    }
    count++;
    i++;
  }
  return count;
}

function isFirstPlainUnicode(charCode: number): boolean {
  const binary = charCode.toString(2);
  return !binary.startsWith('110110') && !binary.startsWith('110111');
}

countString('a开户行');

UTF-32

能找到的详细介绍utf-32的资料太少了，以下内容出自 wiki

UTF-32是32位Unicode转换格式（Unicode Transformation Formats，或UTF）的缩写。UTF-32是一种用于编码Unicode的协定，该协定使用32位比特对每个Unicode码位进行编码（但前导比特数必须为零，故仅能表示2²¹个Unicode码位）。与其他可变长度的Unicode转换格式（UTF）相比，UTF-32编码长度是固定的，UTF-32中的每个32位值代表一个Unicode码位，并且与该码位的数值完全一致。

只能根据最后一句话 "UTF-32中的每个32位值代表一个Unicode码位，并且与该码位的数值完全一致。"，推测其编码实现应该就是直接将码点转换成32位二进制码。
如：“赵” U+8d75，00000000 00000000 01001101 01110101

字节序 (Endianness)

在计算机中，对多个字节的二进制数如何存储，不同架构的cpu有不同的处理方式。分为以下两种处理方式：

Big-Endian（大端序）就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。换言之，先从内存中读取到的字节，是高位。即高位在前。
Little-Endian（小端序）就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。简言之，低位在前。
如有二进制数 10101011 00110011 （0xab33），其高位字节是ab，低位字节是33。
假设有低位地址0x0000，高位地址0x0001。
0x0000存放ab，0x0001存放33，就是大端序；
0x0000存放33，0x0001存放ab，就是小端序。

假如某台机器，其使用的是小端序。它的读和写都是小端序，它就无需考虑字节序问题，程序总能正常运行。但是当它和另外一台机器交流时，就需要考虑字节序问题。
比如一台小端序的机器，打开了一个大端序编码的文本文件，如果不做任何处理，读取内容就会出问题。
所以文本文件，在生成的时候，会在文本文件头部加上一个标识，表明其字节序（以及其实现方式：utf8 / utf16 / utf32）。

比如，当读取一个文本时，如果读到的开头字节是FE FF，则说明这是一个utf16编码的文本，且是大端序。其标识（BOM ，Byte Order Mark，字节顺序标记）具体对应规则如下图：

现在来一个实例看一下：
我本地有个文本文件：

image.png

可以看到原始状态是utf8编码的，点击图中右下角的红框，将其转化为UTF-16LE

image.png

然后用node的fs读一下文件：

image.png

发现其开头二字节是FF FE，对照上表，完全符合。

需要说明的是，虽然utf8/16/32前面都有这个标识，但实际上utf8是不存在字节序问题的，这是因为utf8的基本处理长度是一个字节。原因如下：
由前面的utf8的编码实现方式可知，每个字节的开头只能是三种情况：

0开头，如0xxxxxxx，表明这个字符只有一个字节
10开头，如10xxxxxx，表明这个字符有n个字节，且本字节不是第一个字节
1...10开头，如1110，表明这个字符有3个字节，且本字节是第一个字节

现在有文本，"你好a"。假设其utf8编码是：
110xxxxx 10xxxxxx (你)，1110xxxx 10xxxxxx 10xxxxxx(好)，0xxxxxxx(a)，共6字节长。
如果是大端序存储，则读取到的数据为：
110xxxxx 10xxxxxx，1110xxxx 10xxxxxx 10xxxxxx，0xxxxxxx
如果是小端序存储，则读取到的数据为：
10xxxxxx 110xxxxx，10xxxxxx 10xxxxxx 1110xxxx，0xxxxxxx
读取某字符的首字节时，其开头：
如果是0开头，知道这个字符只有这一个字节，可以解析。
如果是10开头，知道这是小端序，只需要继续往下读，读到1..10开头的字节时，这个字符结束，可以解析。
如果是1110开头，知道这是大端序，知道这个字符是3个字节，再读两个字节即可解析。
所以，utf8不是不存在字节序问题，而是它自己能判断。

utf16就不一样了，如中文“啊”，00110011 00101010，简记为554A。
以小端序编码会存为 4A55，当一台大端序的机器读取时，就会认为其码点是 u+4A55。此时因为没有信息告诉机器，需要纠正为u+554A，就会解析成其他字符。
utf32也是同样的道理。

10.unicode

编码方式：

实现方式

UTF-8

UTF-16

提个问题：js如何准确判断字符串长度？'ab好'.length?

UTF-32

字节序 (Endianness)

你可能感兴趣的:(10.unicode)

提个问题：js如何准确判断字符串长度？`'ab好'.length`?