谷歌把3字节变成4字符的算法，程序员用了30年还没换

Base64编码每天在互联网上传输数十亿次，却极少有人停下来问：为什么偏偏是64个字符？为什么3字节非要拆成4个字符？这个1978年诞生的算法，至今仍在你的JWT令牌、邮件附件、CSS内嵌图片里默默运转。

本文用一组具体数字拆解它的工作原理，以及开发者最常踩的5个坑。

从24比特到4个字符：一个刻意的设计

Base64的核心操作极其机械：每3字节（24比特）输入，切成4个6比特组，每组映射到64个可打印字符之一。64个字符刚好是A-Z、a-z、0-9，加上+和/，再用=做补位填充。

这个设计的代价很明确：编码后体积膨胀33%。3字节变4字符，没有压缩，没有加密，只是为了让二进制数据能安全穿过只认文本的系统——1980年代的电子邮件、HTTP头、URL参数、JSON字段。

输入"Man"的完整过程：二进制是01001101 01100001 01101110，切成010011、010110、000101、101110四组，对应Base64字符T、W、F、u。没有魔法，只有位运算。

5个真实使用场景，以及它们的隐藏成本

场景一：HTML/CSS内嵌图片。把小图标转成Data URL可以省掉一次HTTP请求，但Base64字符串会让图片体积膨胀约33%。Google的PageSpeed Insights明确建议：超过2KB的图片就别内嵌了，省下的请求时间抵不上传输膨胀。

场景二：HTTP Basic认证。Authorization头里的Basic dXNlcjpwYXNzd29yZA==看着像加密，实则是user:password的明文转码。RFC 7617文档强调：没有HTTPS时，这种编码"不提供任何机密性保护"。

场景三：JWT令牌结构。一个标准JWT是三段Base64url编码用点号连接：头部、载荷、签名。中间那段payload解码后就是JSON明文，包含用户ID和权限。很多人误以为JWT加密了数据，其实它只是签名防篡改，内容对任何能拿到令牌的人都是透明的。

场景四：JSON传二进制文件。API返回PDF或图片时，常见这种结构：

{ "filename": "invoice.pdf", "content": "JVBERi0xLjQKJeLjz9MKMSAwIG9iag..." }

content字段就是Base64编码的文件内容。这是MIME（多用途互联网邮件扩展）标准的遗产，从1992年的电子邮件附件延续至今。

场景五：数据库存二进制。Redis字符串类型、部分NoSQL系统用Base64存证书或密钥。代价是存储空间和读写时的编解码CPU开销，但换来了跨系统文本传输的兼容性。

开发者最常踩的3个坑

坑一：把编码当加密。Base64的解码不需要密钥，浏览器控制台输入atob("dGVzdA==")就能还原。见过把用户密码Base64存数据库的案例，这等于明文存储。

坑二：URL安全版本混淆。标准Base64含+和/，在URL里会被转义成%2B和%2F，增加长度。JWT用的是Base64url变体，把+换成-、/换成_、去掉=填充。混用两者会导致签名验证失败。

坑三：忽略体积膨胀。把1MB图片Base64编码塞进JSON，实际传输1.33MB。移动端弱网环境下，这33%的额外流量可能直接拖垮体验。

JavaScript和Python的调用方式足够简单：前者用btoa()/atob()或Buffer.from(str).toString('base64')，后者用base64.b64encode()。但工具顺手不代表理解到位——知道什么时候不该用，比知道怎么用更重要。

这个48年前的算法至今没有退役迹象。当你下次复制一段JWT令牌到解码网站时，不妨想想：如果当年电子邮件系统能直接传二进制，我们今天会用什么？