悦省yueser.com

← 全部指南

Base64 编解码:中文与 emoji 不乱码

把文本粘进去,点「编码」得到 Base64;把 Base64 粘进去,点「解码」还原文本。工具内部先把文本转成 UTF-8 字节再编码,所以中文和 emoji 不会像直接用 btoa() 那样报错或乱码。

打开工具:Base64 编解码

什么时候真的需要 Base64

要把一段含中文或 emoji 的文本放进只接受 ASCII 的字段:HTTP header、某些配置项、只允许可打印字符的协议字段。Base64 把任意字节映射成 64 个安全字符。

收到一串 Base64,想判断它解码后是可读的 UTF-8 文本,还是本来就只是二进制乱码。解出来是 � 通常说明原始字节不是 UTF-8。

调试 JWT、Basic Auth、data URL 里的 payload 段:这些格式的载荷都是 Base64 或 Base64URL,先解码才能看内容。注意 JWT 用的是 Base64URL,字符集和填充规则略有不同。

怎么做才不出错

不要直接把 JavaScript 字符串交给 btoa()。btoa() 只接受每个字符在 0–255 范围内的「二进制字符串」,遇到中文会抛 InvalidCharacterError。正确顺序是 TextEncoder 编码成 UTF-8 字节,再逐字节 btoa();解码时 atob() 得到字节,再用 TextDecoder('utf-8') 还原。

体积会变大,约三分之一。Base64 把每 3 个字节编成 4 个 ASCII 字符,长度变成 4/3;字节数不能被 3 整除时末尾补 =。按 UTF-8 算,一个汉字 3 字节,编码后约 4 个字符;一个 emoji 通常 4 字节,编码后约 8 个字符(含填充)。这是编码开销,不是压缩。

解码时空白会被忽略,但 Base64 字母表以外的字符会报错。如果字符串里混进了换行、空格之外的符号,先清掉再解。

非 UTF-8 的 Base64 解出来会出现 �(U+FFFD)。这不是工具坏了,而是原始字节不构成合法 UTF-8;图片、压缩包这类二进制内容本来就不该按文本解。

放进 URL 时要换成 Base64URL:把 + 改成 -、/ 改成 _,并去掉末尾的 =。标准 Base64 的 + 在 query string 里可能被解码成空格(表单规则把 + 当空格),/ 也可能和路径冲突。

最后,Base64 不是加密。它没有密钥,任何人拿到都能解码;用它「隐藏」密码或 token 只是换了个壳。需要保密就用 AES-GCM 这类真正的加密,需要完整性就用签名或哈希。

替代方案与局限

二进制文件(图片、PDF、压缩包)不要用文本工具转:命令行 base64、macOS 的 base64 -i、Windows 的 certutil -encode,或代码里读 ArrayBuffer 再编码,才能保证字节原样。

要加密用 WebCrypto 的 AES-GCM,要签名用 HMAC 或非对称签名;Base64 只负责「把字节变成安全字符」,不提供任何安全性。

本工具只处理文本:编码时按 UTF-8 解释输入,解码时按 UTF-8 还原,二进制字节无法原样保留;也没有流式处理,超大文本会占用较多内存。

常见问题

Base64 为什么体积变大?

因为它把每 3 个字节换成 4 个 ASCII 字符,长度变成原来的 4/3,也就是大约增大三分之一。字节数不能被 3 整除时,末尾会补一个或两个 =。按 UTF-8 算,一个汉字通常 3 字节,编码后约 4 个字符;一个 emoji 通常 4 字节,编码后约 8 个字符(含填充)。

Base64 是加密吗?

不是。Base64 是可逆编码,没有密钥,拿到字符串的人都能解码。它既不隐藏内容,也不验证来源。要保密得用 AES-GCM 这类真正的加密,要防篡改得用签名或哈希。Base64 只解决「字节怎么通过纯文本通道」这一个问题。

能编码图片或 PDF 文件吗?

不能。本工具只接受文本:编码时 TextEncoder 把输入当 UTF-8 文本处理,二进制文件的字节不会原样保留;解码时非 UTF-8 的字节会被替换成 �(U+FFFD),原文件就损坏了。文件转 Base64 请用系统命令(macOS/Linux 的 base64、Windows 的 certutil)或支持二进制读取的工具。

相关工具:Base64 编解码