编码

Base64 编码详解：原理、用途与常见误解

邮件附件、图片 data URI、JWT 令牌都离不开 Base64。本文说明 Base64 到底做了什么、为什么输出比输入更长，以及什么时候该用、什么时候不该用。

AIBIZAP 团队更新于 2026-10-28 约 4 分钟

为什么需要 Base64

计算机中的一切数据归根结底都是字节。然而很多通道只能安全地传输文本，例如邮件正文、HTTP 头、JSON 文档和 URL。如果把原始图片字节或密文直接塞进这些通道，控制字符和换行可能会破坏数据，中间系统也可能擅自改写内容。

Base64 的解决办法是把任意字节序列映射到由大小写英文字母、数字以及 + 和 / 组成的 64 个字符上。这些字符几乎在所有系统中都被视为安全字符，因此二进制数据可以完整地通过纯文本通道。该格式由 RFC 4648 标准化。

核心思路很简单：每次取 3 个字节(24 位)，把这 24 位拆成 4 组，每组 6 位。6 位可以表示 0 到 63 共 64 个值，因此每组对应一个字符：0–25 是 A–Z，26–51 是 a–z，52–61 是 0–9，62 是 +，63 是 /。

以单词 Man 为例，它的字节值是 77、97、110。把这 24 位按 6 位拆分得到 19、22、5、46，对应字符就是 TWFu。非英文文本转换成字节后也是同样的处理方式：韩文字符“한”在 UTF-8 中占 3 个字节(ED 95 9C)，所以正好变成 4 个字符 7ZWc。

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

由于每 3 个字节总会变成 4 个字符，Base64 输出比输入大约多 33%。一个 1,000 字节的文件会变成 1,336 个字符。这就是把大图片作为 data URI 嵌入页面会让页面明显变重的原因。

当输入长度不是 3 的倍数时，最后一组只剩 1 个或 2 个字节。缺少的位用 0 补齐后再编码，并添加 1 个或 2 个 = 字符，使输出长度保持为 4 的倍数。剩 1 个字节时添加 ==，剩 2 个字节时添加一个 =。所以 Hi(2 个字节)会变成 SGk=。

填充只是帮助解码器还原准确长度的标记，本身不携带数据。有些系统会省略填充，严格的解码器可能因此报“长度无效”错误。通常只要在末尾补上 =，让长度成为 4 的倍数即可解决。

+ 和 / 在 URL 中有特殊含义：+ 可能被解析为空格，/ 用于分隔路径。因此 Base64URL 变体把 + 换成 -，把 / 换成 _。同样的两个字节 FB FF，用标准 Base64 编码是 +/8=，用 Base64URL 编码是 -_8=。

JSON Web Token(JWT)的三个部分都采用 Base64URL 编码，通常还省略了填充。解码 JWT 的中间部分，就能直接读到用户 ID、过期时间等声明，这正引出了关于 Base64 最重要的一点。

Base64 输出看起来像随机字符串，所以常被误认为是加密。但它没有密钥，任何人都能按公开的规则立即还原。把密码或 API 密钥转成 Base64 来存储或传输，安全性和明文没有区别。

HTTP Basic 认证就是一个典型例子。用户名和密码用冒号连接后进行 Base64 编码再发送，但这只是传输格式，真正的保护来自 HTTPS。如果要隐藏数据，请使用 AES 等加密算法；如果要检测篡改，请使用哈希或签名。

了解 Base64 用在哪里，能帮助你快速识别陌生的字符串。

大多数解码错误都源于少数几个原因。首先检查是否混入了换行或空格，邮件和 PEM 文件常常每 76 个字符换一行。其次，如果看到 - 或 _，说明这是 Base64URL，必须按该方式解码。最后，如果长度不是 4 的倍数，说明缺少填充。

如果解码成功但文字显示为乱码，问题出在原始字符编码上。例如中文在 UTF-8 和 GBK 中的字节完全不同，必须用编码时相同的字符集来解析。AIBIZAP 的 Base64 工具以 UTF-8 处理，因此中文、日文、韩文和表情符号都能正确往返转换。