你知道 biangbiang 面和编码有什么关系吗？万字长文，手拉手带你一步步认识编码

最新推荐文章于 2024-10-10 14:27:15 发布

裤裆三重奏

最新推荐文章于 2024-10-10 14:27:15 发布

阅读量1.1k

点赞数

分类专栏：前端 --- http 文章标签： html5 http javascript html 前端

本文链接：https://blog.csdn.net/weixin_41917948/article/details/118521607

版权

前端 --- http 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

这篇文章是研究上传文件的时候扩展出来的知识点，因为上传文件的时候会涉及到文件的编码等内容，作为前端平时接触这些东西又比较少，我又是个不彻底搞清楚问题就不罢休的人，所以往往会因为一个小问题牵扯出来一堆问题，接着，疑问又带来新的疑问（禁止套娃！）。

写这篇文章花了很长时间，如果你看完之后有所收获，一个 Star ✨就是对我最好的鼓励。

ps: 文章不会纠结一些不太重要的信息，比如某协议是谁提出的，在什么年份提出的，这些基本上看过一次就忘了，也不重要，我会提取重要的信息来分享给大家。

前置知识

在开始之前，先整理一下我们所需要的前置知识，对于这些我们只需要有个简单的印象即可。

计算机常用的单位换算

二进制位、位、比特、bit、b，这些都是代表计算机存储的最小单位「位」，也就是二进制的 0 或 1。

1B = 8b

字节、Byte、B，这些单位也是表达的同一个意思「字节」，1 个「字节」等于 8「位」。

1kb = 1024B

kb、mb，这些大家应该就要熟悉多了，获取文件大小的时候都可以看到这些单位。

1mb = 1024kb

单位换算

前端中的进制转换

// 十六进制转十进制
parseInt(0x0f, 16);
// 十六进制转二进制
(0x0f).toString(2);

// 十进制转十六进制
(15).toString(16);
// 十进制转二进制
(15).toString(2);

// 二进制转十六进制
parseInt(1111, 2).toString(16);
// 二进制转十进制
parseInt(1111, 2);

计算机之初，杂乱无法统一的编码方案

为了方便理解，文章以 UNICODE 出现作为时间线划分，UNICODE 就是盘古开天辟地的那一斧子。

ASCII 的到来

众所周知，在计算机中，所有的数据存储和运算时都要使用二进制表示，因为计算机用高电平和低电平表示 1 和 0。然后就有这么一群人，他们决定用 8 个二进制位组成码位表示所有字符。

8 个二进制位，每个位置都可以是 0 或者 1，所以一共有 2^8 = 256 个码位，可以表示 256 个字符，这些字符又分为控制字符、通信专用字符和可显示字符。

控制字符和通信专用字符放在一起说，从 0000 0000 ~ 0001 1111，再加上 0111 1111，一共是 33 个码位，也就是有 33 个字符。比如，0000 0111，表示的意思是响铃，那时的计算机在接收到 0000 0111 的时候就会铃铃作响。

可显示字符，第 0010 0000 ~ 0111 1110，一共是 95 个，比如 0011 0000，表示的意思是 0，再比如 0100 1010，表示的是大写英文字母 J。

ASCII

因为计算机刚开始只在美国使用，那大家相安无事，用的挺好，这些字符按照规定的顺序排排坐所产生的表，就是我们在 C 语言里面学到的 ASCII 表。

ps: 现在教育太疯狂了，认识的小孩小学就在学编程，他现在就知道 ASCII 码了 0.0

ASCII 的扩展表以及 GBK 编码方案

后来，因为计算机的发展，一些西方国家开始在 ASCII 码表的后面增加自己国家的字符和制表符等字符，这就是 ASCII 扩展表，他占用了 1000 0000 ~ 1111 1111 的位置来表示自己的字符。

ps: ASCII 扩展表在不同系统配置的内码表也不同，这里就不赘述了，想要了解的同学可以参考这个文档

再后来，计算机传播的越来越远，来到了第三世界。我们发现，泱泱中华数以万计的文字，ASCII 码表是不可能放下我们的字符了，256 个位置全给我们都不够，那该怎么办？

聪明的中国人直接把 127 号码位之后的奇怪符号取消掉（也就是 ASCII 扩展表的内容），规定，一个小于 127 的字符意义与原来相同，但两个大于 127 的字符连在一起时，就表示一个汉字，前面的一个字节（高字节）从 0xa1 ~ 0xf7，后面一个字节（低字节）从 0xa1 ~ 0xfe。（这里开始文章就不用二进制来表示码位了，写起来太长，而且一堆 0 1 看着也不方便，我就把二进制转为其对应的十六进制，0x 打头就代表十六进制）

