Base64url 编码 / 解码器

Base64url 与 Base64 的区别

Base64url 是 RFC 4648 第 5 节定义的 URL 与文件名安全字母表。它保留普通 Base64 的 6 位分组，只把 + 替换为 -，把 / 替换为 _，减少这些字符在 URL、表单、路径和 shell 中的特殊含义。

填充是独立问题。普通 Base64 常用等号补到 4 的倍数，许多 Base64url 协议因为外层结构已知长度而省略填充。本页编码可选保留或删除，解码接受两种合法形式。

本页以文本为目标：Unicode 先编码为 UTF-8，恢复字节必须是有效 UTF-8。签名、压缩内容、密钥和图片等任意二进制应在代码中保留为字节。

如何使用 Base64url 转换器

1. 普通文本选择编码，已有 URL 安全 Base64 选择解码。
2. 编码时按目标协议决定填充，例如 JWT 段通常无填充。
3. 连续粘贴内容，不要包含空格；仅允许字母、数字、-、_ 和合法末尾等号。
4. 与普通 Base64 比较时重点检查 -、_；+、/ 会被严格拒绝。
5. 往返验证 UTF-8 后，仍需单独执行协议解析、签名和字段校验。

Base64url 示例与字母表差异

很多纯文本向量与普通 Base64 看起来相同，因此示例同时展示能产生斜杠和加号的字节，并把填充策略单独说明。

字母表、填充与有效长度

URL 安全字母表由字母、数字、连字符和下划线组成。等号只能在末尾出现一到两个；空白不会自动清理。

无填充长度模 4 只能是 0、2 或 3，余数 1 不可能形成完整字节。有填充时数量必须精确恢复四字符分组。

• 普通 Base64 的 + 在此应为 -。
• 普通 Base64 的 / 在此应为 _。
• 填充可选，但出现时必须结构正确。
• 加号、斜杠、中间等号和空白都会报错。
• 最后量子的未使用低位必须为零。

Base64url 如何转换 UTF-8 字节

编码器每次读取三字节共 24 位，拆成四个 6 位值。Base64url 只改变索引 62 和 63 的符号。尾部一到两字节用零完成临时分组，并可用等号标记缺少的输出字节。

无填充输出只删除末尾等号，不删除数据字符。解码按长度计算隐含填充，把 -、_ 映射回标准字母表，恢复字节并检查未使用位为零。

最后使用严格 UTF-8 解码，避免损坏字节被替换字符掩盖。合法 Base64url 字节序列与合法 Base64url 文本是两个不同条件。

Base64url 的常见用途

它适合在 URL 安全文本字段中承载二进制或结构化数据，但不提供保密性或真实性。

Base64url 错误与协议边界

最常见问题是直接把普通 Base64 交给 Base64url 解析器。原始编码层可能只需替换字符，但上层仍必须明确是否允许填充以及字节的含义。

成功解码也不代表可信。例如展示 JWT 负载不会验证签名、发行者、受众、过期时间或算法。

• 长度模 4 为 1 时非法。
• 中间填充或过多填充非法。
• 普通 Base64 的 +、/ 不会被静默修正。
• 恢复的二进制可能不是 UTF-8。
• Base64url 可逆，绝不是加密。

Base64url、Base64 与 URL 编码

普通 Base64 和 Base64url 表示相同 6 位数值，只差两个字符。URL 百分号编码解决的是 URL 组件保留字符问题，并不把任意二进制变为紧凑字母表。

十六进制更直观且无填充，但长度翻倍；Base58 更适合人工抄写，却不是主流 Web 协议标准。