🔐 Base64 编解码

关于 Base64 编解码

Base64 是一种基于 64 个可打印字符（A-Z、a-z、0-9、+、/）来表示二进制数据的编码方式，等号（=）用作填充字符。它最初被设计用于电子邮件（MIME）中传输二进制附件，如今已广泛应用于 Web 开发的各个领域。

Base64 的编码原理是将每 3 个字节（24 bit）分为一组，每组拆分为 4 个 6 bit 的值，每个 6 bit 值对应一个可打印字符。当字节数不是 3 的倍数时，用等号填充。编码后的数据体积会增加约 33%。

使用说明

1. 输入文本 — 在输入框中输入你想要编码或解码的文本内容，支持中文、英文、符号等所有字符
2. 编码 — 点击「编码」按钮将普通文本转换为 Base64 格式的字符串
3. 解码 — 点击「解码」按钮将 Base64 字符串还原为原始文本内容

Base64 一次完整转换过程

Base64 不是加密，而是一种把二进制数据映射为可打印字符的编码规则。它使用 A-Z、a-z、0-9、+、/ 共 64 个字符，并用等号表示末尾填充。编码时，原始字节每 3 个被切分为一组，每组 24 位再拆成 4 个 6 位片段，最后从字符表中取出对应字符。

以文本 Hi 为例：它的 UTF-8 字节是 48 69，只有 2 个字节，不够 3 的整数倍，因此末尾会补 1 个等号，得到 SGk=。输入内容越长，编码过程越接近每 3 个字节变成 4 个字符，所以输出体积固定增加约 33%。理解这一点，就能解释为什么 Base64 不适合压缩，也不会让数据变小。

常见用途与使用场景

1. 网页内嵌小图片 — 把几 KB 的图标转为 Base64 放进 CSS 或 HTML，减少一次网络请求；大图不建议这样做
2. JWT 中间部分查看 — JWT 的 Header 和 Payload 都是 Base64URL 编码，解码后可快速检查过期时间、用户身份和权限字段
3. HTTP Basic 认证调试 — 用户名与密码拼接后使用 Base64 编码放入 Authorization 请求头，注意它本身没有保密能力
4. 小型二进制入库 — 当数据库只支持文本字段时，可把小型文件转为 Base64 存储；应同时记录原始类型和大小
5. 接口联调 — 某些旧接口要求以文本形式传递二进制内容，Base64 是最通用的中间格式

解码失败应该怎么排查

1. 先确认字符串中没有多余换行、空格或 MIME 前缀，例如 data:image/png;base64, 需要先去掉前缀再解码
2. 检查长度是否为 4 的倍数，缺少等号时先补齐再解码
3. 确认原内容在编码前使用 UTF-8，解码后也使用 UTF-8 还原
4. 如果结果包含乱码，尝试先 Base64 解码，再检查字节编码是否与预期一致

Base64 与加密的区别

加密需要密钥，并且没有密钥无法还原；Base64 不需要任何密钥，任何拿到字符串的人都能立即解码。不要把密码、身份证号、银行卡号或访问令牌用 Base64 保存和传输。即使肉眼看起来不可读，它也只相当于给内容换了一套字符表示方式，不提供任何安全保护。

什么时候不要使用 Base64

• 文件大于几 MB 时，传输和内存开销明显增加，应使用二进制上传或分片上传
• 内容本身已经是文本时，直接传输文本即可，不需要额外编码
• 需要保密时，应使用 HTTPS 和 AES、RSA 等真正的加密方案
• 需要在 URL 中使用时，应选择 Base64URL 变体，避免 + 和 / 产生歧义

使用本工具的最佳流程

先明确当前文本是否包含中文，再选择编码或解码。工具统一按 UTF-8 处理，中文编码后不会乱码。复制结果前可以点击清空重新输入，避免历史内容与当前内容混淆。对于包含换行的长文本，建议先在文本统计工具中查看字符数，再决定是否需要分段处理。

安全与隐私说明

本工具全部在浏览器本地运行，输入文本不会上传到服务器。粘贴的密钥、令牌、接口参数等敏感内容只会停留在当前页面，关闭后即被清除。页面会加载 Google AdSense 脚本，但广告服务不会读取输入框内容；仍然建议不要在生产环境页面中粘贴长期有效的敏感凭据。

编码长度与文件体积的估算方法

Base64 将每 3 个原始字节变成 4 个字符，因此输出长度通常按 4 × ceil(字节数 ÷ 3) 计算，体积约为原来的 133%。这些字符再经过 UTF-8 文本存储时仍占字节，所以接口 JSON、数据库文本列和日志都会因此变大。看到 1 MB 文件变成约 1.33 MB 是规则使然，不是工具额外添加了数据。

原始字节	标准 Base64 长度	填充等号	是否适合内嵌 HTML
1	4	2 个	仅限非常小的数据
2	4	1 个	仅限非常小的数据
3	4	0 个	取决于总大小
300	400	0 个	通常不建议
3 MB	约 4 MB	0 或按余数	不建议，应直接传文件

Base64URL 与标准 Base64 的转换

JWT、URL 参数和文件名场景常使用 Base64URL。它把 + 换成 -，把 / 换成 _，通常还会去掉末尾等号。反向处理时先替换回标准字符，再按 4 的倍数补齐等号。不要直接把 JWT 片段粘贴到只接受标准 Base64 的解码器中，否则可能因为字符集或填充不匹配而失败。

常见疑问速答

Base64 字符串一定以等号结尾吗？不一定。只有原始字节数不是 3 的倍数时才会出现等号，等号数量只能是 0、1 或 2。没有等号不代表错误。

为什么有的 Base64 里包含减号和下划线？那是 Base64URL 变体，用于 URL 和令牌场景。标准解码器通常不能直接处理这种变体，需要先替换字符并补齐等号。

中文 Base64 编码后为什么那么长？一个常用汉字在 UTF-8 中占 3 字节，编码成 Base64 后大约对应 4 个字符，所以中文内容的编码结果会比原文长很多。

解码得到乱码怎么补救？先确认原文本编码：如果原文是 UTF-8，解码后的文本也必须按 UTF-8 展示。不要用 GBK 解码 UTF-8 内容，否则会得到无法还原的乱码。

常见应用场景

• 在 HTML 中嵌入图片 — 将小图标或图片转换为 Base64 字符串，直接写在 img 标签的 src 属性中，减少 HTTP 请求数
• API 数据传输 — 在 JSON 格式的 API 请求中传输小型二进制文件，如头像图片、二维码截图等
• JWT 编解码 — JSON Web Token 的 Header 和 Payload 部分使用 Base64 编码，可以用此工具解码查看内容
• 基本认证 — HTTP Basic Auth 的用户名和密码组合使用 Base64 编码传输
• 数据存储 — 将二进制数据以 Base64 字符串形式存入数据库或文本文件

常见问题

Q: Base64 是加密吗？

不是。Base64 是一种编码方式，不是加密算法。任何人都可以轻松解码 Base64 字符串读取原始内容，不要用它来保护敏感数据。

Q: 为什么解码后出现乱码？

通常是编码时使用的字符集和解码时使用的字符集不一致导致的。本工具统一使用 UTF-8，可以避免这类问题。

Q: Base64 编码后的字符串末尾为什么有等号？

当原始数据的字节数不是 3 的倍数时，编码结果末尾会用 1 到 2 个等号填充，这是标准 Base64 的规范行为。