一次搞定 Unicode、字节序、UTF-*

前置阅读：

什么是字符集

顾名思义，字符集就是字符的集合。

什么是 ASCII

ASCII ((American Standard Code for Information Interchange): 美国信息交换标准代码）是基于拉丁字母的一套电脑编码系统，主要用于显示现代英语和其他西欧语言。

在计算机中，所有的数据在存储和运算时都要使用二进制数表示（因为计算机用高电平和低电平分别表示1和0），例如，像 a、b、c、d 这样的 52 个字母（包括大写）以及 0、1 等数字还有一些常用的符号（例如 *、#、@ 等）
既然要使用二进制数来表示字符，那具体用哪些二进制数字表示哪个符号，当然每个人都可以约定自己的一套（这就叫编码），而大家如果要想互相通信而不造成混乱，那么大家就必须使用相同的编码规则，于是美国有关的标准化组织就出台了 ASCII 编码，统一规定了上述常用符号用哪些二进制数来表示。

美国信息交换标准代码是由美国国家标准学会(American National Standard Institute , ANSI ) 制定的，是一种标准的单字节字符编码方案，用于基于文本的数据。
它最初是美国国家标准，供不同计算机在相互通信时用作共同遵守的西文字符编码标准，后来它被国际标准化组织（International Organization for Standardization, ISO）定为国际标准，称为 ISO 646 标准。

简单的说 ASCII 码表就是一套最基础的编码库或字符集，里面包括了字母、数字、符号以及一些控制字符。

什么是 Unicode

Unicode 是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案，通过 Unicode 编码规则出来的字符的集合便叫做 Unicode 字符集。

计算机只能处理数字（0、1），如果要处理文本，就必须先把文本转换为数字才能处理。最早的计算机在设计时采用 8 个比特（bit）作为一个字节（byte）。
一个字节能表示的最大的整数就是 255（2⁸-1=255），而 ASCII 编码，占用 0 ~ 127 用来表示大小写英文字母、数字和一些符号，这个编码表被称为 ASCII 编码，比如大写字母 A 的编码是 65，小写字母 z 的编码是 122。

如果要表示中文，显然一个字节是不够的，至少需要两个字节，而且还不能和 ASCII 编码冲突，所以，中国制定了 GB2312 编码，用来把中文编进去。
类似的，日文和韩文等其他语言也有这个问题。为了统一所有文字的编码，Unicode 应运而生。Unicode 把所有语言都统一到一套编码里，这样就不会再有乱码问题了。

Unicode 用若干个字节表示一个字符，原有的英文编码如果想从单字节变成双字节，只需要把高字节全部填为 0 就可以。在表示一个 Unicode 的字符时，通常会用 “U+” 然后紧接着一组十六进制的数字来表示这一个字符。

目前的 Unicode 字符分为 17 组编排，0x0000 至 0x10FFFF，每组称为平面（Plane），而每平面拥有 65536 （即2¹⁶）个码位，共 1,114,112 个。然而目前只用了少数平面。

平面	始末字符值	中文名称	英文名称
0号平面	U+0000 - U+FFFF	基本多文种平面	Basic Multilingual Plane，简称 BMP
1号平面	U+10000 - U+1FFFF	多文种补充平面	Supplementary Multilingual Plane，简称 SMP
2号平面	U+20000 - U+2FFFF	表意文字补充平面	Supplementary Ideographic Plane，简称 SIP
3号平面	U+30000 - U+3FFFF	表意文字第三平面	Tertiary Ideographic Plane，简称 TIP
4号平面至 13号平面	U+40000 - U+DFFFF	（尚未使用）
14号平面	U+E0000 - U+EFFFF	特别用途补充平面	Supplementary Special-purpose Plane，简称 SSP
15号平面	U+F0000 - U+FFFFF	保留作为私人使用区（A区）	Private Use Area-A，简称 PUA-A
16号平面	U+100000 - U+10FFFF	保留作为私人使用区（B区）	Private Use Area-B，简称 PUA-B

其中平面 15 和平面 16 上只是定义了两个各占 65534 个码位的专用区（Private Use Area），分别是0xF0000 - 0xFFFFD 和 0x100000 -0x10FFFD。所谓专用区，就是保留给大家放自定义字符的区域，可以简写为PUA。

平面 0 也有专用区：

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

Unicode 只规定了每个字符的码点，到底用什么样的字节序表示这个码点，就涉及到编码方法。

Unicode 字符集有多种编码方式，分别是 UTF-8、UTF-16 和 UTF-32 /...

什么是 UTF-32

由于 Unicode 码点最大占用 4 个字节，如果每个码点固定使用四个字节表示，字节内容一一对应码点。这种编码方法就叫做UTF-32。比如，码点 0 就用四个字节的 0 表示，码点 59 7D 就在前面加两个字节的 0 。

UTF-32的优点在于，转换规则简单直观，查找效率高。缺点在于浪费空间，同样内容的英语文本，它会比ASCII编码大四倍。这个缺点很致命，导致实际上没有人使用这种编码方法，HTML 5标准就明文规定，网页不得编码成UTF-32。

人们真正需要的是一种节省空间的编码方法，这导致了UTF-8的诞生。

什么是 UTF-8

UTF-8是一种变长的编码方法，字符长度从1个字节到4个字节不等。

越是常用的字符，字节越短，最前面的128个字符，只使用1个字节表示，与ASCII码完全相同。

UTF-8 以字节为单位对 Unicode 进行编码。 UTF-8 的编码方式如下：

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

Unicode 编码(十六进制)	UTF-8 字节流(二进制)	x 数量
0000 0000 - 0000 007F	0xxxxxxx	7
0000 0080 - 0000 07FF	110xxxxx 10xxxxxx	11
0000 0800 - 0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx	16
0001 0000 - 0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx	21

通过规则可以看出并不是直接把十六进制的 Unicode 码直接转成二进制就是 UTF-8 码，而是通过编码方式进行转换，原先 Unicode 编码下最大码点是 10FFFF 大小不超过 3 个字节，但是转换成 UTF-8 后最大需要用 4 个字节去表示。

这个规则的好处在于能够使解析的时候快速确认当前字符需要多少个字节。<u>UTF-8 编码的最大长度是 4 个字节</u>。

UTF-8 的特点是对不同范围的字符使用不同长度的编码。对于 0x00 - 0x7F 之间的字符，UTF-8 编码与 ASCII 编码完全相同。

从上表可以看出，4 字节模板有 21个 x，即可以容纳 21 位二进制数字。Unicode 的最大码位 0x10FFFF 也只有21位。编码举例如下：

“汉” 字的 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

UTF-16编码介于UTF-32与UTF-8之间，同时结合了定长和变长两种编码方法的特点。

它的编码规则很简单：基本平面的字符占用2个字节，辅助平面的字符占用4个字节。也就是说，UTF-16的编码长度要么是2个字节（U+0000到U+FFFF），要么是4个字节（U+010000到U+10FFFF）。

于是就有一个问题，当我们遇到两个字节，怎么看出它本身是一个字符，还是需要跟其他两个字节放在一起解读？

前面在 Unicode 部分说到，在基本平面内，从 U+D800 到 U+DFFF 是一个空段，即这些码点不对应任何字符。因此，这个空段可以用来映射辅助平面的字符。

具体来说，辅助平面的字符位共有220个，也就是说，对应这些字符至少需要 20 个二进制位。UTF-16 将这 20 位拆成两半，前 10 位映射在 U+D800 到 U+DBFF（空间大小210），称为高位（H），后 10 位映射在 U+DC00 到 U+DFFF（空间大小210），称为低位（L）。这意味着，一个辅助平面的字符，被拆成两个基本平面的字符表示。

所以，在UTF-16 编码下，当我们遇到两个字节，发现它的码点在 U+D800 到 U+DBFF 之间，就可以断定，紧跟在后面的两个字节的码点，应该在 U+DC00 到 U+DFFF 之间，这四个字节必须放在一起解读。

什么是字节序

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

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

简单来说，字节序就是字节之间的顺序，当传输或者存储时，如果数字超过1个字节，需要指定字节间的顺序。字节序用英语说就是 byte order mark，简称BOM。

字节序问题仅存在于某种编码下计算机一次读取字符大小大于一个字节的时候。

字节序一般分为大端字节序或小端字节序，两种字节序的共同存在完全是历史原因。采用什么顺序更多的是出于数值处理上的考量。对于数值的不同操作不同的字节序性能也不同，当然如果数值大小不超过一个字节也就不需要担心什么顺序了。

大端顺序是网络协议中的主要顺序，例如在 Internet协议套件中，它被称为网络顺序，先传输最高有效字节。相反，小字节序是处理器体系结构（x86，大多数 ARM 实现，基本 RISC-V 实现）及其关联内存的主要排序方式。

文件格式则可以使用任何一种顺序：有些格式将两者混合使用。那对文件系统而言计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode 规范定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做"零宽度非换行空格"（zero width no-break space）。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大端方式；如果头两个字节是FF FE，就表示该文件采用小端方式。

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 编码了。

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

字节格式	文本内容	16 进制	占用内存大小	内存地址
UTF-8	1	31	1 byte	01
UTF-8 带 BOM	1	EF BB BF 31	4 byte	01~04

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

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

字节格式	文本内容	16 进制	占用内存大小	内存地址
UTF-8	我	E6 88 91	3 byte	01~03
UTF-8 带 BOM	我	EF BB BF E6 88 91	6 byte	01~06

中文 “我” 的 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）。

字节格式	文本内容	16 进制	占用内存大小	内存地址
UTF-16 LE	我	11 62	2 byte	01~02
UTF-16 LE 带 BOM	我	FF FE 11 62	4 byte	01~04
UTF-16 BE	我	62 11	2 byte	01~02
UTF-16 BE 带 BOM	我	FE FF 62 11	4 byte	01~04

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

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

主机字节序

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

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

举例说明：

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

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

内存地址	4000	4001	4002	4003
LE 小端	04	03	02	01
BE 大端	01	02	03	04

或则：

内存地址	LE 小端	BE 大端
4000	04	01
4001	03	02
4002	02	03
4003	01	04

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

内存地址	0x0000	0x0001	0x0002	0x0003
LE 小端	0xcd	0xab	0x34	0x12
BE 大端	0x12	0x34	0xab	0xcd

或则：

内存地址	LE 小端	BE 大端
0x0000	0xcd	0x12
0x0001	0xab	0x34
0x0002	0x34	0xab
0x0003	0x12	0xcd

基本是：

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

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

网络字节序

网络字节顺序是 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 node
console.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

JavaScript 共有 6 种方法可以表示一个字符:

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

更多 ES-6 对 Unicode 的支持细节:

ASCII 码表参考

Bin(二进制)	Oct(八进制)	Dec(十进制)	Hex(十六进制)	缩写/字符	解释
0000 0000	00	0	0x00	NUL(null)	空字符
0000 0001	01	1	0x01	SOH(start of headline)	标题开始
0000 0010	02	2	0x02	STX (start of text)	正文开始
0000 0011	03	3	0x03	ETX (end of text)	正文结束
0000 0100	04	4	0x04	EOT (end of transmission)	传输结束
0000 0101	05	5	0x05	ENQ (enquiry)	请求
0000 0110	06	6	0x06	ACK (acknowledge)	收到通知
0000 0111	07	7	0x07	BEL (bell)	响铃
0000 1000	010	8	0x08	BS (backspace)	退格
0000 1001	011	9	0x09	HT (horizontal tab)	水平制表符
0000 1010	012	10	0x0A	LF (NL line feed, new line)	换行键
0000 1011	013	11	0x0B	VT (vertical tab)	垂直制表符
0000 1100	014	12	0x0C	FF (NP form feed, new page)	换页键
0000 1101	015	13	0x0D	CR (carriage return)	回车键
0000 1110	016	14	0x0E	SO (shift out)	不用切换
0000 1111	017	15	0x0F	SI (shift in)	启用切换
0001 0000	020	16	0x10	DLE (data link escape)	数据链路转义
0001 0001	021	17	0x11	DC1 (device control 1)	设备控制1
0001 0010	022	18	0x12	DC2 (device control 2)	设备控制2
0001 0011	023	19	0x13	DC3 (device control 3)	设备控制3
0001 0100	024	20	0x14	DC4 (device control 4)	设备控制4
0001 0101	025	21	0x15	NAK (negative acknowledge)	拒绝接收
0001 0110	026	22	0x16	SYN (synchronous idle)	同步空闲
0001 0111	027	23	0x17	ETB (end of trans. block)	结束传输块
0001 1000	030	24	0x18	CAN (cancel)	取消
0001 1001	031	25	0x19	EM (end of medium)	媒介结束
0001 1010	032	26	0x1A	SUB (substitute)	代替
0001 1011	033	27	0x1B	ESC (escape)	换码(溢出)
0001 1100	034	28	0x1C	FS (file separator)	文件分隔符
0001 1101	035	29	0x1D	GS (group separator)	分组符
0001 1110	036	30	0x1E	RS (record separator)	记录分隔符
0001 1111	037	31	0x1F	US (unit separator)	单元分隔符
0010 0000	040	32	0x20	(space)	空格
0010 0001	041	33	0x21	!	叹号
0010 0010	042	34	0x22	"	双引号
0010 0011	043	35	0x23	#	井号
0010 0100	044	36	0x24	$	美元符
0010 0101	045	37	0x25	%	百分号
0010 0110	046	38	0x26	&	和号
0010 0111	047	39	0x27	'	闭单引号
0010 1000	050	40	0x28	(	开括号
0010 1001	051	41	0x29	)	闭括号
0010 1010	052	42	0x2A	*	星号
0010 1011	053	43	0x2B	+	加号
0010 1100	054	44	0x2C	,	逗号
0010 1101	055	45	0x2D	-	减号/破折号
0010 1110	056	46	0x2E	.	句号
0010 1111	057	47	0x2F	/	斜杠
0011 0000	060	48	0x30	0	字符0
0011 0001	061	49	0x31	1	字符1
0011 0010	062	50	0x32	2	字符2
0011 0011	063	51	0x33	3	字符3
0011 0100	064	52	0x34	4	字符4
0011 0101	065	53	0x35	5	字符5
0011 0110	066	54	0x36	6	字符6
0011 0111	067	55	0x37	7	字符7
0011 1000	070	56	0x38	8	字符8
0011 1001	071	57	0x39	9	字符9
0011 1010	072	58	0x3A	:	冒号
0011 1011	073	59	0x3B	;	分号
0011 1100	074	60	0x3C	<	小于
0011 1101	075	61	0x3D	=	等号
0011 1110	076	62	0x3E	>	大于
0011 1111	077	63	0x3F	?	问号
0100 0000	0100	64	0x40	@	电子邮件符号
0100 0001	0101	65	0x41	A	大写字母A
0100 0010	0102	66	0x42	B	大写字母B
0100 0011	0103	67	0x43	C	大写字母C
0100 0100	0104	68	0x44	D	大写字母D
0100 0101	0105	69	0x45	E	大写字母E
0100 0110	0106	70	0x46	F	大写字母F
0100 0111	0107	71	0x47	G	大写字母G
0100 1000	0110	72	0x48	H	大写字母H
0100 1001	0111	73	0x49	I	大写字母I
01001010	0112	74	0x4A	J	大写字母J
0100 1011	0113	75	0x4B	K	大写字母K
0100 1100	0114	76	0x4C	L	大写字母L
0100 1101	0115	77	0x4D	M	大写字母M
0100 1110	0116	78	0x4E	N	大写字母N
0100 1111	0117	79	0x4F	O	大写字母O
0101 0000	0120	80	0x50	P	大写字母P
0101 0001	0121	81	0x51	Q	大写字母Q
0101 0010	0122	82	0x52	R	大写字母R
0101 0011	0123	83	0x53	S	大写字母S
0101 0100	0124	84	0x54	T	大写字母T
0101 0101	0125	85	0x55	U	大写字母U
0101 0110	0126	86	0x56	V	大写字母V
0101 0111	0127	87	0x57	W	大写字母W
0101 1000	0130	88	0x58	X	大写字母X
0101 1001	0131	89	0x59	Y	大写字母Y
0101 1010	0132	90	0x5A	Z	大写字母Z
0101 1011	0133	91	0x5B	[	开方括号
0101 1100	0134	92	0x5C	\	反斜杠
0101 1101	0135	93	0x5D	]	闭方括号
0101 1110	0136	94	0x5E	^	脱字符
0101 1111	0137	95	0x5F	_	下划线
0110 0000	0140	96	0x60	`	开单引号
0110 0001	0141	97	0x61	a	小写字母a
0110 0010	0142	98	0x62	b	小写字母b
0110 0011	0143	99	0x63	c	小写字母c
0110 0100	0144	100	0x64	d	小写字母d
0110 0101	0145	101	0x65	e	小写字母e
0110 0110	0146	102	0x66	f	小写字母f
0110 0111	0147	103	0x67	g	小写字母g
0110 1000	0150	104	0x68	h	小写字母h
0110 1001	0151	105	0x69	i	小写字母i
0110 1010	0152	106	0x6A	j	小写字母j
0110 1011	0153	107	0x6B	k	小写字母k
0110 1100	0154	108	0x6C	l	小写字母l
0110 1101	0155	109	0x6D	m	小写字母m
0110 1110	0156	110	0x6E	n	小写字母n
0110 1111	0157	111	0x6F	o	小写字母o
0111 0000	0160	112	0x70	p	小写字母p
0111 0001	0161	113	0x71	q	小写字母q
0111 0010	0162	114	0x72	r	小写字母r
0111 0011	0163	115	0x73	s	小写字母s
0111 0100	0164	116	0x74	t	小写字母t
0111 0101	0165	117	0x75	u	小写字母u
0111 0110	0166	118	0x76	v	小写字母v
0111 0111	0167	119	0x77	w	小写字母w
0111 1000	0170	120	0x78	x	小写字母x
0111 1001	0171	121	0x79	y	小写字母y
0111 1010	0172	122	0x7A	z	小写字母z
0111 1011	0173	123	0x7B	{	开花括号
0111 1100	0174	124	0x7C	\		垂线
0111 1101	0175	125	0x7D	}	闭花括号
0111 1110	0176	126	0x7E	~	波浪号
0111 1111	0177	127	0x7F	DEL (delete)	删除

补充：

字体编辑用中日韩汉字Unicode编码表

一次搞定 Unicode、字节序、UTF-*

什么是字符集

什么是 ASCII

什么是 Unicode

什么是 UTF-32

什么是 UTF-8

什么是 UTF-16

什么是字节序

UTF 的字节序和 BOM

主机字节序

网络字节序

文件字节序

什么时候需要关心字节序

Hashbang 注释

在 JavaScript 中使用 Unicode

ASCII 码表参考

Tomson

引用和评论

二进制与 Go 的原子操作

腾讯新闻中心首页改版啦

前端如何入门 Go 语言

100个React最佳实践小技巧

前端开发工具

开发插件集合

JS校验身份证号