带你走进字符编码的世界

时间 2019-11-10

原文原文链接

思考一下，为何有字符编码这种东西？html

固然是为了让计算机“听话”呗。咱们知道，计算机的世界只有01这两个字符，而咱们现实世界有成千上万的字符。如何用01的组合去和现实中的字符一一对应呢？这就是须要制定相应的编码规则来实现了。明白了这点，咱们正式开始编码的讲解。前端

ASCII码

咱们知道，在计算机内部，全部的信息最终都表示为一个二进制的字符串。每个二进制位（bit）有0和1两种状态，所以八个二进制位就能够组合出256种状态（-128~127），这被称为一个字节（byte）。也就是说，一个字节一共能够用来表示256种不一样的状态，每个状态对应一个符号，就是256个符号，从0000000到11111111。segmentfault

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，作了统一规定。这被称为ASCII码，一直沿用至今。数组

ASCII码一共规定了128个字符的编码，好比空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。浏览器

ASCII码用了1个字节，1个字节能够表示256种状态，但ASCII码只用了128种，也就是一个字节的后七位，最前面的1位都是0。安全

非ASCII编码

英语用128个符号编码就够了，可是用来表示其余语言，128个符号是不够的。好比，在法语中，字母上方有注音符号，它就没法用ASCII码表示。因而，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。好比，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，能够表示最多256个符号。服务器

可是，这里又出现了新的问题。不一样的国家有不一样的字母，所以，哪怕它们都使用256个符号的编码方式，表明的字母却不同。好比，130在法语编码中表明了é，在希伯来语编码中却表明了字母Gimel (ג)，在俄语编码中又会表明另外一个符号。可是无论怎样，全部这些编码方式中，0—127表示的符号是同样的，不同的只是128—255的这一段。网络

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，确定是不够的，就必须使用多个字节表达一个符号。好比，简体中文常见的编码方式是GB2312，使用两个字节表示一个汉字，因此理论上最多能够表示256x256=65536个符号。
中文编码的问题须要专文讨论，这篇笔记不涉及。这里只指出，虽然都是用多个字节表示一个符号，可是GB类的汉字编码与后文的Unicode和UTF-8是毫无关系的。app

Unicode编码

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字能够被解释成不一样的符号。所以，要想打开一个文本文件，就必须知道它的编码方式，不然用错误的编码方式解读，就会出现乱码。为何电子邮件经常出现乱码？就是由于发信人和收信人使用的编码方式不同。ide

能够想象，若是有一种编码，将世界上全部的符号都归入其中。每个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种全部符号的编码。

Unicode（统一码、万国码、单一码）是计算机科学领域里的一项业界标准，包括字符集、编码方案等。Unicode 是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每一个字符设定了统一而且惟一的二进制编码，以知足跨语言、跨平台进行文本转换、处理的要求。

Unicode是国际组织制定的能够容纳世界上全部文字和符号的字符编码方案。目前的Unicode字符分为17组编排，0x0000 至 0x10FFFF，每组称为平面（Plane），而每平面拥有65536个码位，共1114112个。然而目前只用了少数平面。UTF-八、UTF-1六、UTF-32都是将数字转换到程序数据的编码方案。

Unicode固然是一个很大的集合，如今的规模能够容纳100多万个符号。每一个符号的编码都不同，好比，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，能够查询unicode.org，或者专门的汉字对应表。

Unicode的问题

须要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。好比，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少须要2个字节。表示其余更大的符号，可能须要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题：1. 如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？2. 咱们已经知道，英文字母只用一个字节表示就够了，若是unicode统一规定，每一个符号用三个或四个字节表示，那么每一个英文字母前都必然有二到三个字节是0，这对于存储来讲是极大的浪费，文本文件的大小会所以大出二三倍，这是没法接受的。

它们形成的结果是：

出现了unicode的多种存储方式，也就是说有许多种不一样的二进制格式，能够用来表示unicode。
unicode在很长一段时间内没法推广，直到互联网的出现。

UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其余实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，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码。

下表总结了编码规则，字母x表示可用编码的位。

下面，仍是以汉字“严”为例，演示如何实现UTF-8编码。

已知“严”的unicode是4E25（100111000100101），根据上表，能够发现4E25处在第三行的范围内（0000 0800-0000 FFFF），所以“严”的UTF-8编码须要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。而后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就获得了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

那unicode和UTF-8有何区别？
Unicode 是「字符集」
UTF-8 是「编码规则」

字符集：为每个「字符」分配一个惟一的 ID（学名为码位 / 码点 / Code Point）
编码规则：将「码点」转换为字节序列的规则

参考：字符编码笔记：ASCII、Unicode、UTF-8 和 Base64

BCD码

上面讲的是字符编码，是指一个字符对应的一个二进制数。而BCD码是计算机在对十进制数作运算或存储时采用的二进制格式。

