[转帖]一次搞定 Unicode、字节序、UTF-*

茫茫人海中与你相遇

相信未来的你不会很差

作者：Tomson                                                                          

来源：https://segmentfault.com/a/1190000038171151

什么是字符集

什么是 ASCII

什么是 Unicode

• 0xD800 - 0xDFFF，共 2048 个码位，是一个被称作代理区(Surrogate)的特殊区域。代理区的目的是用两个 UTF-16 字符表示 BMP 以外的字符。

什么是 UTF-32

什么是 UTF-8

• 对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。
• 对于n字节的符号(n > 1)，第一个字节的前n位都设为1，第n + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。

• “汉” 字的 Unicode 编码是 0x6C49。0x6C49 在 0x0800-0xFFFF 之间，需要使用 3 字节模板：1110xxxx 10xxxxxx 10xxxxxx。将 0x6C49 写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的 x，得到：11100110 10110001 10001001，即 E6 B1 89。这里的  E6 B1 89 便是“汉” 字的 UTF-8 编码。当然原先占两个字节的  Unicode 码点的进行 UTF-8 编码后的码点占 3 个字节；
• Unicode 编码 0x20C30 在0x010000 - 0x10FFFF 之间，使用 4 字节模板：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将 0x20C30 写成 21位二进制数字(不足21位就在前面补0)：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即 `F0 A0 B0 B0；

什么是 UTF-16

什么是字节序

先看字节序的定义，援引维基百科

Endianness is the sequential order in which bytes are arranged into larger numerical values when stored in memory or when transmitted over digital links.

UTF 的字节序和 BOM

引用至 How to teach endian 的一段话：

One of the major disciplines in computer science is parsing/formatting. This is the process of converting the external format of data (file formats, network protocols, hardware registers) into the internal format (the data structures that software operates on).

An external format must be well-defined. What the first byte means must be written down somewhere, then what the second byte means, and so on. For Internet protocols, these formats are written in RFCs, such as RFC 791 for the "Internet Protocol". For file formats, these are written in documents, such as those describing GIF files, JPEG files, MPEG files, and so forth.

翻译过来就是：

解析/格式化是计算机科学的主要学科之一。这是将数据的外部格式(文件格式，网络协议，硬件寄存器)转换为内部格式(软件所操作的数据结构)的过程。

外部格式必须定义明确。必须将第一个字节的含义写在某个地方，然后将第二个字节的含义写下，依此类推。对于Internet协议，这些格式以 RFC 编写，例如“ Internet协议”的 RFC 791。对于文件格式，这些格式写在文档中，例如描述 GIF 文件，JPEG 文件，MPEG 文件等的文档。

Unicode 规范中推荐的标记字节顺序的方法是 BOM。BOM 不是 “Bill Of Material” 的 BOM 表，而是 Byte Order Mark。

在 UCS 编码中有一个叫做 "ZERO WIDTH NO-BREAK SPACE” 的字符，它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。

UCS 规范建议我们在传输字节流前，先传输字符 "ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到 FFFE ，就表明这个字节流是 Little-Endian 的。因此字符 "ZERO WIDTH NO-BREAK SPACE” 又被称作 BOM。

UTF-8 不需要 BOM 来表明字节顺序，但可以用 BOM 来表明编码方式。字符 "ZERO WIDTH NO-BREAK SPACE” 的 UTF-8 编码是EF BB BF所以如果接收者收到以 EF BB BF 开头的字节流，就知道这是 UTF-8 编码了。

举例如下(这里假设每个内存地址保存一个字节数据)：

如上表所示：如果我们单纯保存一个内容为 “1”(Unicode 编码为 0x31)的一个文本数据，选择带不带 BOM 保存的内容是不一致的，针对第一种我们明确的使用了 UTF-8 的编码进行存储，如果需要重新加载这个文本数据，将数据从内存(或指定存储结构)加载出来(这里只有一个字节，文件大小文件地址等在文件元信息可以获取)，如何展示这个加载数据取决于我们选择什么编码方式，由于我们是使用特定的格式(UTF-8)写入，所以我们需要指明使用特定的格式( UTF-8) 去读取才能正确读取出文本 “1”，否则如果我们选择直接展示16 进制数据的话得到的内容便是 31。

现在大部分数据加载工具都会设定默认的编码方式，譬如文本工具等基本默认编码方式都是 UTF-8。那为了让某些未设置默认读取方式的数据加载工具能正确识别数据编码，便需要我们在写入数据时优先写入 BOM，如上表 文本 1 带上 BOM 后写入内容将多占用 3 个字节。有了这 3 个字节的 BOM 数据加载方便清楚接下来使用 UTF-8 去解析内容。

中文 “我” 的 Unicode 编码为 0x6211，二进制为 0110 0010 0001 0001 根据前文的 Unicode UTF -8 编码规则得出 “我” 的 UTF-8

属于范围 0000 0800 - 0000 FFFF ，替换模板为 1110xxxx 10xxxxxx 10xxxxxx  带入模板后得出二进制为: 11100110 10001000 10010001 转换成 16 进制便是 E6 88 91。

如果是使用 UTF-16 编码：

UTF-16的编码长度要么是2个字节(U+0000 到 U+FFFF)，要么是4个字节(U+010000 到 U+10FFFF)。

中文 “我” 的 Unicode 编码为 6211，UTF-16 没有特殊的转换规则，每次读取或写入数据必须是 2 个字节，刚刚我字占用 2 个字节。

如上表所示，如果采用大端字节排序的方式(UTF-16 BE)存储数据在内存中的表示是与人类阅读的方式一致的，如果是小端字节序的方式存储则直观看起来有点反人类。

主机字节序

网络字节序与主机字节序是经常导致混淆的两个概念，网络字节序是确定的，而主机字节序的多样性往往是混淆的原因。

基本 x86 系列 CPU 都是 little-endian 的字节序。

举例说明：

假设每个内存地址单位存一个字节

例子：在内存中双字 0x01020304(DWORD) 的存储方式

或则：

例子：如果我们将 0x1234abcd 写入到以 0x0000 开始的内存中，则结果为

或则：

基本是 ：

• 字节角度：字节高位在内存高位代表的是小端字节序，相反字节高位在内存低位便是大端字节序;
• 内存角度：内存低位在字节低位便是小端字节序，相反内存低位放字节高位代表的是大端字节序;
• 总结：字节高位放内存高位或字节低位放内存低位则是小端字节序，否则就是大端字节序。

  

  

正常情况下我们都无需去关心主机字节序，因为如何存储是外部存储器或则说使驱动需要关心的，我们只需要正常写入数据和读取数据即可，其他的字节序的处理无需我们去关心，我们更多需要关心的应该使网络字节序

网络字节序

网络 字节顺序 是 TCP/IP 协议中规定好的一种数据表示格式，它与具体的 CPU 类型、操作系统 等无关，从而可以保证数据在不同主机之间传输时能够被正确解释。网络字节顺序采用 big endian(大端)排序方式。

由于网络协议中默认使用的是大端字节序，大家都遵守这个规则，自然而然的大家直接用大端字节序去解析网络数据便可以的到相应的信息，便不需要手动去声明这个数据包是大端字节序的。当然前提是你发送出去的数据也是大端字节序的(如果你发送出去的数据是小端字节序编码的自然收取方也得主动用小端的去解析 )。

文件字节序

除了主机字节序以及网络字节序，还有一种便是我们在保存文件的时候主动声明使用的字节序。

譬如我们在保存一个文本文件的时候我们可以设置其保存格式为 ：UTF-8 / UTF-8 带 BOM / UTF-16 LE / UTF-16 LE 带 BOM / UTF-16 BE / UTF-16 BE 带 BOM / UTF-32 LE / UTF-32 LE 带 BOM / UTF-32 BE / UTF-32 BE 带 BOM / UCS….

什么时候需要关心字节序

使用底层语言譬如 C 语言之类的，我们需要手动将读取到的内存转换为指定的数值类型，这个时候就需要知道具体内存的字节序，譬如如果是大端则几个字节拿出来直接拼在一起可以作为数值使用，否则是小端的话得坐相应的处理才能得到最终的值。高级语言一般不需要我们直接操作内存，运行环境直接帮我们做好处理。

一般开发的时候声明的变量，如果是数值类型，在运行时，运行环境会自动帮我们处理好数值在内存中的表现，无需过度关心，数值在内存中既有可能大端字节序存储也有可能是小端字节序存储，取决于系统的需要。如果是字符类型也同理，运行环境已经会自动帮我们处理好，声明时是什么值使用的时候便是什么值，无需关心在内存中的表现。

跨主机即联网的时候需要确认发送出去的数据的字节序，接收方需要使用相同的字节序去解析，TCP/IP 协议规定一般使用大端字节序。

Hashbang 注释

Hashbang 注释 是一种专门注释语法

对于 JavaScript 而言，Hashbang注释正在 ECMAScript 中标准化(参见 Hashbang 语法建议[https://github.com/tc39/propo...])。

Hashbang 注释的行为与单行(//)注释完全相同，但它以 #! 开头且仅在脚本或模块的绝对开头有效。还要注意，在 #! 之前不允许有任何类型的空格。

注释由 #! 之后的所有字符组成直到第一行的末尾；只允许有一条这样的注释。Hashbang 注释指定特定 JavaScript 解释器的路径要用于执行脚本。示例如下：

#!/usr/bin/env nodeconsole.log("Hello world");

注意：JavaScript 中的 Hashbang 注释模仿 Unix 中的 Shebangs，用于指定适当的解释器运行文件。

尽管在 Hashbang 注释之前的 BOM 在浏览器中能工作，但不建议在具有 Hashbang 的脚本中使用 BOM。当您尝试在 Unix/Linux 中运行脚本时，有 BOM 将不工作。因此，如果要直接从 shell 运行脚本，请使用没有 BOM 的 UTF-8。您只能使用 #! 注释样式以指定 JavaScript 解释器。在所有其他情况下，只需使用 // 注释(或多行注释)。

在 JavaScript 中使用 Unicode

十六进制

> 0x00A9 // 这是一个 16 进制数字169  // 直接执行默认输出为 10 进制

十六进制表示一个转义序列

> '\xA9' // 一个字符通过 16 进制表示，或则说这里两个 16 进制所代表的字符通过 '\x' 转义表示 ,最多支持两个 16 进制"©"

> '\xA9' === String.fromCodePoint(0xA9)true

Unicode 转义序列要求在\\u之后至少有四个字符(4 个 16 进制，代表两个字节)

> '\u00A9' // \u 后面接 4 个 16 进制数表示一个字符转义"©"

Unicode 编码转义是 ECMAScript 6 新增特性。使用 Unicode 编码转义，任何字符都可以被转义为十六进制编码。最高可以用到0x10FFFF。

使用单纯的 Unicode 转义通常需要写成分开的两半以达到相同的效果。可以参考 String.fromCodePoint() 和 String.prototype.codePointAt() 。

'\u{2F804}' // 对于某些字符超出两个字节表示的就得可以用 \u{} 包起对应的若干个 16 进制，不能超过 10FFFF// 使用单纯 Unicode 转义'\uD87E\uDC04' // 使用两个 UTF-16 单元凑成一个 4 字节的字符码点

不同字节字符表示方式

'\xA9'             // 支持一个字节表示字符'\u00A9'         // 支持两个字节表示字符'\u{2F804}'        // 支持两个以上字节表示字符

两个\\x表示的字符无法拼接成一个双字节的字符

> '\u01ff' // 双字节字符"ǿ"> '\x01\xff' // \x01 是不可打印字符，相当于两个字符串拼接"ÿ"

两个 \\u表示的字符可以拼接成一个四字节的字符

// "?" 在 UTF-16 是一个 4 字节字符 码点是 20bb7> "?".charCodeAt(0) // 获取前面两个字节的 10 进制55362> "?".charCodeAt(1) // 获取后面两个字节的 10 进制57271> (55362).toString(16)  // 获取对应的 16 进制"d842"> (57271).toString(16)    // 获取对应的 16 进制"dfb7"> '\ud842\udfb7'"?"> "?".codePointAt(0) // 获取完整字符的 10 进制134071(134071).toString(16) // 获取对应的 16 进制"20bb7"

相关 API：

• str.charCodeAt

• str.codePointAt

• str.charAt

• String.fromCodePoint()

• String.fromCharCode

'\z' === 'z'  // true'\172' === 'z' // true'\x7A' === 'z' // true'\u007A' === 'z' // true'\u{7A}' === 'z' // true

我们在虚拟的空间与你相遇，期待可以碰撞出不一样的火花