如何使用 Base64 编码解码工具
- 选择编码把文本转换为 Base64，或选择解码把 Base64 还原为文本。
- 粘贴您的输入内容。文本按 UTF-8 处理，所以带重音的字母、非拉丁文字和表情符号都能正确处理。
- 如果结果要用在 URL、文件名或 JWT 中，请启用 URL安全 选项。
- 复制输出结果。
编码和解码都在您的浏览器本地完成；您粘贴的任何内容都不会被上传或存储。
Base64 的工作原理
Base64 由 RFC 4648 定义，用 64 个可打印的 ASCII 字符表示任意二进制数据：A–Z、a–z、0–9、+ 和 /。它的作用是让二进制内容能安全地通过为文本设计的系统传输，例如电子邮件、JSON、XML 和 HTTP 头。
算法每次读取 3 个字节（24 位）输入，并把它们拆分成四组 6 位。每个 6 位的值（0–63）从字母表中选出一个字符。以单词 Man 为例说明这个过程：
| 步骤 | 值 |
|---|---|
| 字节 | M=77, a=97, n=110 |
| 24 位 | 01001101 01100001 01101110 |
| 6 位分组 | 010011 010110 000101 101110 = 19, 22, 5, 46 |
| Base64 | TWFu |
由于每 3 个字节会变成 4 个字符，Base64 输出比输入大约大 33%（如果 MIME 等格式插入换行符，还要再加上换行）。
用 = 填充
当输入长度不是三的倍数时，最后一组会被填充。剩下一个字节时生成两个字符加 ==；剩下两个字节时生成三个字符加 =。例如，Hi 编码后是 SGk=。
URL 安全的 Base64
标准的 + 和 / 字符在 URL 和文件路径中有特殊含义。RFC 4648 第 5 节定义了 base64url 字母表，用 - 和 _ 替换了它们。填充通常会被省略。JSON Web Token（JWT）使用不带填充的 base64url。
标准： +/8=
URL安全： -_8常见陷阱
Base64 不是加密
任何人都能立即解码 Base64；它没有密钥。切勿用它来“隐藏”密码或 API 密钥。完整性校验请使用哈希生成器生成的哈希值，保密则请使用真正的加密。
JavaScript 中的 UTF-8
浏览器内置的 btoa() 只接受 Latin-1 范围内的字符，遇到其他字符就会报错。请先把文本转换为 UTF-8 字节：
btoa("✓"); // InvalidCharacterError
const bytes = new TextEncoder().encode("✓");
btoa(String.fromCharCode(...bytes)); // "4pyT"混用字母表
用严格的标准解码器解码 base64url 数据时，会因为遇到 - 和 _ 或缺少填充而失败。解码前请先转换字母表，并重新补齐填充，使长度为四个字符的倍数。
在哪些地方会遇到 Base64
- Data URI 把小文件直接嵌入 HTML 或 CSS：
data:image/png;base64,iVBORw0KGgo... - HTTP Basic 认证发送经 Base64 编码的
username:password。user:pass会变成Authorization: Basic dXNlcjpwYXNz，这很容易还原，所以 Basic 认证只能在 HTTPS 下使用。您可以用 HTTP响应头检测工具查看这类请求头。 - 电子邮件附件（MIME）以及 PEM 格式的证书和密钥。
- JWT，其 header 和 payload 是经 base64url 编码的 JSON。可以用 JWT解码器读取它们。
printf 'text' | base64 用于编码，base64 -d 用于解码（较旧版本的 macOS 使用 -D）。请使用 printf 或 echo -n，以免末尾的换行符也被编码进去。常见问题
为什么我的 Base64 字符串以 = 或 == 结尾？
那是填充。当输入长度不能被三整除时，它告诉解码器最后一组包含几个字节。
Base64 安全吗？
不安全。它是一种编码，不是加密。它完全不提供保密性；只是让二进制数据能够以文本形式安全传输。
为什么编码后的输出比输入大？
每个 Base64 字符只携带 6 位而不是 8 位，所以 3 个输入字节需要 4 个输出字符，开销约为三分之一。
Base64 和 base64url 有什么区别？
只有两个字符不同：base64url 用 - 和 _ 代替 + 和 /，并且通常省略 = 填充，所以结果无需再转义就能放进 URL。
更新于