针对base64编码和URIEncode的一点研究

Posted 2020-11-26 leegent

Base64编码的作用

将任意的二进制比特串编码成由ASCii码中的64个可显示字符组成的字符串。

 

为什么需要base64编码？

所有的文件，本质上都是0、1组成的比特串，文本文件、二进制文件的区别只在于操作系统如何解读文件内容。前端最常用的html、css、js都是文本文件，而文本文件的所有比特都会被操作系统当做字符编码来解读（比如按照UTF-8编码规则来解读），所以，当我们想在一个文本文件里保存二进制文件的数据（比如在css文件里保存一张图片）时，就会遇到问题——比如，操作系统会强行把原本属于图片的二进制数据当成UTF-8编码串来解码，然后我们会在页面上得到一堆不知所云的乱码，甚至可能会破坏真正的文本数据区域。

当然，这个问题是有解的——我们用可以正常展示的文本字符来编码二进制数据，然后保存在css等文本文件里，在真正使用到这些数据时（比如<img>标签渲染图片内容）再进行解码。这就是base64所做的事。

 

为什么码表里有64个字符？

因为ASCii码的可见字符只有95个，向下取整（2的n次方）就是64。

具体是哪64个？A-Z、a-z、0-9，以及+、/ 这两个符号。26+26+10+2正好是64。

除此之外，还有一个字符有时也会作为占位符出现在Base64编码串的末尾，即等号 = 。一个等号表示编码时在原比特串的末尾补了2bit的0。等号只可能出现1或2个，下面会解释为什么。

 

为什么base64编码后文件体积会变大？

64个字符可以表示6bit的数据(2^6=64)，而一个ASCii码字符要占一个字节（1byte = 8bit），也就是说，base64编码其实是用8个比特来表示原二进制串里的6个比特，所以编码后体积是原二进制串的4/3。

正是因为这个原因，前端base64编码只适用于小文件，因为增加的体积不多，还可以省下一次网络请求；但当文件体积比较大时，会影响网站初次加载和渲染的速度（解码base64大文件也会消耗性能），这种时候文件还是放CDN比较好。

 

为什么base64补0只有两种情况？

考虑另一个限制条件：在操作系统中，文件系统进行读写操作，都是以字节为单位来操作的，而一个字节等于8bit，因此，base64的编码对象，其二进制位数都是8的倍数，而base64编码是每次从中取出6bit来编码，这就可能在二进制串的末尾出现除不尽的情况——有且仅有两种情况：

1. 剩1个字节待编码，从中取出6bit之后，剩2bit尚未编码（8 - 6 = 2），这时需要补4位0。

2. 剩2个字节待编码，从中取出12bit之后，剩4bit尚未编码（8*2 - 6*2 = 4），这时需要补2位0。

剩3个字节时，正好对应4个6bit，不需要补0。

所以我们可能在Base64串尾部看到1或2个等号，就是这样来的。

 

Base64与URI编码的异同

相同点：它们都是用给定的字符集去表示更广范围数据的方法。

区别：URI编码是针对超出URI合法字符集（是ASCii可显示字符集的子集，去掉了不安全字符和保留字符）范围外的字符做编码，而base64是针对二进制数据做编码——一个是对文本的编码，一个是对二进制数据的编码。

两个Tips

1. 文本本质上也是二进制数据，因此也可以强行拿来做base64编码

2. base64编码中的斜杠号/和等号=不属于URI合法字符，故base64编码串不能直接带在链接参数上