Base64URL 和普通 Base64 混用导致解码失败怎么排查？

先看失败现象

如果同一段内容在某些工具中能解码，在另一些工具中提示非法字符、长度错误或 padding 错误，常见原因是 Base64URL 和普通 Base64 被混用了。

JWT 的 Header 和 Payload 使用 Base64URL，不应直接假设它们一定能被严格普通 Base64 解码器接受。

• 包含 - 或 _ 时优先考虑 Base64URL
• 包含 + 或 / 时更像普通 Base64
• 末尾缺少 = 不一定是错误，可能是省略填充

快速检查清单

先确认字符串来源：如果来自 JWT、URL 查询参数或 Web 安全场景，优先按 Base64URL 处理。然后检查是否被 URL 编码、复制截断或自动换行。

再根据长度补齐填充。Base64 编码长度通常应为 4 的倍数，Base64URL 可能省略等号，但底层解码前仍可能需要补齐。

• 把 - 转回 +
• 把 _ 转回 /
• 按长度补齐 = 填充
• 确认没有混入空格、换行或引号

修复步骤

如果工具支持 Base64URL 模式，优先直接切换模式。若只能处理普通 Base64，可以先把字符替换回普通 Base64，再按长度补齐等号。

如果解码后仍是乱码，问题可能已经从编码变体转向字符集，需要继续检查 UTF-8、GBK 或二进制数据的解释方式。

如何验证修复完成

对 JWT 场景，解码 Header 和 Payload 只能说明格式可读，不能说明 Token 有效。仍需服务端验签并检查 exp、aud、iss 等声明。

对 URL 参数场景，修复后还应确认参数没有被二次编码，避免把 %2B、%2F 或 %3D 当成原始字符直接处理。