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-4个字节来保存字符的Unicode编码（"8"是指表示一个字符最少需要8个比特位）。如：
字符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>=16，得出最少需要3个字节
- 所以“赵”的utf8编码格式是：
1110xxxx 10xxxxxx 10xxxxxx- 在占位符上填入'赵'的二进制码点，得到赵的utf8编码：
11101000 10110101 10110101 - 当不能全部占满空位时，需要在前面补0，比如，汉字
分 -
'分'.charCodeAt().toString(2) = 101001000000110// 15位 - 最少需要三个字节，但是三子节共有16个空位
- 则前面加0，补足16位，变成
0 101001000000110
UTF-16
utf16和utf8很像，也是变长编码，"16"是指表示一个字符最少需要16个比特位。其表示字符只有2字节、4字节两种情况：
二字节：xxxxxxxx xxxxxxxx
四字节：110110xx xxxxxxxx 110111xx xxxxxxxx
当字符为0号平面上的字符时，直接用其码点是二进制码表示。如：
“赵” U+8d75 用 1000 1101 0111 0101表示
当字符不是0号平面上的字符时， 转换算法如下：
- 码点减去 0x10000，即十进制的65536
- 将结果转换成二进制
- 将这些位按照
110110xx xxxxxxxx 110111xx xxxxxxxx的格式填入空位处
以汉字“𧅄"** U+27144为例**：
- 码点减去 0x10000，得到
0x17144 - 转换成二进制，得到
0001 0111 0001 0100 0100 - 填入空位，得到110110
00 0101110011011101 01000100，共4字节
这里有两个问题：
1、为什么utf16编码辅助平面时候，要减去一个 0x10000=65536
因为最后一个平面，也就是第17个平面，其长度为21个比特。比如其第一个码点：10000 00000000 00000000
按照utf16 110110xx xxxxxxxx 110111xx xxxxxxxx的格式，最多只能存20位，所以将直接码点下移一个平面
2、为什么是110110和110111？
因为基本平面中，从 [0xD800-0xDFFF] 的码点是空闲的，不对应于任何字符。
0xD800 1101100000000000
0xDFFF 1101111111111111
所以 110110... ~ 110111...不会和基本平面冲突
值得一提的是，js内部使用的是utf16储存字符（JavaScript 引擎内部是自由的使用 UCS-2 或者 UTF-16。大多数引擎使用的是 UTF-16），1个字符2个字节，并规定2个字节的length为1。
所以0号平面的字符长度为1，如'赵'.length === 1
0号平面以外的字符，长度为2，如'𧅄'.length === 2
'𧅄'.charCodeAt(0) //55388，实际是获取的其前两个字节 11011000 01011100 = 55388
所以有时候js计算字符长度，如果包含有其他平面的字符，长度就是错的。要另外想办法。这里提供一个方法：
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开户行😘');
这个方法用来计算emoji的时候，有可能还是会错。这倒不是有bug，而是又写emoji，似乎是由多个emoji组合成的一样。比如：
光标可以移动它中间，敲一下空格，还会变成两个emoji。
UTF-32
能找到的详细介绍utf-32的资料太少了，以下内容出自 wiki
UTF-32是32位Unicode转换格式（Unicode Transformation Formats， 或UTF）的缩写。UTF-32是一种用于编码Unicode的协定，该协定使用32位比特对每个Unicode码位进行编码（但前导比特数必须为零，故仅能表示221个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，字节顺序标记）具体对应规则如下图：
现在来一个实例看一下：
我本地有个文本文件：
可以看到原始状态是utf8编码的，点击图中右下角的红框，将其转化为UTF-16BE
然后用node的fs读一下文件：
发现其开头二字节是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也是同样的道理。
