Base64 编码与解码

Base64 是什么，又为何存在

Base64 是一种二进制到文本（binary-to-text）的编码方案。它接收原始字节——也就是构成图像、压缩包、加密密钥，或任何其他不是可读纯文本的数据——并用一套小而安全、由 64 个可打印字符组成的字母表重写它们：26 个大写字母 A-Z、26 个小写字母 a-z、十个数字 0-9，外加两个符号，通常是 + 和 /。等号则用于末尾的填充。由于它产生的每个字符都是普通的 ASCII，结果就能穿过那些原本只为处理文本而设计的系统。

这正是 Base64 被发明的全部理由。许多较老的协议——电子邮件就是经典例子——都假定自己承载的内容是文本。如果你把原始二进制交给它们，有些字节会被损坏、剥除或被解释为控制字符，于是数据到达时已经损坏。Base64 把字节转换成任何文本安全的通道都会原封不动放行的形式，从而绕开了这个问题。原始数据随后可以在另一端被精确地重建。

转换是如何进行的

从机制上讲，Base64 把输入按每三个字节——也就是 24 位——分组，然后把这同样的 24 位重新切成四组，每组六位。六位能表示 64 种可能的值，这正是字母表为何有 64 个字符的原因。所以三个字节的输入总会变成四个字符的输出。当输入长度不是三的整数倍时，编码器会用一两个 = 字符填充最后一组，好让解码器知道真正的数据在哪里结束。

这个四比三的比例也是那个著名的体积代价的来源：Base64 输出大约比原始数据大 33%。如果编码后的文本被折成固定宽度的行（电子邮件标准常常要求这样），你还要在此之上为换行多付几个百分点。这份开销是兼容性的代价，对于大多数用途而言是一笔公平的交易。

你会在哪里遇到 Base64

一旦你知道该留意什么，Base64 在日常计算中几乎无处不在：

• Data URI。一张小图像或一种字体可以用 data: URI 直接嵌入 HTML 或 CSS，文件内容以 Base64 写出。浏览器就地解码它，省去一次单独的网络请求。
• 电子邮件附件。MIME，也就是让邮件能携带文件的标准，依靠 Base64 让二进制附件无损地穿过纯文本的邮件系统。
• HTTP Basic 认证。那熟悉的 Authorization: Basic ... 头不过是用冒号连接、再经 Base64 编码的用户名和密码——这正是为什么 Basic 认证必须始终运行在 HTTPS 之上。
• 令牌与配置。JSON Web Token、证书、SSH 密钥，以及无数配置值都以 Base64 存储或传输，好让它们在复制粘贴和基于文本的存储中存活下来。

编码不是加密

这是最需要理解的一点，它同时绊倒了初学者和经验丰富的开发者。Base64 不是加密，完全不提供任何安全性。它没有密钥、没有密码，也没有任何私密之处。这个变换是完全公开且完全可逆的：任何看到一段 Base64 字符串的人都能在一秒内把它解码回原始字节，用的正是和这个一模一样的工具。

所以 Base64 是个糟糕的藏身之处，无论藏的是密码、API 密钥还是任何敏感值。如果一段字符串仅仅看上去被打乱了，那并不意味着它受到保护。相比之下，加密用一个密钥变换数据，使得只有持有该密钥的人才能读取它。两者解决的是不同的问题：加密保护机密性，Base64 保护兼容性。它们常常一起使用——你可能用 AES 加密数据，然后对密文做 Base64 编码，好让它能穿过文本通道——但其中一个永远不能替代另一个。

编码与解码

这两个方向就是简单的镜像。编码接收你的原始文本或二进制，产生 Base64 字符串。解码接收一段 Base64 字符串，重建出精确的原始字节。我们的工具直接在你的浏览器中完成两者——你键入或粘贴的任何内容都不会被发送到服务器，所以操作完全是本地且私密的。这使得解码你正在调试的令牌，或编码你想嵌入的片段，都很安全，你的数据不会离开页面。

关于相关的转换，请看我们的 URL 编码/解码工具来做百分号编码，或者用 JWT 解码器来检查令牌内部的 Base64 段。你会在我们其余的开发者工具旁边找到它们。

常见问题