Base64 与 Base64URL：padding、JWT 三段与 PEM 换行

症状：都像 Base64，每个工具却各解各的

把 JWT 的一段丢进「普通 Base64」框，解出来是乱码；或 PEM 被「去掉换行整理」之后突然解不开。字节往往没坏——方言错了。标准 Base64（RFC 4648 §4）、Base64URL（RFC 4648 §5 / JWT）和 PEM（RFC 7468）都长得像 Base64，但在两个字符、末尾 =，以及是否允许空白上并不一致。

需要往返编解码时用站内 Base64 编解码（打开 URL 安全开关）；字符串里有两个点用 JWT 解码器；看到 BEGIN CERTIFICATE 用 证书解码器。

码表与 padding 一张表

互转是机械的：

• 标准 → URL 安全：+→-，/→_，去掉 =
• URL 安全 → 标准：反向替换两个字符，再把长度补到 4 的倍数（加 =）

解码后的字节长度由原始字节数决定，不取决于有没有把 = 写出来。缺 = 不等于损坏——前提是码表对、长度能补齐。

JWT 为什么拒绝 +、/ 和 =

紧凑 JWT 是三段 Base64URL，用 . 拼接：

base64url(header) + "." + base64url(payload) + "." + base64url(signature)

这段字符串常进 query 或 Authorization 头，不能带上 URL 语法敏感字符：+ 在 application/x-www-form-urlencoded 里可能变空格；/ 会切路径；= 是 query 赋值符。Base64URL 去掉这些地雷，让 token 能当一整段不透明字符串传输。

排查时记住：

1. 一次只解一段，用认识 Base64URL 的工具，或在 Base64 页打开 URL 安全。把整段 a.b.c 丢进 MIME Base64 解码器会因点号失败。
2. Header / Payload 解出来是 JSON 文本；Signature 是二进制，指望它是可读 JSON 属于类别错误。
3. JWT 不是加密。Base64URL 只是让内容不那么「一眼可读」。拿到 token 就能看 claims。字段语义见 JWT 解码指南 与 exp/nbf 时钟漂移。

看起来像「非法 token」的 padding 坑

库对「调用 atob / b64decode 前要不要补 =」并不统一。常见耗时模式：

• 代理剥掉了标准 Base64 字段里的 =。本地 curl 还有 padding，网关后没有。
• 一端 URL 安全、一端标准。 密钥没错也会验签失败——参与签名的字符串已经对不上。相关：JWT 签名无效。
• 手工「修复」：给已经能解的 Base64URL 段乱加 ==。错误长度的 padding 会直接抛错；正确补法是让 len % 4 === 0，补 '' / '=' / '==' 三种之一。

速查：对 URL 安全段 s，算 pad = (4 - (s.length % 4)) % 4，补上对应个 =，把 -_ 映回 +/，再解。若 JSON 正常，说明原 token 没问题——是第一只解码器不懂 Base64URL。

PEM：码表跟标准 Base64 一样，包装不同

PEM 把 DER（二进制 ASN.1）包成：

-----BEGIN CERTIFICATE-----
<通常每行 64 列的 Base64>
-----END CERTIFICATE-----

和 JWT 对照：

常见「不是密码学坏了」的 PEM 故障：

• 有人把所有行拼成超长一行：宽松消费者接受，严格消费者拒绝。粘进配置时尽量保留 RFC 风格换行。
• 复制时带上 UTF-8 BOM 或中文引号包住标签。
• 只贴了叶子证书，服务器还需要中间证书——那是链问题，不是 Base64 问题。见 证书链不完整排查 与 证书解码指南。

OpenSSL 心智模型仍然好用：PEM → DER 字节 → 解析字段。站内证书工具回答「这张 PEM 写了什么」，不替代 openssl verify 做信任决策。

决策树：先开哪个工具？

1. 字符串有两个点、三段 → JWT 解码器。不要整段做 MIME Base64。
2. 有 BEGIN … / END … → 证书解码器。保留换行。
3. 码表含 - 或 _ 且无 PEM 标签 → 当 Base64URL；在 Base64 开 URL 安全。
4. 码表是 +/，可有可无 = → 标准 Base64（API 字段、data URI、多数密码库）。
5. 字节已成功解出，但中文花屏 → 字符集不一致（UTF-8 vs GBK），不是码表问题。见 Base64 中文乱码。

实现注记

站内 Base64 页经 TextEncoder / TextDecoder 走 UTF-8，再套所选码表与 padding。URL 安全模式只改字符映射与填充，不改 Unicode 语义。JWT 是另一条路径：按 . 切开、逐段 Base64URL、claims 做无损 JSON（大整数仍可读）。证书路径剥标签、忽略正文空白、标准 Base64 → DER，再在浏览器里走 ASN.1 子集。以上路径都不上传材料。

五分钟清单

1. 数点号：零（整块）、两个（JWT），还是 PEM 标签？
2. 看第 62/63 字符：是 +/ 还是 -_？
3. = 是 JWT 故意省略，还是被代理剥掉？
4. PEM：换行与 BEGIN/END 是否完整？
5. 字节已经干净之后，剩下的失败是 JSON claims、签名密码学，还是 TLS 信任？

相关阅读

• Base64 编码详解
• JWT 详解：结构与安全实践
• JWT exp/nbf 时钟漂移
• 在线证书解码指南
• 证书链不完整排查

本文由 ToolVault 工具匣 提供。更多开发者工具请访问 首页。