这样我们既可以保证在 ASCII 表中的英文字母不会显示乱码，另外还能组合出八千多个位置来放自己的文字、数学符号、日文假名等，而且，我们甚至把原先在 ASCII 码表里就有的标点符号，又全部编了两个字节长的字符，这就是我们常说的全角字符了，而 127 号以下的符号就称为半角字符。（「,」和「，」看出不同了吗？前者是半角字符，后者是全角字符）

后来这个方案用着还不错，我们就给它取了个名字 GB2312，前面的 GB 意思是国标。

但是我们的汉字实在太多了，八千多个位置还是不够，那我们干脆就不要求低字节是 127 号之后的了，规定只要高字节大于 127，那就代表这是 GBK 编码方案中代表的字符。这个编码方案就称为 GBK，GBK 不仅包括了 GB2312 的所有内容，还增加了好多汉字和繁体字。

再后来，少数民族也要用电脑了，要把他们的文字也加进去，于是就再进行扩展，GBK 扩成了 GB18030。

有兴趣的同学可以到这个网站查询国标对应字符的码位。

听起来是不是挺完美的？GB18030，几乎可以囊括你能见到的所有中文，但是我们这只解决了中文的编码，无法显示其他国家或者地区的文字，比如，那时候还有一个编码方案叫 Big5，普及与台湾、香港、澳门等繁体中文通行区，倚天中文系统、window 繁体中文等系统的字符集都是以 Big5 为基准。

你看，中国的内地和港澳台编码方式都不一样，那其他国家就更不用说了，结果就是，大家都闭门造车，如果需要看其他国家的文档那就得安装切换其他国家的编码方案。

UNICODE 万国码的问世

再这么混乱下去肯定不行，这时候，创建一个囊括全世界的字符的字符集就势在必行，这个时候，有两个组织开始着手统一字符集，国际标准化组织（ISO）开发的 ISO 10646 字符集，统一码联盟开发的 UNICODE 字符集。再后来，他们意识到自己应该做的是统一标准而不是重蹈覆辙，最终才有了我们在用的 UNICODE 字符集，当然 ISO 10646 字符集依然存在，并且和 UNICODE 共存，而且根据规约，他们各自的码位的字符含义都相同。

因为我们比较熟悉的是 UNICODE，所以接下来的内容我都会以 UNICODE 为主。

UNICODE 平面的含义以及码位区段说明

刚开始 UNICODE 的做法很简单，ASCII 的 1 个字节（8 位）不是不够吗，那就 2 个字节（16 位），2^16 = 65536 个码位，这总够了吧？

结果是被啪啪打脸，在被各个国家的字符蹂躏了一遍之后，不行，这得改，于是决定取 UNICODE 中的两段区域 0xd800 ~ 0xdbff（高代理位）和 0xdc00 ~ 0xdfff（低代理位），用他们来组成新的码位。这两段代理位都有 1024 个码位，那就是增加了 1024^2 = 1048576 个码位，再加上原先的 2^16 = 65536 个码位，所以按道理来说，UNICODE 一共有 1048576 + 65536 = 1114112 个码位。

现在我们有正常 2 个字节的码位，还有高代理位和低代理位组成的 4 个字节的码位，我们该怎么区分他们呢？这个时候，我们需要引入平面的概念，把这些平面划分到不同平面，2 个字节的是 BMP 平面，4 个字节的是辅助平面。

第 0 平面称为 BMP 其范围为 0x0000 ~ 0xffff。
第 1 辅助平面称为 SMP 又称为多文种补充平面，其范围为 0x10000 ~ 0x1ffff。
第 2 辅助平面称为 SIP，又称为表意文字补充平面，其范围为 0x20000 ~ 0x2ffff。
第 3 辅助平面称为 TIP，又称为表意文字第三平面，其范围为 0x30000 ~ 0x3ffff。
第 4 至 13 辅助平面尚未使用。
第 14 辅助平面称为 SSP，又称为特殊用途补充平面，其范围为 0xe0000 ~ 0xeffff。
第 15 辅助平面，其范围为 0xf0000 ~ 0xfffff。
第 16 辅助平面，其范围为 0x100000 ~ 0x10ffff。

