base64 原理及转换会变大的原因

以前用到base64有这么几个场景：

1. 使用html2canvas 将html 转成图片的时候，html 里面的跨域图片无法生成图片，所以将图片先转成base64再生成
2. jpg之类的图片有损压缩，使用canvas.toDataUrl()
3. webpack 打包时，为了减少 https（http） 的请求数量（主要是为了减少三次握手，如果是http1.1开启了长连接或者http2.0/3.0之类的有多路复用，其实我觉得可以不用转base64），将小于10k（好像是10k，记不清了）的图片转成base64打在代码里。

但是，图片转成base64，体积会变大33%，所以大点的图片也不建议转换。

那么，转成 base64 为什么会变大呢？

还有为啥叫 base64， 不叫base16或者base24、base32呢？

针对上面的疑问，我们一步步来解释，别急，老弟！

base64 生成步骤

假设我们有个单词要转成base64： Hello

1. 找到每个字母对应的ASCII值

通过上表可以得知分别为：

2. 将 ASCII 值转换为二进制

算数不好的同学（我）试试这个方法：

通过上面可以知道，其实 ASCII 码只有128个，也就是 7位就够了，但是存储确是用的 8 位，每个都是在前面补0，其实已经浪费了一些空间。假如说以后字符补充到256个，就可以充分利用空间了。

3. 将 ASCII 的二级制值每6个一组，重新组装（如果不足六位，在前面补0），并计算对应的10进制的值

那疑问来了，为什么是6个一组？

首先常用字符有a-z、A-Z、0-9

这些字符总共 26 + 26 + 10 = 62个，另外有找了2个凑数的字符 + /

其实我觉得其他字符拿来凑数也是可以的，例如 -、#、[、]等。

2的6次方等于64，也就是6位就足以覆盖全部的base64字符了，所以是6位。

但是存储还是按8位一组来的，所以要在前面补2个零。

6 和 8 的最小公倍数是24，也就是3个字节，每 6 位一组，也就是4组，每组前面补2个0，凑够8位。所以这个时候就变成了4个字节，也就是增加了33.33%

重新分组后新的值为：

同样计算过程为：

4. 接下来就是根据新的值在base64表查找对应的字符了

最后的结果为：

这时候转换的结果是SGVsbGP

因为规定不足4字节的要在后面补 =

所以结果为SGVsbGP=

本以为这样就ok了，但是我去在线base64 加解密 算了下结果为 SGVsbG8=

什么？最后一位是8？ 看了下base64 表里对用的值为60，也就是 parseInt(111100,2)，仔细想了下，每三个字符一组，如果只有两个，那最后一个字符就是00000000，分组的时候 就变成了111100。
所以纠正后的结果为：

表格地址获取：https://docs.qq.com/doc/DU0tod0JXQ0J3UFRp

为什么是Base64，可以是Base16或者Base512吗？

前面已经说到ASCII码有128个，即 2 的 7 次方，一个字节等于8个无符号位，这种情况下，已经浪费了 1 个符号位，Base64 是 6位，假如说我们用4位的，也就是2的4次方16，可以命名为Base16，这个时候转换会有什么后果呢？ 相当于一个字节拆成2个字节，4和8最小公倍数为32，也就是4个字节一组，但是重新组装后，长度变为原来的2倍，所以体积变为原来的2倍。这时候应该清楚为什么是Base64了吧，就是为了减少空间的浪费。那可以发明Base256、或者Base512 这种东西来节省体积吗？如果是Base256，也就是2的8次方，跟现在的位数一样，但是用不同的符号代替，则可以保证在不增加体积的情况下完成转换。如果是Base512，则是9位了，一个字节才8位，那就不行了。这么说来Base64 还有优化空间，上限就是Base512，哪天我高兴了，我也给编个Base512的表，发明Base512编码，哈哈哈！！！

然而实际情况是我并没有512个字符可以用