Binary-Coded Decimal‎，简称BCD，称BCD码或二-十进制代码，亦称二进码十进数。是一种二进制的数字编码形式，用二进制编码的十进制代码。这种编码形式利用了四个位元来储存一个十进制的数码，使二进制和十进制之间的转换得以快捷的进行。

BCD码的优势是效率高：好比十进制要以二进制的形式在计算机中存储，十进制直接转换成与之对应的BCD码比十进制经过除法取余再转换的效率来的高。

Base64编码

什么是base64？
Base64是网络上最多见的用于传输8Bit字节码的编码方式之一，Base64就是一种基于64个可打印字符来表示二进制数据的方法。

为何会有base64？
因为HTTP协议是文本协议，因此在HTTP协议下传输二进制数据须要将二进制数据转换为字符数据。然而直接转换是不行的。由于网络传输只能传输可打印字符。

问：什么是“可打印字符”呢？
答：在ASCII码中规定，0~3一、128这33个字符属于控制字符，32~127这95个字符属于可打印字符，也就是说网络传输只能传输这95个字符，不在这个范围内的字符没法传输。

问：那么该怎么才能传输其余字符呢？
答：其中一种方式就是使用Base64。Base64通常用于在HTTP协议下传输二进制数据。

base64实现原理
Base64的索引与对应字符的关系以下表所示：

也就是说，若是将索引转换为对应的二进制数据的话须要至多6个Bit(2^6=64)。然而ASCII码须要8个Bit来表示，那么怎么使用6个Bit来表示8个Bit的数据呢？6个Bit固然不能存储8个Bit的数据，可是46个Bit能够存储38个Bit的数据啊

能够看到“Son”经过Base64编码转换成了“U29u”。这是刚恰好的状况，3个ASCII字符恰好转换成对应的4个Base64字符。可是，当须要转换的字符数不是3的倍数的状况下该怎么办呢？Base64规定，当须要转换的字符不是3的倍数时，一概采用补0的方式凑足3的倍数，具体以下表所示：

每6个Bit为一组，第一组转换后为字符“U”，第二组末尾补4个0转换后为字符“w”。剩下的使用“=”替代。即字符“S”经过Base64编码后为“Uw==”。这就是Base64的编码过程。

好了，原理懂了，那么若是要进行base64编码，咱们该怎么作呢？本身撸一个方法？找一个库？都行，可是HTML规范中已经规定了base64转换的API，window对象上能够访问到base64编码和解码的方法，直接调用便可。
window.atob() // 对base64编码过的字符串进行解码
window.btoa() // 对ASCII编码的字符串进行base64编码（不支持汉字，汉字可经过URIencode预处理后再编码）

base64有哪些应用场景
前端将较小的icon编码为base64直接在文档中加载，减小http请求
电子邮件传输二进制文件时，一般用base64编码后再传

注意：
base64编码后的数据量是要比编码前大的，因此base64不能用于减小数据量。
base64不能用于加密数据，即便使用私有的索引表也是不安全的。

关于转中文出错：btoa("中文") // The string to be encoded contains characters outside of the Latin1 range.
意思就是超出支持范围，ASCII。

可是，若是你非要使用btoa来base64转码中文，也不是不行，就是略微蛋疼。以下：

btoa(escape("中文")) // "JXU0RTJEJXU2NTg3"

unescape(atob("JXU0RTJEJXU2NTg3")) // "中文"

btoa(encodeURI("https://zweizhao.com/文章/JS经常使用转码URI与Base64.md"))
// "aHR0cHM6Ly96d2Vpemhhby5jb20vJUU2JTk2JTg3JUU3JUFCJUEwL0pTJUU1JUI4JUI4JUU3JTk0JUE4JUU4JUJEJUFDJUU3JUEwJTgxVVJJJUU0JUI4JThFQmFzZTY0Lm1k"

decodeURI(atob("aHR0cHM6Ly96d2Vpemhhby5jb20vJUU2JTk2JTg3JUU3JUFCJUEwL0pTJUU1JUI4JUI4JUU3JTk0JUE4JUU4JUJEJUFDJUU3JUEwJTgxVVJJJUU0JUI4JThFQmFzZTY0Lm1k"))
// "https://zweizhao.com/文章/JS经常使用转码URI与Base64.md"

btoa(encodeURIComponent("https://zweizhao.com/文章/JS经常使用转码URI与Base64.md"))
// "aHR0cHMlM0ElMkYlMkZ6d2Vpemhhby5jb20lMkYlRTYlOTYlODclRTclQUIlQTAlMkZKUyVFNSVCOCVCOCVFNyU5NCVBOCVFOCVCRCVBQyVFNyVBMCU4MVVSSSVFNCVCOCU4RUJhc2U2NC5tZA=="

