什么是 Base64？
Base64 用六十四个可读字符改写字节，让数据能穿过为文本设计的通道：邮件正文、JSON 字符串、XML 属性、URL。每三个字节变成四个字符，名字由此而来 — 字母表有六十四个符号，每个恰好承载 6 个比特。
它是传输编码，不是安全措施，也不是压缩。输出比输入大约三分之一，任何拿到字符串的人都能直接还原。想知道数据是否被改动，那是哈希（哈希生成器）；想让内容保密，那是加密。Base64 两样都不做。
要记住的那个数字：三个输入字节变成四个输出字符。本页其他一切都由此推出。四个字符承载 24 个比特，而 24 个比特恰好是三个字节，所以数据永远不会丢失或凭空出现 — 除了最末尾，输入可能填不满最后一组三个字节。
本页可用的五种字母表
前两行是标准，后三行是围绕 Unix 成长起来的惯例。五种字母表每字符承载的 6 个比特相同，区别只在用哪六十四个字符来承载，因此同样的字节会变成五个不同的字符串。字符串内部没有任何信息说明它出自哪个字母表，这就是字母表选择器默认为标准、URL-safe 复选框是第二行快捷方式的原因。
页面如何判断候选：选择器是两个方向的默认值。解码时，右侧面板还会读字符串本身 — - 和 _ 只可能来自 URL-safe 字母表，+ 或 / 只可能来自标准字母表，靠前的 / 或 . 则指向两种 Unix 字母表。所有能读取当前输入的字母表都会列在那里，并附上它是不是候选及原因。
换行：76 与 64 字符
MIME 要求 Base64 能放进邮件而不让某一行长得离谱，最终定为每行 76 个字符、以 CRLF 分隔。包裹证书和密钥的 PEM 文件用 64。换行不属于数据：解码器会先去掉换行把各行接回去再做别的事，因此带换行和不带换行的字符串解码出完全相同的字节。除最后一行外，每行都容纳整数个四字符组，这正是接回去是安全的原因。
本页默认把输出放在一行，除非您选择宽度；解码器则接受带或不带换行的输入。本页写出的换行是普通换行符，这是文本框能容纳的形式；MIME 邮件正文传统上在每个换行前加一个回车，而现实中每种解码器两者都接受。
填充，以及为什么可以去掉
当输入不是三字节的倍数时，最后一组四个字符不完整，由一个或两个 = 补齐。它们完全不承载数据：只是说明四个字符里有几个是真的。解码器也可以从长度推算这一点，这就是 URL-safe Base64 传统上不留填充的原因 — = 在 URL 或文件名里很别扭，有些系统还会对它做百分号编码。
选项行的复选框在选中 URL-safe 字母表时保留填充。其余一切不变；承载数据的字符两种情况下完全相同。
常见误解
- “Base64 能隐藏数据。”不能。它是不带密钥的替换，全部意义就在于任何读者都能撤销它。把密码或令牌包一层 Base64，谁能不能读丝毫没有变化。
- “Base64 是压缩。”恰恰相反：每三个输入字节变成四个输出字符，文本比它承载的数据大三分之一。
- “换行是值的一部分。”它们只是排版。增删换行永远不会改变还原出的字节。
- “URL-safe 是另一种编码。”是同一编码换掉两个字符：
+ 变 -、/ 变 _，使字符串可以放在 URL 路径或查询值里而无需转义。
- “能解出来的字符串一定是合法 Base64。”字母表字符组成的任何字符串都是合法 Base64，因为 6 比特值的任意组合都对应一串有效字节。字符串只在下一步、当这些字节被拿去对照应有格式时才会暴露问题。
- “填充能说明用的是哪个字母表。”不能，而且多数情况下字符也说明不了：标准与 URL-safe 字母表在六十四个符号中有六十二个相同，短字符串常常在两者中读出同一结果。
常见问题
为什么 Base64 字符串有时结尾一个 =，有时两个？一个 = 表示最后一组含三个有效字符，即两个输入字节；两个 = 表示含两个，即一个输入字节。没有 = 说明输入长度是 3 的倍数。
Base64 能表示任意二进制文件吗？能，这正是它的主要用途。本页把输入当作 UTF-8 文本；需要编码非文本内容时，专用的 文件转 Base64 工具会读取原始字节。
在 API 里该用哪种字母表？以接收方的文档为准。它说 URL-safe 就用 URL-safe；它没说而值要放进 URL 时，去掉填充的 URL-safe 是稳妥的选择。
输出区分大小写吗？完全区分。a 和 A 是不同的值，这也是 Base64 输错一个字符的容错能力远不如 Base32 或 Crockford Base32 的原因。