平面其实可以理解成把相同长度的码位区段取了不同名字。我们常用的字符都在 BMP 平面，看下图，从 0x0000 ~ 0xffff 一共有 65536 个码位，其中高代理位和低代理位组合成了辅助平面。

BMP

另外，有兴趣的同学可以到这个网站上查看 UNICODE 所有的字符。

等等！高代理位和低代理位的操作是不是很熟悉？看文章仔细的同学应该马上就反应过来了，对，没错，就像当初我们针对 ASCII 而提出的 GBK，我们用 127 号以后的 ASCII 码组合出几万个码位给汉字用，UNICODE 也是一样，取了两段代理位组合成了辅助平面，那为什么 UNICODE 有几百万个码位，而我们提出的 GBK 只有几万个码位，那是因为 ASCII 只有 1 个字节，UNICODE 有 2 个字节，仅此而已。

那我们有了 UNICODE 字符集之后，所有问题就都解决了吗？其实并没有，当时的情况是，由于 UNICODE 一开始就没有打算去兼容之前任何字符集，所以 UNICODE 的推广之路并不平坦。

这时候还有细心的同学可能会问了，你上面的图画的，UNICODE 不是把 ASCII 前一半的字符拿去了吗？而且每个码位对应的字符都一样，为啥就不兼容了？

这个同学就看的更细心了，但是 ASCII 是 1 个字节，而 UNICODE 的 BMP 平面是 2 个字节，同样表达英文字母 A，ASCII 是 01000001，而 UNICODE 是 00000000 01000001，前面多了一堆无用的 0。所以，UNICODE 推广受阻还有一个原因就是，存储相同内容的英文文档，空间占用会翻倍，更别说其他文字了。

UNICODE vs ASCII

解决兼容和空间问题，聪明的 UTF-8

这个时候，为了兼容 ASCII，UTF-8 就出现了，他是 UNICODE 的编码方案。在实现上他不仅可以兼容 ASCII，并且由于它是可变长编码方案，对于纯英文的文档，可以使空间使用减半。

但是对于中文文档，相对于 GBK 编码方案还是导致空间增加了，因为原先我们 GBK 用 2 个字节组合出了几万个码位，但在 UTF-8 中，即使是 BMP 平面的汉字，那也需要 3 个字节。为什么？我们直接看下面的例子，对于”裤裆“的”裤“字，UTF-8 是如何编码的。

首先这里有一个表格，是 UTF-8 的替换模板，模板也是有规律的，如果开头是 0，那就占用一个字节，如果开头是 1，那连续几个 1 就表示有几个字节。

十六进制范围	UTF-8 模板
0x0000 ~ 0x007f	0xxxxxxx
0x0080 ~ 0x07ff	110xxxxx 10xxxxxx
0x0800 ~ 0xffff	1110xxxx 10xxxxxx 10xxxxxx
0x10000 ~ 0x10ffff	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

细心的同学可能又要问了（你就不能换个方式引题！？），看最后一个模板，如果 x 位置全是 1 的话，明明就大于 0x10ffff，为什么范围限制在了 0x10ffff？这就是代理位所带来的问题了，因为 UNICODE 一开始设定 2 个字节表示字符失策，后来用了代理位做补救，但这就导致码位的个数被限制在了 0x10ffff，即使 UTF-8 的设计可以表达、容纳更多的字符。

// 获取”裤“的 UNICODE 码位
const code = "裤".charCodeAt(); // 35044
// 获取 35044 的十六进制表示
// 查表可得 0x88e4 位于上表的第 3 行
const hex = code.toString(16); // 0x88e4
// 获取 35044 的二进制表示
const binary = code.toString(2); // 1000 1000 1110 0100

//          10001000 11100100   |   ”裤“的二进制序列
//     1000   100011   100100   |   ”裤“的二进制排序后
// 1110xxxx 10xxxxxx 10xxxxxx   |   模板中的第三行
// --------------------------   |   从低位到高位带入模板
// 11101000 10100011 10100100   |   获得编码后的二进制序列
//       e8       a3       a4   |   二进制序列转为十六进制

// 最终得到 e8 a3 a4 的编码结果

// 通过 node Buffer 来验证
const buffer = new Buffer.from("裤", "utf-8"); // <Buffer e8 a3 a4>

UTF-8

如上我们可以看到，汉字在经过 UTF-8 编码后，变成了 3 个字节，而 GBK 我们使用 2 个字节就可以表示。所以，如果你的网站或者文档只需要在国内传输的，使用 GBK 未尝不可？可以减少不少文档大小。

