Base64 编码 / 解码

中文文本怎么编码

工具先把文本转成 UTF-8 字节，再做 Base64。常用汉字在 UTF-8 里占 3 个字节，正好对应 4 个 Base64 字符，所以纯中文的结果长度通常是汉字数乘以 4。

输入 你好，世界（5 个字符，含一个全角逗号，共 15 字节），Standard 模式输出 5L2g5aW977yM5LiW55WM，正好 20 个字符，末尾没有 =。

中英文混排时字节数不一定是 3 的倍数。Base64 编码 是 6 个 ASCII 字节、1 个空格和 6 个汉字字节，共 13 字节，输出 QmFzZTY0IOe8lueggQ==，末尾补了两个 =。

两种字母表只差三个字符。测试 在 Standard 模式下是 5rWL6K+V，切换到 URL-safe 后：

输出变成 5rWL6K-V，+ 换成了 -。这样的字符串可以直接放进 URL 的查询参数或路径，不用再做百分号编码。反过来，把 5rWL6K-V 放回 Standard 模式解码会失败：

状态行显示 第 7 个字符：“-”属于 URL-safe 字母表，请切换到 URL-safe 再解码。，切换后即可解出。规则见 RFC 4648 第 5 节。

GBK 系统给的 Base64 为什么解不出来

一些老系统或数据库按 GBK 存文本，再把字节做成 Base64 传过来。同样是“你好”，两种编码的字节不同，Base64 也不同：UTF-8 是 5L2g5aW9，GBK 的字节是 C4 E3 BA C3，Base64 是 xOO6ww==（可以用 Python 的 base64.b64encode('你好'.encode('gbk')) 核对）。

把 xOO6ww== 粘到解码框，工具不会显示乱码，而是报 解码后的第 1 个字节（C4）不是有效的 UTF-8。解码结果只显示 UTF-8 文本，二进制数据和 GBK 等编码的文本无法在这里显示。：这串 Base64 本身没错，问题出在解出来的字节。第 1 个字节 C4 在 UTF-8 里是双字节字符的开头，后面应当跟 80–BF 之间的字节，实际跟的是 E3。本工具只按 UTF-8 输出文字，GBK、GB18030 这类旧编码需要在你自己的程序里先按原编码解码。

被截断的 emoji

前端用 slice() 截取字符串时，可能把一个 emoji 从中间切开，只留下一半（孤立的代理项）。这种文本无法转成 UTF-8，工具会指出位置：

输入“你好”加半个 emoji，状态行显示 第 3 个字符：孤立的代理项（emoji 等字符的一半）无法编码为 UTF-8。。位置按字符计算，一个完整的 emoji 算 1 个字符。

解码时可以省略的东西

• 末尾的 = 可以不写。5L2g5aW977yM5LiW55WMIQ 去掉了两个 =，照样解出 你好，世界!。浏览器的 atob() 遵循 WHATWG 的 forgiving-base64 decode，不强制填充。
• 换行、制表符和空格会被忽略，Standard 与 URL-safe 两种模式相同。从邮件原文复制的 Base64 每 76 个字符换一行，可以原样粘贴。例如在 URL-safe 模式下，5rWL 换行后接 6K-V，照样解出 测试。
• URL-safe 模式也能读 Standard 字符串，因为它只是把 - 和 _ 换回 + 和 /。

限制

• 解码结果只显示 UTF-8 文本，不能还原成图片或其他文件。
• 字符串中间出现 =，或者按 4 个字符分组后多出 1 个字符，都会报错，状态行写出 = 的位置或字符个数。例如复制时少了几个字符的 5L2g5，会提示 共 5 个 Base64 字符，按 4 个一组后多出 1 个。字符串可能被截断，或多了一个字符。
• 文件编码没有固定上限。超过 5 MiB（5,242,880 字节）时状态行提示 文件较大，编码可能需要几秒。，整个文件和结果都放在内存里，文件太大会让页面变慢。
• Base64 只是编码，不是加密，任何人都能解开。需要保密的内容请用 AES 加密工具。

常见使用场景

• API 认证： HTTP Basic 认证把 用户名:密码 做成 Base64 放进请求头（RFC 7617），完整请求头可以用 Basic Auth 请求头生成器生成。
• Data URI： CSS 和 HTML 里内联的图片、字体是 Base64。图片请用图片转 Base64，它能按文件内容判断类型。
• JWT： Header 和 Payload 两段是不带填充的 URL-safe Base64，解码时选 URL-safe。
• 邮件： MIME 附件用 Base64 传输，非 ASCII 的邮件标题也可以用 Base64（RFC 2047 的 B 编码）。