标准 Base64 和 Base64URL 在核心算法上完全一致：都读入二进制数据，把比特重新切成六位一组，再映射到一张六十四字符的表上。它们的输出往往几乎一模一样。差别集中在三个字符上，但正是这几个字符，决定了结果放进 URL 里是否还能安然无恙。

标准 Base64 为何在 URL 里显得别扭

标准字符表里包含 + 和 /，并用 = 做填充。这些字符本身没有错，但每一个在常见的 Web 语法里都已经各有用途：斜杠用来分隔路径片段，加号在表单式查询解析里可能被当成空格，等号则用来分隔参数名和参数值。把标准 Base64 不加转义地塞进 URL，应用还没拿到数据，值就可能已经被改掉了。

百分号编码能解决这个问题，但它会让结果更长，还引入了另一道每个生产方和消费方都得一致处理的变换。Base64URL 正是为了消除这种摩擦而生：它把加号换成连字符、斜杠换成下划线，并且通常省略填充，因为解码器可以根据长度推断或补回。

两张字符表的对照

对大多数输入而言，两种变体产出的字符完全相同，因为字母和数字在两张表里占据着相同的位置。只有当某个六位组恰好落到最后两个符号上时，才会出现可见差异：标准 Base64 给出 + 或 /，而 Base64URL 给出 - 或 _。如果标准输出带有填充，无填充的 Base64URL 通常会去掉末尾的等号。

这种高度相似既方便又容易藏 bug。开发者可能用一个只含共有字符的值做测试，便断定两个解码器都没问题。故障会推迟到生产环境才暴露——某个输入终于产生了斜杠或加号的那一刻。针对编码边界的测试，应该刻意包含能触发差异符号和填充规则的取值。

JWT 是最常见的 Base64URL 场景

一个 JSON Web Token 由三个用点号分隔的片段组成：头部、载荷和签名。每个片段都使用 Base64URL，因为令牌经常出现在 HTTP 授权头、Cookie 和链接里。对某些头部或载荷来说，标准 Base64 编码器看起来似乎也能用，但它就是错误的格式，可能生成不兼容的令牌。

需要强调的是，Base64URL 并不能让 JWT 的声明变得私密。任何拿到令牌的人都能解码出头部和载荷。真正让服务端能察觉篡改的是签名；当声明必须保密时，则需要使用加密。URL 安全编码所做的，仅仅是让令牌片段便于传输。

填充是策略选择，而非未解之谜

标准 Base64 通常带填充，使编码输出的长度能被四整除。Base64URL 的规范则往往允许甚至要求无填充输出。一个健壮的解码器可以根据编码长度算出缺了几个等号，在内部补回，再替换掉 URL 安全符号，最后调用标准解码原语。

问题往往出在两端对"严格程度"的理解不一致：一个解码器既接受带填充也接受不带填充的形式，另一个却完全拒绝填充。协议应当明确规定哪种表示是规范形式。签名对此尤其敏感，因为同一段字节的两种文本表示终究是两个不同的字符串，验证方必须针对协议要求的那种精确表示来操作。

如何选对变体

当外层格式明确要求标准 Base64 时就用它。MIME 邮件附件、PEM 块以及许多既有接口都定义了标准 Base64，不应被悄悄改掉。而当编码数据必须直接出现在 URL、文件名、Cookie 值，或某个指定了 URL 安全字符表的令牌格式中时，则应使用 Base64URL。

不要仅仅因为应用恰好跑在 Web 上，就一律选择 Base64URL。一个 JSON 接口字段完全可能定义为标准 Base64，哪怕整个请求是经由 HTTP 传输的。字段本身的契约，比整个请求所用的传输方式更重要。

避免意外的几个互操作习惯

在每个编码字段旁边写清楚期望的字符表和填充行为。给工具函数起精确的名字：encodeBase64Url 比泛泛的 encode 传达的信息多得多。遇到格式错误的输入应当拒绝，而不是默默丢弃意外字符。再配上往返测试和取自相关规范的已知样例。

排查故障时，要检查字符串在每道边界前后的样子。查询解析、URL 解码、表单处理以及框架中间件，都可能在业务代码运行前就改写了某个加号或百分号转义。把两端的精确字节拿来对比，通常就能看清问题到底属于 Base64、URL 解析，还是协议契约本身的不一致。