另外，我们也写一下英文字母经过 UTF-8 编码后会获取到多少字符。

// 获取 A 的 UNICODE 码位
const code = "A".charCodeAt(); // 65
// 获取 65 的十六进制表示，0x41 位于上表的第 1 行
const hex = code.toString(16); // 0x41
// 获取 65 的二进制表示
const binary = code.toString(2); // 1000001

//  1000001   |   A 的二进制序列
// 0xxxxxxx   |   模板中的第一行
// --------   |   从低位到高位带入模板
// 01000001   |   获得二进制序列
//       41   |   二进制序列转为十六进制

// 最终得到 41 的编码结果

// 通过 node Buffer 来验证
const buffer = new Buffer.from("A", "utf-8"); // <Buffer 41>

可见，对于英文字母来说，00000000 01000001 变成了 01000001，所占空间减少了一半。

UTF-16 编码方案

说完了 UTF-8，我们来说说 UTF-16 和 UCS-2，后面还有 UTF-32 和 UCS-4。另外，上面我们不是提到了 ISO 组织么？UCS 就是该组织提出的编码方案，UCS-2 可以说就是 UTF-16 的前身。

虽然看着 UTF-16 和 UTF-8 是 double 的样子，但其实并不。

首先，对于 BMP 面的字符，UTF-16 就直接用 2 个字节来表示，包括英文字母。

另外，我们刚才不是提到代理位和代理位组合而成的辅助平面么？忘了的同学可以翻上去看看，其实代理位就是专门用于 UTF-16 的，对于辅助平面的字符，UTF-16 就用 4 个字节来表示，也就是高代理位和低代理位组合表示。

看了这么久文章，同学们该饿了吧，我们说点好吃的，陕西的特产，biangbiang 面。

biangbiang 面

这个 biang 字，如下图。

biang 字

biang 在 UNICODE 的码位为 0x30ede，你可以打开这个网站，搜索 0x30ede 来查看 biang 字收录在 UNICODE 字符集的位置。虽然这个字在浏览器中还不能够打出来，但是我们可以用这个字做引子，来说说 UTF-16 的编码该如何实现。

biangCharCodeHex = "0x30ede";
// 从 200414 这个码位就可以看出来，biang 字不在 BMP 平面
// 因为 BMP 平面只有 65536 个码位
parseInt("0x30ede"); // 200414

// 接下来演示 UTF-16 编码过程

// 先获取 200414 的二进制表示
(200414).toString(2); // 11 0000 1110 1101 1110

//            11 0000 1110 1101 1110   |   码位对应的二进制
//             1 0000 0000 0000 0000   |   减去 0x10000
//            10 0000 1110 1101 1110   |   得到的二进制
//          0010 0000 1110 1101 1110   |   把得到的二进制前补 0，补充到 20 位
//       0010000011       1011011110   |   整理一下，10 位一隔，方便阅读
// 1101100000000000 1101110000000000   |   左边是 0xd800，右边是 0xdc00
// ---------------------------------   |   还记得高代理位和低代理位的区间么？
//                                     |   高代理位从 0xd800 ~ 0xdbff，我们取 0xd800
//                                     |   低代理位从 0xdc00 ~ 0xdfff，我们取 0xdc00
// 1101100010000011 1101111011011110   |   直接把 10 位分别取代代理位后面的 0，从后面开始取代
//             d883             dede   |   把上述二进制转为 16 进制，最终获取到 UTF-16 编码

// 通过 node Buffer 来验证
// 因为 node 只支持 UTF-16 小端序
// http://nodejs.cn/api/buffer.html#buffer_buffers_and_character_encodings
// 所以表示为 dede 83d8，注意，这是从右往左读的
// 另外 "\u{30ede}" 这是个 ES6 用来表示辅助平面的字符的方法
const buffer = new Buffer.from("\u{30ede}", "utf16le"); // <Buffer 83 d8 de de>

UTF-16

以上，我们就完成了 UTF-16 编码，另外 UNICODE@3.0 也给出了辅助平面字符的转换公式

High = Math.floor((charCode - 0x10000) / 0x400) + 0xd800;
Low = ((charCode - 0x10000) % 0x400) + 0xdc00;

// 我们把刚才 biang 的码位代入试试
High = (Math.floor((0x30ede - 0x10000) / 0x400) + 0xd800).toString(16); // d883
Low = (((0x30ede - 0x10000) % 0x400) + 0xdc00).toString(16); // dede

