Base64 和 URL 编码的区别：什么时候该用哪个

Base64 编码和 URL 百分号编码常被混用，但两者解决的问题完全不同。本文讲清各自的使用场景、字符集差异，以及接口对接中同时用到两者的常见情况。

一句话区分

URL 编码解决「这个字符能不能安全放进网址里」，Base64 解决「怎么把任意字节压成一段不破坏传输的文本」。目标不同，规则自然不同。

字符集差异（最直观）

URL 编码的产物只包含这几类字符：A-Z a-z 0-9 - _ . ~，以及被转义后的 %XX。而标准 Base64 的输出包含 + 和 /，以及末尾的 = 补位符。

这意味着：直接把 Base64 结果塞进 URL 是不安全的——+ 在查询串里会被解码成空格，/ 和 = 也会破坏 URL 结构。这就是 Base64URL 变体存在的理由：它把 + 换成 -、/ 换成 _，并去掉末尾补位符。

典型使用场景对照

• URL 编码：把中文、特殊字符塞进查询参数；拼接带非 ASCII 字符的链接。
• Base64：把二进制文件塞进 JSON；JWT 的载荷段；把密钥类文本做传输编码；HTTP Basic 认证头。
• Base64URL：JWT、JWS 这类「Base64 结果要直接放进 URL 或紧凑 JSON」的场合。

常见踩坑：JWT 里的那个下划线

JWT 的三段用 . 分隔，其中头部和载荷段是 Base64URL 编码。如果你把标准 Base64 的 + 解不开、长度对不上，多半是用错了变体。DevKit 的 Base64 工具同时提供 Base64 和 Base64URL 两种模式，遇到 JWT 解析问题可以先用 Base64URL 模式解头部。

为什么它们可以叠加使用

两者并不冲突。常见组合是：先Base64 编码，再对结果做 URL 编码，用于把一段数据安全地放进查询参数。因为 Base64 的输出含 +、/、=，直接放进 URL 会被破坏；做一层 URL 编码后就安全了。解码时顺序相反：先 URL 解码，再 Base64 解码。

一个实用建议

排查这类问题时，先把原始字符串在两个工具里各跑一遍，看它到底是被哪一层编码过的，比读代码猜要快得多。DevKit 的 Base64 和 URL 编解码工具都在浏览器本地运行，可以放心粘贴敏感内容。

常见问题

Base64 是加密吗？

不是。Base64 只是编码，任何人拿到结果都能立刻还原，它不提供任何安全性。真正的加密需要密钥和算法，Base64 只是把二进制数据换成了文本形态以便传输。

Base64 解码出来是乱码怎么办？

常见原因有两个：一是选错了变体（把 Base64URL 当标准 Base64，或反之），二是原文并非Base64 编码而是其他格式。建议先用 Base64URL 模式试一次，再确认原文来源。

URL 编码和 encodeURIComponent 是一回事吗？

思路接近但不完全相同。URL 编码会把 @ : $ , 等保留字符也转义，范围更广；JavaScript 的 encodeURIComponent 只转义非保留字符，且不处理部分字符。处理中文查询参数时两者结果基本一致，但要严格遵循 URL 规范时优先用 URL 编码。