什么是Base64?
Base64 是一种用 64 个可打印字符来表示二进制数据的编码方式。它最核心的用途，不是保密，而是让原本不适合直接放进纯文本通道的字节内容，可以安全地穿过邮件、表单字段、配置片段、JWT 组件、Data URI 或其他只接受文本的边界。这也是为什么 Base64 会在 RFC 4648 与 MIME 相关规范里长期存在，而且直到今天仍然是开发、排错与内容传输场景中的高频基础工具。
Base64编码算法原理
Base64 的原理相对直接：它把原始字节重新切分成适合文本映射的 6 位块，再按照固定字符表输出结果。真正需要说明的，不是算法复杂度，而是当前处理的到底是原始字节、文本内容、Base64URL 片段，还是带 MIME 前缀的 Data URI。
- 将输入数据拆分为每 3 个字节一组。
- 把这 3 个字节共 24 位重新分组为 4 个 6 位块。
- 将每个 6 位值（范围 0-63）映射到 Base64 字符表。
- 如果最后一组不足 3 个字节，就用 0 位补齐，并在结果末尾加上相应数量的 `=` 作为填充符。
Base64 字符集：A-Z、a-z、0-9、+、/ 填充字符：=
如何使用这个工具
- 先选择是把普通文本编码成 Base64，还是把复制来的 Base64 解码回可读文本。
- 粘贴 UTF-8 文本样本或完整 Base64 字符串，并检查填充符、字符编码或 URL-safe 差异。
- 确认输出与预期字节或可见文本完全一致后，再复制结果。
经典示例：Man 为什么会变成 TWFu
文本 "Man" 的 ASCII 码：77 97 110
二进制表示：01001101 01100001 01101110
重组为 6 位：010011 010110 000101 101110
十进制值：19 22 5 46
Base64 结果：T W F u简化的 JavaScript 实现示例
下面这段示例代码的重点，不是取代浏览器内建 API，而是让你更直观地理解 3 个字节到 4 个 Base64 字符的转换流程。
function encodeBase64Simple(bytes) {
const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
let output = "";
for (let i = 0; i < bytes.length; i += 3) {
const b1 = bytes[i];
const b2 = i + 1 < bytes.length ? bytes[i + 1] : 0;
const b3 = i + 2 < bytes.length ? bytes[i + 2] : 0;
const triplet = (b1 << 16) | (b2 << 8) | b3;
output += alphabet[(triplet >> 18) & 0x3f];
output += alphabet[(triplet >> 12) & 0x3f];
output += i + 1 < bytes.length ? alphabet[(triplet >> 6) & 0x3f] : "=";
output += i + 2 < bytes.length ? alphabet[triplet & 0x3f] : "=";
}
return output;
}常见用途
- MIME 邮件附件或其他需要走纯文本传输的二进制数据。
- URL 安全变体 Base64URL 场景，例如 JWT header 与 payload 的组成部分。
- 将小型图片或字体数据以 Data URI 形式嵌入 HTML 或 CSS。
- 在 XML、JSON 或配置片段中携带不适合直接裸露的字节内容。
- 快速检查复制来的令牌片段、响应载荷或记录数据是否只是被 Base64 包装。
进阶边界与常见误区
真正棘手的 Base64 问题，往往不在算法，而在边界上下文：标准 Base64 与 Base64URL 是否混用、Data URI 前缀是否完整、MIME 场景里的换行是否被保留、以及文本在进入编码前究竞采用了哪种字符集。这些问题看起来像“解码失败”或“结果乱码”，实际上多半是上下文没对齐。
- Base64URL 会把 `+`、`/` 替换成 `-`、`_`，有时还会省略填充符，所以并不总能直接丢进严格的标准 Base64 解码器。
- Base64 会让数据体积平均增加约三分之一，因此它换来的是传输便利，不是存储效率。
- Base64 不是加密。任何人只要拿到内容，都能在不需要密钒的情况下还原原始字节。
- 大文件的 Base64 会显著增加内存与处理成本，尤其在浏览器与前端载荷里更就得留意。
- 如果结果最终要进入 Data URI、JWT 或其他特定容器，周边语法和前缀常常与编码値本身一样重要。
Base64 与其他编码的比较
| 编码方式 | 特点 | 主要用途 |
|---|---|---|
| Base64 | 使用 64 个可打印 ASCII 字符表示二进制数据 | 邮件附件、Data URI、JWT 组件、二进制数据文本化传输 |
| URL 编码 | 把特殊字符转成 `%XX` 形式，服务 URL 上下文安全 | 查询参数、路径片段、表单提交 |
| 十六进制编码 | 每个字节使用两个十六进制字符表示 | 哈希值展示、底层字节检查、二进制可视化 |
使用注意
- 复用可检查的 Base64 文本或解码后的普通文本前，先检查填充符、字符编码、URL-safe 变体、换行，以及内容是否在其他层真正加密。
- Base64 是可逆编码，不是加密；不要把编码或解码结果当作受保护的密钥存储。
- 当结果会影响生产工作或客户可见内容时，应保留原始普通文本、复制来的 Base64 字符串、令牌片段、数据片段和 UTF-8 内容以便回退和核对。
Base64 编码/解码 参考说明
Base64 编码/解码 重点说明 Base64 是编码算法而不是加密，并解释它为什么常用于在文本协议中传输二进制数据、令牌片段、图片或配置内容。
- Base64 会把每 3 个原始字节拼成 24 位，再拆成 4 组 6 位索引，并映射到 64 个可打印字符上。
- 当输入字节数不能被 3 整除时，会补 `=` 填充符，使输出长度保持为 4 的倍数。
- Base64 可逆，不能单独用于保护密钥、密码或隐私数据。
- 处理中文等非 ASCII 文本时要注意字符集，默认使用 UTF-8 最稳妥。
参考资料
常见问题
以下问题围绕 Base64 编码/解码 的实际用途整理，重点说明输入要求、输出结果和常见限制。将文本编码为 Base64，或将 Base64 解码回可读文本。
Base64 编码/解码 会把文本加密吗？
不会。Base64 是可逆编码，只是为了让二进制或文本内容更容易在面向文本的系统里传输。拿到编码字符串的人都可以把它解回来。
为什么 Base64 编码/解码 解码出来的内容有时会乱码？
原因通常是源内容并不是 UTF-8 文本，或者它本来就是二进制数据而不是可读字符。应先确认原始字符集，以及这段内容是否本来就适合按文本解码。
适合用 Base64 编码/解码 处理 JWT 片段或接口样本吗？
它可以帮助查看普通 Base64 文本，但 JWT payload 使用的是 Base64URL，而且还涉及认证语义，不能仅按普通解码场景理解。需要查看令牌声明时，应优先使用专门的 JWT 页面。
Base64 编码/解码 最适合处理什么样的普通文本、复制来的 Base64 字符串、令牌片段、数据片段和 UTF-8 内容？
Base64 编码/解码 的核心用途是把文本编码成 Base64，或把 Base64 解码回可读文本。当普通文本、复制来的 Base64 字符串、令牌片段、数据片段和 UTF-8 内容需要快速变成可检查的 Base64 文本或解码后的普通文本，并继续用于API payload 核对、令牌检查、配置清理、邮件源码查看和 Data URI 准备时，它最有价值。
复用 Base64 编码/解码 生成的可检查的 Base64 文本或解码后的普通文本前，最该检查什么？
应优先检查填充符、字符编码、URL-safe 变体、换行，以及内容是否在其他层真正加密。这些细节最能直接判断结果是否已经适合继续交给下游流程。
Base64 编码/解码 生成的可检查的 Base64 文本或解码后的普通文本通常会被带到哪里继续使用？
最常见的下一步就是用于API payload 核对、令牌检查、配置清理、邮件源码查看和 Data URI 准备。这类输出是按真实交接场景来组织的，不是泛化占位结果。
什么时候不应该直接相信 Base64 编码/解码 的结果，而要人工复核？
Base64 是可逆编码，不是加密；不要把编码或解码结果当作受保护的密钥存储。