揭开数据传输的伪装衣：深入浅出 Base64 编码

无论你是前端从服务端接收一个长相怪异的头像图片数据 data:image/png;base64,iVBORw0...，还是在配置 K8S 密钥字典，你肯定都见过这种由大小写字母、数字和零星几个斜杠凑成的长串文本。这，就是大名鼎鼎的 Base64 编码。

为什么创造他？它解决的痛点

在计算机内部，所有的文件——无论是 JPG 街拍图，PDF 劳动合同，还是一段普通的文本，归根结底都是只含有 0 和 1 的二进制数据（Binary）。

以前的互联网主要是为了传送简单的英文文本字符而设计的。早期的路由节点或者邮件服务器 (SMTP)，如果在传输过程中读到了某些无法理解的二进制控制字符，比如系统响铃符号，它可能会懵圈报错，不仅会截断你的数据，甚至会认为这是一次攻击操作。

为了能在这个“只认纯文本”的高速公路上运载“特殊包裹（比如图片）”，程序员们必须给这些特殊包裹套上一个“马甲”。这个马甲不能包含特殊控制标点，必须全部是由标准、更安全的字母数字组成，这就是 Base64。

Base64 的硬核转换逻辑

Base64 顾名思义，它使用了 64 个极其安全的字符作为它的“马甲材质”。具体是哪 64 个？

• 字母 A-Z (26个)
• 字母 a-z (26个)
• 数字 0-9 (10个)
• 加上最后两个普通符号：+ 和 /。 (总计 64 个)

它是如何把原图里的二进制转换为这 64 个字符的呢？

本质上，计算机每次抓取三个 8 位字节（共 24 个二进制比特位）。然后，将这 24 个比特狠狠地切分一刀，切成了四份，每份 6 位的二进制碎片。因为 2 的 6 次方刚刚好等于 64，所以每一份碎片的数值就落在 0 到 63 之间，可以刚刚好和那 64 个挑选出来的标准安全字母一一对应查询字典。

这个过程中，数据量膨胀了大约 33% (从原本的 3 Bytes，变到了 4 个字符占据 4 Bytes 的体积)。这就是使用 Base64 编码必须要付出的“物理学超载代价”。

那个神秘的等号：= 的秘密

你一定经常在某些 Base64 字符串的最结尾见到 = 或者甚至是 == 单独列在大厦之尾。它们有什么用？

还记得刚才的切分法吗？计算机总是一把抓取 3 个字节。可是，如果你的文本或图片的原始大小偏偏除不尽这个 3（比如大小为 10 Bytes，3 个一组凑完剩下最后 1 个 Byte），这时怎么办？

这时候最后那一组其实是个残缺的，计算机只能补 0 。为了告诉拿到这串密码的接收方：“注意咯，我最后这里是补零凑出来的数，别当真！”，就用等号 = 作为填补提示（Padding）。缺了两组数字位，就放两个 ==。

最大误区：不要滥用 Base64 来加密密码！

必须强调千万次：Base64 不是加密（Encryption）！它仅仅是一种编码（Encoding）！

这玩意连小偷的锁都算不上，充其量就是把一段日文翻译成了大号西班牙语发出去。任何一个人只要懂西班牙语（知道 Base64 的规则），用浏览器甚至我们专门提供的 Base64 编解码器，一秒钟不到就能百分之百毫无保留地把文本剥出来。

如果想做安全保护，请出门左转寻找 AES 或者是 SHA 哈希工具。