首页文本与开发 › Base64 编码 / 解码

Base64 编码 / 解码

文本与 Base64 互转,正确处理中文等 UTF-8 字符,可选 URL-safe(- _ 无填充)变体。

Base64 是什么,不是什么

Base64 是一种把任意二进制数据表示成 64 个可打印 ASCII 字符(A–Z、a–z、0–9、+、/)的编码方式:每 3 个字节(24 位)拆成 4 组 6 位,每组对应一个字符,不足 3 字节时末尾用 = 填充。因此编码后体积固定增加约 1/3(每 3 字节变 4 字符),一张 300KB 的图片转成 Base64 约 400KB。

Base64 不是加密,任何人都可以瞬间解码,不能用来保护密码或敏感信息;它解决的是“在只允许文本的地方传输二进制”的问题。常见用途包括:网页中的 data URI(把小图标直接写进 CSS 或 HTML,形如 data:image/png;base64,…),邮件附件(MIME),HTTP Basic 认证头,JSON 里传输文件内容,以及 JWT 令牌的头部和载荷(用的是 URL-safe 变体)。

中文处理与 URL-safe 变体

浏览器自带的 btoa 只接受单字节字符,直接对中文调用会报错。本工具先用 TextEncoder 把文本转成 UTF-8 字节,再编码;解码时反向用 TextDecoder 还原,所以中文、emoji 都能正确处理。在旧浏览器上则回退到 encodeURIComponent 与 unescape 的组合技巧。请注意其他系统若使用 GBK 编码,同一段中文得到的 Base64 会不同。

标准 Base64 中的 + 和 / 在 URL 和文件名里有特殊含义,= 也会被 URL 编码,所以 RFC 4648 定义了 URL-safe 变体:用 - 代替 +,_ 代替 /,并省略末尾的 =。JWT、部分 OAuth 参数和短链接都采用这种形式。本工具解码时自动兼容两种写法并补齐填充。解码结果若不是合法 UTF-8 文本(例如它本来是图片),会提示失败,这类数据应交由文件工具处理。

常见问题

Base64 能当加密用吗?

不能。它只是编码,没有密钥,任何人都能解码。需要保密请使用 AES 等真正的加密算法,Base64 只负责把加密后的字节变成文本。

为什么编码后有一个或两个等号?

= 是填充符。原文字节数除以 3 余 1 时补两个 =,余 2 时补一个,整除时没有。URL-safe 变体通常省略它。

解码出来是乱码怎么办?

多半是原文不是 UTF-8 编码(如 GBK),或者内容本身是图片等二进制数据。前者需按原编码解码,后者应保存为文件。

图片转 Base64 会更快吗?

不会更快,反而大 1/3 且无法被浏览器单独缓存。只建议对几 KB 的小图标使用,减少一次请求。