decodeURIComponent(atob("aHR0cHMlM0ElMkYlMkZ6d2Vpemhhby5jb20lMkYlRTYlOTYlODclRTclQUIlQTAlMkZKUyVFNSVCOCVCOCVFNyU5NCVBOCVFOCVCRCVBQyVFNyVBMCU4MVVSSSVFNCVCOCU4RUJhc2U2NC5tZA=="))
// "https://zweizhao.com/文章/JS经常使用转码URI与Base64.md"

参考：
从base64到atob和btoa的一些理解
 JS经常使用转码URI与Base64

MIME类型

每一个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图象image等，后面定义具体的种类。

常见的MIME类型(通用型)：
超文本标记语言文本 .html text/html
xml文档 .xml text/xml
XHTML文档 .xhtml application/xhtml+xml
普通文本 .txt text/plain
RTF文本 .rtf application/rtf
PDF文档 .pdf application/pdf
Microsoft Word文件 .word application/msword
PNG图像 .png image/png
GIF图形 .gif image/gif
JPEG图形 .jpeg,.jpg image/jpeg
au声音文件 .au audio/basic
MIDI音乐文件 mid,.midi audio/midi,audio/x-midi
RealAudio音乐文件 .ra, .ram audio/x-pn-realaudio
MPEG文件 .mpg,.mpeg video/mpeg
AVI文件 .avi video/x-msvideo
GZIP文件 .gz application/x-gzip
TAR文件 .tar application/x-tar
任意的二进制数据 application/octet-stream

URI编码解码

URL传输过程？
HTTP协议中参数组件的传输是key=value键值对的形式，若是要传输多个参数就须要用“&”符号对键值对进行分隔。例如?name1=value1&name2=$value2,这样在服务器收到这种字符串的时候，会用“&”分隔出每个参数，而后再用“=”来分隔出参数值。

针对name1=value1&name2=value2咱们来讲一下客户端到服务器端的概念上解析过程：

上述字符串在计算机中用ASCII码（16进制）表示为：6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532

服务器端在接收到该数据后就能够遍历该字节流，首先一个字节一个字节的读取，当读到3D这个字节的时候，服务器端就知道前面读到的字节串表示一个key，继续读取，若是遇到了26，表示从刚才读到的3D到26字节之间的字节串是上一个key的value，按照此方法就能够解析出客户端传过来的参数。

如今又这样一个问题：若是个人参数值中就包含=或者&这样的特殊子字符的时候，该怎么办。好比说name1=value1,其中value1的值是va&lu=e1，那么在传输过程当中就会变成name1=va&lu=e1。用户传输的本意是只有一个键值对，可是服务器端会解析成两个键值对，这样就天然的产生了歧义。

如何解决上述问题带来的歧义呢？解决之法就是对URL进行编码!!!

URL编码只是简单的在特殊字符的各个字节（16进制）前加上”%”便可。例如，咱们对上述会产生歧义的字符(“va&lu=e1”)进行编码后的结果：name1=va%26lu%3D，这样服务器会把紧跟在”%”后的字节当成普通的字节，不会把它当成各个参数或键值对的分隔符。

另一个问题是，为何要用ASCII码传输，可不能够用别的编码？
由于一些历史的缘由URL设计者使用US-ASCII字符集表示URL。（缘由好比ASCII比较简单；全部的系统都支持ASCII）。固然能够用别的编码，你能够本身开发一套编码而后本身进行解析。就像大部分国家都有本身的语言同样。可是国家之间要怎么进行交流呢，用英语吧，英语的使用范围最广。

一般若是同样的东西须要编码，就说明这样的东西并不适合传输。至于缘由有多种多样，size过大，包含隐私数据等等。对于URL来讲，之全部要进行编码，是由于URL中有些字符会引发歧义。
例如，URL参数字符串中若是包含”&”或者”%”势必会形成服务器解析错误，因此须要对其进行编码。
又如，URL的编码格式采用的是ASCII码而不是Unicode，这也就是说你不能在URL中包含任何非ASCII字符，好比中文。不然若是客户端浏览器和服务器端浏览器支持的字符集不一样的状况下，中文可能会形成问题。

URL编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符。

哪些字符须要编码
RFC3986文档规定，URL中只容许包含英文字母（a-zA-Z）、数字（0-9）、- _ . ~4个特殊字符以及全部的保留字符。RFC3986文档对URL的编码解码问题作出了详细的建议，指出了哪些字符须要被编码才不会引发URL语义的转变，以及对为何这些字符须要编码作出了相应的解释。

US-ASCII字符集中没有对应的可打印字符：URL中只容许使用可打印的字符。US-ASCII码中的10-7F字节全都表示控制字符，这些字符不能直接出如今URL中。同时对于80-FF字节，因为已经超出了ASCII码定义字符的范围，所以也不能放在URL中。

