Base64URL 编码指南：放进链接和 JWT 的那种 Base64

标准 Base64 里的 + 和 / 在 URL 里有特殊含义，直接拼进链接会被转义或截断；Base64URL 就是为此做的替换，算法本身没变。

什么时候非它不可

把一段二进制或 JSON 塞进查询参数、路径片段、文件名，或者参与 OAuth 的 state、PKCE 的 code_verifier，都必须用 URL 安全字母表。否则 + 会被服务端当成空格，/ 会被当成路径分隔符，数据在到达之前就坏了。

JWT 是最常见的例子：header 和 payload 都是 Base64URL 编码的 JSON，三段用点连接。签名段同样用这套字母表，所以整个 token 可以直接放在 Authorization 头或 URL 里。

编码前先按 UTF-8 取字节，再做 Base64，最后把 + 换成 -、/ 换成 _，并删掉末尾所有 =。顺序反了或者只替换一部分，解出来就是错的。填充符去掉是因为 = 在 URL 里也需要转义，而长度可以靠补回来。

体积会涨到约 4/3，这是 Base64 的固定开销，不是工具多做了什么。编码后的字符串只含 A–Z、a–z、0–9、- 和 _，可以安全地放进 URL，不需要再套一层百分号编码。

Base64URL 不是加密，没有密钥，任何人拿到都能还原。JWT 的 payload 只是「编码过」，不是「加密过」，把用户角色、内部 ID 甚至邮箱放进去，等于公开。

签名保证的是完整性——内容被改过就能发现，但它不隐藏内容。需要保密就上 JWE 或直接加密载荷；需要防止篡改，才轮到签名。两者经常一起用，但不能互相替代，把目的分开看会清楚很多。

和普通 Base64 有什么区别？

只差三个地方：+ 换成 -，/ 换成 _，末尾的 = 去掉。解码时反向替换并补齐填充即可。内容完全一样，选择哪种只看使用环境是否对 URL 友好。

为什么要把 = 去掉？

= 是填充符，本身不携带数据，但在 URL 里需要转义，容易在复制、拼接时出问题。去掉后长度仍能推出补几个 =，所以解码端可以无损还原。

JWT 里的内容安全吗？

不安全。payload 只是 Base64URL 编码，任何拿到 token 的人都能读出里面的字段。签名只证明它没被篡改，不提供保密，敏感信息不要放进去。