ASCII使用7位来表示字符。通过使用7位，我们最多可以有2 ^ 7（= 128）个不同的组合*。这意味着我们最多可以表示128个字符。等一下7位 但是为什么不使用1个字节（8位）呢？最后一位（第8位）用作奇偶校验位以避免错误。这与多年前有关。ASCII扩展一些聪明的人开始使用第8位（用于奇偶校验的位）来编码更多字符以支持其语言（例如，以法语支持“é”）。只需使用一个额外的位，就可以将原始ASCII表的大小增加一倍，以映射最多256个字符（2 ^ 8 = 256个字符）。而不是像以前一样2 ^ 7（128）。10000010 -> é (e with acute accent - 130)10100000 -> á (a with acute accent - 160)该“ ASCII扩展到8位而不是以前的7位”的名称可以简称为“扩展ASCII”或“ 8位ASCII”。
ascii 有 128个字符 ascii扩展有 256个字符
最初的unicode编码是固定长度的，16位，也就是2两个字节代表一个字符，这样一共可以表示65536个字符。显然，这样要表示各种语言中所有的字符是远远不够的。Unicode4.0规范考虑到了这种情况，定义了一组附加字符编码，附加字符编码采用2个16位来表示，这样最多可以定义1048576个附加字符，目前unicode4.0只定义了45960个附加字符。
Unicode只是一个编码规范，目前实际实现的unicode编码只要有三种：UTF-8,UCS-2和UTF-16，三种unicode字符集之间可以按照规范进行转换。
一、概念：
本质上来说：
Unicode 是「字符集」 UTF-8 是「编码规则」
字符集： 为每一个「字符」分配一个唯一的 ID（学名为码位 / 码点 / Code Point）；
编码规则： 将「码位」转换为字节序列的规则（编码/解码 可以理解为 加密/解密 的过程）
二、案例：
每一个字符对应一个十六进制数字。
计算机只懂二进制，因此，严格按照unicode的方式(UCS-2)，应该这样存储：
I 00000000 01001001
t 00000000 01110100
’ 00000000 00100111
s 00000000 01110011
00000000 00100000
知 01110111 11100101
乎 01001110 01001110
日 01100101 11100101
报 01100010 10100101
上面 8 个字符串总共占用了18个字节，但是对比中英文的二进制码，可以发现，英文前9位都是0！浪费啊，浪费硬，浪费流量。英文出现的频率明显比中文高的！
UTF-8是这样做的：
单字节的字符，字节的第一位设为0，对于英语文本，UTF-8码只占用一个字节，和ASCII码完全相同；
n个字节的字符(n>1)，第一个字节的前n位设为1，第n+1位设为0，后面字节的前两位都设为10，这n个字节的其余空位填充该字符unicode码，高位用0补足。
这样就形成了如下的UTF-8标记位：
0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
… …
于是，”It’s 知乎日报“就变成了：
I 01001001
t 01110100
’ 00100111
s 01110011
00100000
知 11100111 10011111 10100101
乎 11100100 10111001 10001110
日 11100110 10010111 10100101
报 11100110 10001010 10100101
和上边的方案对比一下，英文短了，每个中文字符却多用了一个字节。但是整个字符串只用了17个字节，比上边的18个短了一点点。
python是支持Unicode的，在使用Unicode时，在字符串前加上u即可。
要看懂从unicode 二进制 变为 utf-8二进制，需要了解如下规则
UTF-8 是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
编码规则：
对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。
对于n字节的符号（n > 1），第一个字节的前n位都设为1，第n + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。
例如 utf8中，中文占3个字节，即第一个字节的前3位都设为1，第3 + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。
如下：
如上规则推算unicode 的 知 【0111】【0111】 【1110】【0101】 转换为 utf8 知的二进制同理
- 中文在utf8 是3个字节，所以 第1个字节的前3位为 111，第3+1位为0，得到 1110
- 后面还有2个字节，前两位一律为10 。即 1110xxxx 10xxxxxx 10xxxxxx
- 将unicode的二进制，补上xxx的部分就得到 1110【0111】 10【0111】【11】 10【10】【0101】
三、前因后果
ASCII码：是用一个字节（8bit， 0-255）中的127个字母表示大小写字母，数字和一些符号.主要用来表示现代英语和西欧语言。
所以处理中文就出现问题了，因为中文处理至少需要两个字节,所以中国制定了GB2312。
所以，各国制定了各国的标准。日本制定了Shift_JIS，韩国制定了Euc-kr。。。那么，乱码就来了。
为了统一，Unicode诞生了。统一码把所有语言都统一到一套编码里。解决了乱码问题，但是存储和传输效率低下的问题又来了。
因为ASCII编码是1个字节，而Unicode编码通常是2个字节。你表示一个英文字母一个字节就够了，但是Unicode却不得不用两个字节来表示（另一个字节补0）。
ASCII 是 Unicode 编码方案的一个子集
四、btoa和atob
btoa和atob是window对象的两个函数，其中btoa是binary to ASCII，用于将binary的数据用ASCII码表示，即Base64的编码过程，而atob则是ASCII to binary，用于将ASCII码解析成binary数据，即Base64的解码过程。
注意，atob输出的binary数据并不是二进制的 01 11 这种数据，而是一个叫binary集对应的数据，是字符形式。
atob:
使用atob()对base64数据进行解码 结果是一个文件数据流 以字符串的格式输出
如果传入字符串不是有效的 base64 字符串，比如其长度不是 4 的倍数，则抛出DOMException。
那为啥在浏览器中debugger显示为对应的unicode编码集的显示？
因为谷歌器默认编码为utf-8，浏览器是直接显示这种binary集数据会乱码，所以对应二进制编码的base64字符串使用window.atob()后在浏览器中debugger显示为对应的unicode编码集的显示，如下图：
这里每个/u开头的都是一个Unicode码的字符，如\u0000是一个Unicode码的字符，每一个’\u0000’都代表了一个空格。
binary是什么？
binary 是JS字符集的另外一个子集，它类似于 ASCII 字符集，但是字符的码点(charCode)不再限制到 127， 它包含了255 以内的字符。binary string设计的目的不是用于代表字符， 而是代表二进制数据。由 binary string 代表的二进制数据大小是原始数据的两倍，然而这对于最终用户是不可见的， 因为JavaScript strings 的长度是以2字节为单位进行计算的。比如， “Hello world” 这个字符串属于 ASCII 子集, 而 ÀÈÌÒÙ 不属于ASCII码[2]，但属于binary。
五、Base64编码过程
Base64，就是包括小写字母a-z、大写字母A-Z、数字0-9、符号"+“、”/"一共64个字符的字符集，（任何符号都可以转换成这个字符集中的字符，这个转换过程就叫做base64编码。 [2]
Base64编码是从二进制到字符的过程，可用于在HTTP环境下传递较长的标识信息。采用Base64编码具有不可读性，需要解码后才能阅读。
Base64要求把每三个8Bit的字节转换为四个6Bit的字节（38 = 46 = 24），然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3。
转换前 10101101,10111010,01110110
转换后 00101011, 00011011 ,00101001 ,00110110
十进制 43 27 41 54
对应码表中的值 r b p 2
Table : The Base64 Alphabet
| 索引 | 对应字符 | 索引 | 对应字符 | 索引 | 对应字符 | 索引 | 对应字符 |
|---|---|---|---|---|---|---|---|
| 0 | A | 17 | R | 34 | i | 51 | z |
| 1 | B | 18 | S | 35 | j | 52 | 0 |
| 2 | C | 19 | T | 36 | k | 53 | 1 |
| 3 | D | 20 | U | 37 | l | 54 | 2 |
| 4 | E | 21 | V | 38 | m | 55 | 3 |
| 5 | F | 22 | W | 39 | n | 56 | 4 |
| 6 | G | 23 | X | 40 | o | 57 | 5 |
| 7 | H | 24 | Y | 41 | p | 58 | 6 |
| 8 | I | 25 | Z | 42 | q | 59 | 7 |
| 9 | J | 26 | a | 43 | r | 60 | 8 |
| 10 | K | 27 | b | 44 | s | 61 | 9 |
| 11 | L | 28 | c | 45 | t | 62 | + |
| 12 | M | 29 | d | 46 | u | 63 | / |
| 13 | N | 30 | e | 47 | v | ||
| 14 | O | 31 | f | 48 | w | ||
| 15 | P | 32 | g | 49 | x | ||
| 16 | Q | 33 | h | 50 | y |
所以上面的24位编码，编码后的Base64值为 rbp2。
编码过程?
第一个字节，根据源字节的第一个字节处理。
规则：源第一字节右移两位，去掉低2位，高2位补零。
既：00 + 高6位
第二个字节，根据源字节的第一个字节和第二个字节联合处理。
规则如下，第一个字节高6位去掉然后左移四位，第二个字节右移四位
即：源第一字节低2位 + 源第2字节高4位
第三个字节，根据源字节的第二个字节和第三个字节联合处理，
规则第二个字节去掉高4位并左移两位（得高6位），第三个字节右移6位并去掉高6位（得低2位），相加即可
第四个字节，规则，源第三字节去掉高2位即可。
用更接近于编程的思维来说，编码的过程是这样的：
第一个字符通过右移2位获得第一个目标字符的Base64表位置，根据这个数值取到表上相应的字符，就是第一//个目标字符。
然后将第一个字符与0x03(00000011)进行与(&)操作并左移4位,接着第二个字符右移4位与前者相或(|)，即获得第二个目标字符。
再将第二个字符与0x0f(00001111)进行与(&)操作并左移2位,接着第三个字符右移6位与前者相或(|)，获得第三个目标字符。
最后将第三个字符与0x3f(00111111)进行与(&)操作即获得第四个目标字符。
在以上的每一个步骤之后，再把结果与 0x3F 进行 AND 位操作，就可以得到编码后的字符了。
原文的字节数量应该是3的倍数，如果这个条件不能满足的话，具体的解决办法是这样的：原文剩余的字节根据编码规则继续单独转(1变2，2变3；不够的位数用0补全)，再用=号补满4个字节。这就是为什么有些Base64编码会以一个或两个等号结束的原因，但等号最多只有两个。因为一个原字节至少会变成两个目标字节，所以余数任何情况下都只可能是0，1，2这三个数中的一个。如果余数是0的话，就表示原文字节数正好是3的倍数（最理想的情况）。如果是1的话，转成2个Base64编码字符，为了让Base64编码是4的倍数，就要补2个等号；同理，如果是2的话，就要补1个等号。
解码同理
解码同理，把 rbq2 的二进制位连接上再重组得到三个8位值，得出原码。
（解码只是编码的逆过程，有关MIME的RFC还有很多，如果需要详细情况请自行查找。）
六、结论：
unicode是静态的，而且是固定长度的，一一对应；unicode-8是一套规则，字长是可变的，即对应的字符结果是可变的。
为了节约，出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间（ASCII码可以看成是UTF-8的一部分，所以大量只支持ASCII编码的历史遗留软件可以在UTF-8编码下继续工作）。
说到编码，得先从ASCII编码讲起。ASCII编码是由美国人发明，美国的字符不超过255个，所以ASCII编码使用了8bit 即一个字节来存储字符。由于汉字的数量远超255个，所以中国自己发明了一个GB2312编码来表示汉字，一般的汉字使用2个字节，对于一些生僻的汉字则使用更多的字节来表示，当然，GB2313编码是可以兼容ASCII码的。
然后，日本，韩国等等国家也自己发明了一套编码方法，这时候又出现了一个新的问题。如果一篇文章里面，即有中文，又有日文的话，无论使用中文的编码方法还是使用日文的编码方法都会出现乱码。随后，unicode编码便应运而生。unicode编码对文字的编码进行了统一，当然，unicode只是一种编码规范，它有多个版本，常用的unicode编码使用了16位来存储字符，16位的存储空间足以容纳世界上所有书面字符（对于汉字来说，一共有6万多个，只能包含其中的一些常用汉字，所以unicode编码对于汉字的兼容性并不是特别好）。unicode编码兼容了ASCII码，ASCII码转unicode编码时，保持后8位不变，前8位只需要用0去补全即可。
使用了unicode编码后，又有新的问题出现。因为unicode编码是用两个字节来存储字符，如果一篇文章中，大部分都是英文，使用unicode编码就会造成空间的浪费，对英文部分使用ASCII码只需要一个字节就可以了。这时候，utf-8解决了这个问题。utf-8是一种可变长的字符编码，当存储英文时只使用一个字节，节省了一半的空间，而存储中文字符时，长度还是不变。utf-8虽然压缩了存储空间，但是如果在内存中存储，使用utf-8却由于它的长度不固定，带来了很大的不便，使得在内存处理字符变得复杂。应对这个问题的解决策略是：在内存中存储字符时还是使用unicode编码，因为unicode编码的长度固定，处理起来很方便。而在文件的存储中，则使用utf-8编码，可以压缩内存，节省空间。这里一般有个自动转换的机制，即从文件中读取utf-8编码到内存时，会自动转换为unicode编码，而从内存中将字符保存到文件时，则自动转换为utf-8编码。
623
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
