一直对这个都十分困扰，今天重新看了看
ASCII、Unicode、UTF-8
ASCII 是美国制定的一套字符编码，对英语字符与二进制位之间的关系，做了统一的规定。
ASCII 码一共规定了 128 个字符的编码，比如空格 SPACE 是 32（二进制00100000），大写的字母 A 是 65（二进制01000001）。这 128 个符号（包括 32 个不能打印出来的控制符号），只占用了一个字节的后面 7 位，最前面的一位统一规定为 0。
英语用 128 个符号编码就够了，但对于其他语言来说是不够。比如汉子多达 10 万左右，一个字节只能表示 256 中符号，肯定是不够的，就必须使用多个字节表达一个符号。比如简体中文常见的编码方式是 GB2312，使用两个字节表示一个汉子，所以理论上最多可以表示 256*256 = 65536 个符号。
由于世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。
如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是 Unicode，就像它的名字都表示的，这是一种所有符号的编码。
Unicode 只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储
汉字 严 的 Unicode 是十六进制数 4E25，转换成二进制数足足有 15 位（100111000100101），也就是说，这个符号的表示至少需要 2 个字节。表示其他更大的符号，可能需要 3 个字节或者 4 个字节，甚至更多。
Unicode 存在的问题
- 如何才能区别 Unicode 和 ASCII ？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？
- 我们已经知道，英文字母只用一个字节表示就够了，如果 Unicode 统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是 0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。
造成的结果就是出现了 Unicode 的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示 Unicode。Unicode 在很长一段时间内无法推广，直到互联网的出现。
互联网的普及，强烈要求出现一种统一的编码方式。UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式。
UTF-8 是 Unicode 的实现方式之一。
UTF-8 最大的一个特点，就是它是一种变长的编码方式。它可以使用 1~4 个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8 编码规则
- 对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。
- 对于 n 字节的符号（n > 1），第一个字节的前 n 位都设为 1，第 n + 1 位设为 0，后面字节的前两位一律设为 10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。
解读 UTF-8 编码非常简单。如果一个字节的第一位是0，则这个字节单独就是一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。
为什么需要
三者的基本功能都是把 URI 非法字符转化成合法字符。
在处理 0xff 以内字符时，编码方式是一样的（都是「%XX」，XX为字符的 16 进制 unicode，同时也是字符的 UTF-8），只是范围（即哪些字符编码哪些字符不编码）不一样。
在处理 0xff 之外字符的时候，escape 和 encodeURI 有区别
- escape：在处理 0xff 之外字符的时候，直接使用字符的 unicode 在前面加上
%u - encodeURI：在处理 0xff 之外字符的时候，则是先进行 UTF-8，再在 UTF-8 的每个字节码前加上
%
而 encodeURI 和 encodeURIComponent 的区别在于需要转义的字符范围不一样。
为什么 URI 需要编码，主要原因是 URI 有规范。比如 = 和 & 符号，服务端认定这些字符为分隔符，从而得到参数 K-V 键值对，但是如果参数值中本身就包含 = 或 & 等特殊字符，就会导致解析出错。举个例子
比如说“name1=value1”,其中 value1 的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。我们的本意是就只有一个键值对，但是服务端会解析成两个键值对，这样就产生了奇异。
解决的办法就是对参数进行 URL 编码，URL 编码只是简单的在特殊字符的各个字节前加上 %，例如，我们对上述会产生奇异的字符进行 URL 编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在 % 后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。
使用场景
首先 escape 已经被废弃，使用 encodeURI 和 encodeComponent 替代。所以请直接忘记它吧
encodeURI 设计用来编码整个 URL 字符串，于是 URL 中的功能字符，比如 &, ?, /, = 等等这些并不会被转义。
encodeURIComponent 设计来对一个 URL 中的值进行转义，会把这些功能字符也进行转义。
encodeURIComponent 的编码范围比 encodeURI 要大，这也是为什么不能用来编码整个 URL 的原因。
const arr = Array(256)
.fill(0)
.map((_, i) => String.fromCharCode(i))
.filter(c => encodeURI(c) != encodeURIComponent(c));
arr.forEach(c => console.log(c, encodeURI(c), encodeURIComponent(c)));
如果使用 encodeURIComponent 编码整个 URI 会导致 URI 不能被浏览器正常访问，最典型的就是连 "/" 都被编码了
打印结果为
# # %23
$ $ %24
& & %26
+ + %2B
, , %2C
/ / %2F
: : %3A
; ; %3B
= = %3D
? ? %3F