于是，就计算出了 Unicode 码 0x10A6F 的 UTF-16 编码是 11011000 00000010 11011110 01101111 , 转换成十六进制就是 0xD802DE6F， 对应上图的 步骤 5
UTF-32 编码UTF-32 是固定长度的编码，始终占用 4 个字节，足以容纳所有的 Unicode 字符，所以直接存储 Unicode 码即可，不需要任何编码转换。虽然浪费了空间，但提高了效率。
UTF-8、UTF-16、UTF-32 之间如何转换前面介绍过，UTF-8、UTF-16、UTF-32 是 Unicode 码表示成不同的二进制格式的编码规则，同样，通过这三种编码的二进制表示，也能获得对应的 Unicode 码，有了字符的 Unicode 码，按照上面介绍的 UTF-8、UTF-16、UTF-32 的编码方法 就能转换成任一种编码了
UTF 字节序最小编码单元是多字节才会有字节序的问题存在，UTF-8 最小编码单元是一字节，所以 它是没有字节序的问题，UTF-16 最小编码单元是 2 个字节，在解析一个 UTF-16 字符之前，需要知道每个编码单元的字节序
比如：前面提到过，"中" 字的 Unicode 码是 4E2D, "ⵎ" 字符的 Unicode 码是 2D4E， 当我们收到一个 UTF-16 字节流 4E2D 时，计算机如何识别它表示的是字符 "中" 还是 字符 "ⵎ" 呢 ?
所以，对于多字节的编码单元，需要有一个标记显式的告诉计算机，按照什么样的顺序解析字符，也就是字节序，字节序分为 大端字节序 和 小端字节序
小端字节序简写为 LE( Little-Endian ), 表示 低位字节在前，高位字节在后, 高位字节保存在内存的高地址端，而低位字节保存在内存的低地址端
大端字节序简写为 BE( Big-Endian ), 表示 高位字节在前，低位字节在后，高位字节保存在内存的低地址端，低位字节保存在在内存的高地址端
下面以 0x4E2D 为例来说明大端和小端，具体参见下图:
数据是从高位字节到低位字节显示的，这也更符合人们阅读数据的习惯，而内存地址是从低地址向高地址增加
所以，字符0x4E2D 数据的高位字节是 4E，低位字节是 2D
按照大端字节序的高位字节保存内存低地址端的规则，4E 保存到低内存地址 0x10001 上，2D 则保存到高内存地址 0x10002 上
对于小端字节序，则正好相反，数据的高位字节保存到内存的高地址端，低位字节保存到内存低地址端的，所以 4E 保存到高内存地址 0x10002 上，2D 则保存到低内存地址 0x10001 上
BOMBOM 是 byte-order mark 的缩写，是 "字节序标记" 的意思, 它常被用来当做标识文件是以 UTF-8、UTF-16 或 UTF-32 编码的标记
在 Unicode 编码中有一个叫做 "零宽度非换行空格" 的字符 ( ZERO WIDTH NO-BREAK SPACE ), 用字符 FEFF 来表示
对于 UTF-16 ，如果接收到以 FEFF 开头的字节流， 就表明是大端字节序，如果接收到 FFFE， 就表明字节流 是小端字节序
UTF-8 没有字节序问题，上述字符只是用来标识它是 UTF-8 文件，而不是用来说明字节顺序的。"零宽度非换行空格" 字符 的 UTF-8 编码是 EF BB BF, 所以如果接收到以 EF BB BF 开头的字节流，就知道这是UTF-8 文件
下面的表格列出了不同 UTF 格式的固定文件头
UTF编码 固定文件头UTF-8 EF BB BF
UTF-16LE FF FE
UTF-16BE FE FF
UTF-32LE FF FE 00 00
UTF-32BE 00 00 FE FF
根据上面的 固定文件头，下面列出了 "中" 字在文件中的存储 ( 包含文件头 )
编码 固定文件头Unicode 编码 0X004E2D
UTF-8 EF BB BF E4 B8 AD
UTF-16BE FE FF 4E 2D
UTF-16LE FF FE 2D 4E
UTF-32BE 00 00 FE FF 00 00 4E 2D
UTF-32LE FF FE 00 00 2D 4E 00 00
常见的字符编码的问题
Redis 中文key的显示
有时候我们需要向redis中写入含有中文的数据，然后在查看数据，但是会看到一些其他的字符，而不是我们写入的中文
上图中，我们向redis 写入了一个 "中" 字，通过 get 命令查看的时候无法显示我们写入的 "中" 字
这时候加一个 --raw 参数，重新启动 redis-cli 即可，也即 执行 redis-cli --raw 命令启动redis客户端，具体的如下图所示
MySQL 中的 utf8 和 utf8mb4