Base64编码与解码

Base64 由 RFC 4648 定义，用 64 个可打印 ASCII 字符来表示任意字节：A–Z、a–z、0–9、+ 和 /。每 3 个字节（24 位）会被拆成 4 个 6 位数字，每个数字对应字符表中的一个字符。当输入长度不是 3 的倍数时，最后一组会用一个或两个 = 补位。结果总是比输入大约多 33%：每 3 个字节对应 4 个字符。

它的存在，是因为许多传输渠道原本只为文本设计。电子邮件（MIME）、HTML 和 CSS 中的 data: URL、携带图片或证书的 JSON 字段，以及 HTTP Basic 认证头，都用 Base64 来安全地传输二进制数据。它不是加密，也不会隐藏任何内容，解码不需要密钥。

Base64 编码的是字节而不是文字，所以文本必须先转换成字节。本工具始终使用 UTF-8，这是网络通用的编码：é 会变成两个字节，一个 emoji 则是四个字节。浏览器内置的 btoa 函数遇到 U+00FF 以上的任何字符都会报错，这就是简单的编码器处理带重音字符和 emoji 时会失败的原因；这里文本会先经过 TextEncoder 处理，解码时再用 TextDecoder 还原。如果解码出的字节不是有效的 UTF-8（例如图片、zip 文件），工具会以十六进制显示，而不是显示乱码。

标准 Base64 使用的 + 和 / 在 URL 和文件名中有特殊含义。RFC 4648 第 5 节的 URL 安全字符表把它们替换为 - 和 _，并且通常省略补位符。JSON Web Token 使用的正是这种形式。解码器同时支持两种字符表，也允许缺少补位符，所以你可以任意粘贴其中一种。

选择一个文件，工具会用 FileReader 在本地读取，并返回它的 Base64，或者带有该文件 MIME 类型的完整 data: URL，可直接粘贴到 img 标签或 CSS 背景中。内嵌图片能省掉一次 HTTP 请求，但体积会增加三分之一，而且无法单独缓存，因此适合小图标，不适合照片。如果需要图片预览以及现成的 HTML 和 CSS 代码片段，请使用图片转 Base64。