保留字符：RUL能够划分为干了组件，协议、主机、路径等。有一些字符（： / ? # [ ] @）是用做分隔不一样组件的。例如：冒号用于分隔协议和主机组件，斜杠用于分隔主机和路径，问号用于分隔路径和查询参数，等等。还有一些字符（! $ & * + , ; =）用于在每一个组件中起到分隔做用，如等号用于表示查询参数中的键值对，&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时，须要对其进行编码。

RFC3986中指定了如下字符为保留字符：！ * ’ ( ) ; : @ & = + $ , / ? # [ ]

不安全字符：还有一些字符，当他们直接放在URL中的时候，可能会引发解析程序的歧义。这些字符被视为不安全的字符，缘由有不少。

空格：URL在传输的过程，或者用户在排版的过程当中，或者文本处理程序在处理URL的过程，都有可能引入可有可无的空格，或者将那些有意义的空格给去掉。
引号以及 <>：引号和尖括号一般用于在普通文本中起到分隔URL的做用。
警号#：一般用于表示书签或者锚点。
%：百分号自己用做对不安全的字符进行编码是使用的特殊字符，所以自己须要编码。
{ } | ^ [ ] ’ ~：某一些网关或者传输代理会篡改这些字符

须要注意的是，对于URL中的合法字符，编码和不编码是等价的，可是对于上边提到的这些字符，若是不通过编码，那么它们可能会形成URL语义的不一样。所以对于URL而言，只有普通英文字符和数字，特殊字符$ - _ . + ! * ’ ( )还有保留字符，才能出如今未经编码的Url中，其余字符均须要编码以后才能出如今URL中。
可是因为历史缘由，目前尚存在一些不标准的编码实现，例如对于”~”符号，虽然RFC3986文档规定，对于波浪号~不须要进行URL编码，可是仍是有不少老的网关或者传输代理会进行编码。

如何对URL中的非法字符进行编码?

URL编码一般也被称为百分号编码，是由于它的编码方式很是简单，使用%加上两位字符———[0-9A-F]———表明一个字节的十六进制的形式。URL编码默认使用的字符集是US-ASCII码，例如a在US-ASCII码中对应的字节值是0x61,那么URL编码以后获得的就是%61,咱们在地址栏中输入http://g.cn/search?q=%61%62%63，实际上就等于在google中搜索abc。又如@符号在ASCII字符集中对应的字节为0x40，通过URL编码以后获得的就是%40。

对于非ASCII字符，须要使用ASCII字符集的超集进行编码获得相应的字节，而后对每一个字节执行百分号编码。对于Unicode字符，RFC文档建议使用utf-8对其进行编码获得相应的字节，而后对每一个字节执行百分号编码。如”中文”使用UTF-8编码获得的字节是0xE4 0xB8 0xAD 0xE6 0x96 0x87,通过URL编码以后获得%E4%B8%AD%E6%96%87。

若是某个字符对应的ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。例如”Url编码”,使用UTF-8编码获得的字节是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81,因为前三个字节对应着ASCII中的非保留字符”Url”,所以这三个字节能够用非保留字符”Url”表示。最终”Url编码”通过编码以后获得的是Url%E7%BC%96%E7%A0%81,固然，若是你用%55%72%6C%E7%BC%96%E7%A0%81也是能够的。

因为历史缘由，有一些Url编码实现并不彻底遵循这样的原则
JS中提供3个函数对URL进行编码和解码 escape/unescape,encodeURI/decodeURI,encodeURIComponent/decodeURIComponent。

区别
这三对函数的安全字符（即不须要编码的字符）范围也不一样，以下所示：

escape（69个）：/@+-._0-9a-zA-Z
encodeURI（82个）：!#$&'()+,/:;=?@-._~0-9a-zA-Z
encodeURIComponent（71个）：!'()*-._~0-9a-zA-Z

如今对比encodeURI和encodeURIComponent，从名称上可看出encodeURI是针对整个URI进行编码，咱们以特殊的URI--URL来讲明下。

对于URL为http://www.baidu.com而言，若是用encodeURI编码，返回的还是“http://www.baidu.com”；若是用encodeURIComponent编码，返回的为"http%3A%2F%2Fwww.baidu.com"。

encodeURI所针对的是整个URI，并不会对分隔符如/,?,=符号进行编码，不然破坏了URI的原有含义，而encodeURIComponent则是针对URI的

某一部分进行编码，如查询字符串部分的&会被转义。

参考：为何要进行URL编码

结尾彩蛋

关于字符编码，来点有意思的emoji图标：🐵, 👲🏻, 👲🏿, 💇🏽‍♂️, 👨‍👨‍👦‍👦。

看看这些可爱的小图标，放在上个世纪，这只能用图片作，但如今都这些都是一个个真实的字符。感兴趣的能够研究下Emoji与Unicode、从Emoji的限制到Unicode编码