在上面的例子里我们也看到了，UTF-16 还存在大端序和小端序，也就是字节序（BOM）的问题，其实就是我们得告诉程序，这段编码该从左开始读还是从右开始读。

举个例子，“奠”的编码结果是 5960，“恙”的编码结果是 6059，如果没有表明读取的方向，显示的结果就会有问题。

所以，UTF-16 还有两个分支，UTF-16BE（大端序）和 UTF-16LE（小端序）。并且对于用 UTF-16 编码的文件，会在文件头部增加一个代表字节序的标识，UTF-16BE 放的是 0xfeff，UTF-16LE 放的是 0xfffe，所以你会发现用 UTF-16 保存的文件，所占用空间会多 2 个字节。

我们知道了 UTF-16 可以用高低代理位组合成新的码位，UCS-2 和 UTF-16 的区别就在此，UCS-2 也是用 2 个字节表示 BMP 平面的字符，但是它不能表示辅助平面，并且，由于 ISO 要保证和 UNICODE 保持一致，所以 UCS-2 的 0xd800 ~ 0xdbff 和 0xdc00 ~ 0xdfff 码位的字符是空的，你可以把 UCS-2 理解成是 UTF-16 的子集。

UTF-32 编码方案

接下来我们更快的来过一下 UTF-32 和 UCS-4，他俩都是直接对每个字符都使用 4 个字节，并且刚开始 UCS-4 提出来时，4 个字节，一共 32 个位，但是在计算机中我们一般会把最高位当做符号位（这里是否如此，存疑），那 UCS-2 就有 2^31 = 2147483648 个码位，但是因为 UCS-4 要符合 UNICODE 的标准，码位只能用到 0x10ffff，所以 UTF-32 就被提出来了，他只用来表示 0x000000 ~ 0x10ffff 的码位。

到这里，有没有发现代理位的坑？明明 UTF-8 和 UTF-32 可以表示更多的字符，但是因为用了代理位，UNICODE 的字符个数上限就被制裁到了 0x10ffff，虽然我们现在还有大量的码位没有被使用，UNICODE 被称为万国码，但如果以后如果有了宇宙码呢，那是不是要重启一套编码，或者被迫使用脑电波传输？（狗头

字符集和编码方案的阶段总结

至此，字符集和编码方案就先告一段落，我们来做一个总结

刚开始由美国提出了 ASCII 码表，并且这也是早期计算机的编码方案，规定 8 个位为 1 个字节，一共有 2^8 = 256 个码位。
后来计算机传到了其他国家，所以又出了 ASCII 扩展表，把 127 位之后的码位占满了。
再后来，计算机传到了中国，我们通过特定的规则，将两个 ASCII 码组合，得到了中国汉字编码，当时流行的编码方案有 GB2312、GBK、GB18030、Big5 等。
最后，国际标准化组织终止了各国创造各自编码方案的行为，打造了 UNICODE，试图将全世界的字符都收纳其中。
UNICODE 在提出之初直接规定使用 2 个字节表达所有字符，并没有考虑兼容任何编码方案，包括 ASCII，所以推广十分艰难，直到 UTF-8 编码方案的问世。
UNICODE 的码位一共有 0x10ffff 个，这些码位被分为 17 个平面，我们常用的是 BMP 平面。
UNICODE 的 BMP 平面前 127 个码位内容直接照搬 ASCII，并将 0xd800 ~ 0xdbff 和 0xdc00 ~ 0xdfff 规定为高低代理位，他俩组合生成辅助平面所需码位。
UTF-8 是可变长的编码方案，编码结果是 1 ~ 4 个字节，既保证了英文字符的编码结果和 ASCII 初版字符集保持一致，又可以通过特定规则，编码所有的 UNICODE 码位。
UTF-16 也是可变长编码方案，编码结果是 2 或者 4 个字节，BMP 平面的字符用 2 个字节表示，辅助平面用高低代理位组合计算后的 4 个字节表示。并且由于没有 UTF-8 的特殊规则，所以存在大小端字节序的问题。
UCS-2 是 UTF-16 的前身，编码结果是 2 个字节，不支持辅助平面的字符表示。编码空间为 0x0000 ~ 0xffff。
UTF-32 是定长编码方案，编码结果是固定的 4 个字节，和 UTF-16 一样，也存在字节序的问题。
UCS-4 是 UTF-32 的前身，编码结果是固定的 4 个字节。编码空间为 0x00000000 ~ 0x7fffffff。
UTF 系列编码方案的编码空间都为 0x000000 ~ 0x10ffff。