加密算法基础95 条

Base64URL 编码

URL 安全变体:用 - 与 _ 替换 + 与 /,通常省略 = 填充;用于 JWT、OAuth 参数与文件名等场景。

加密与证书速查安全更新于 2026-10-13

Base64URL 是什么

Base64URL 是 Base64 的 URL 安全变体(RFC 4648 §5):把标准字母表里的加号与斜杠分别换成短横线与下划线,并通常省略末尾的等号填充。这样编码结果不必再做百分号转义,就能安全地放进 URL、文件名与 JSON 字段。JWT 的 header.payload.signature 三段全部是 Base64URL,OAuth 的若干参数也采用同样编码。

基本信息

与标准差异加号换成短横线、斜杠换成下划线,通常省略填充
标准RFC 4648 §5
典型用途JWT 三段结构、OAuth 参数、URL 内嵌数据、文件名
解码注意需补齐填充后才能按标准 Base64 解码
大小写字母表区分大小写,比较时不能忽略
安全性质只是编码,任何人都能还原,不提供机密性

典型使用场景

  • 解析与校验 JWT:先把三段 Base64URL 解码,再验证签名
  • 实现 OAuth 的 PKCE:code_verifier 与 code_challenge 都用它编码
  • 在 URL 中嵌入二进制参数:避免转义与非法字符带来的麻烦
  • 生成短标识或文件名:用编码结果替代不便直接使用的字符集
  • 对接第三方接口:按对方文档确认填充是被省略还是保留

Python 示例

Python 示例
import base64, json
s = base64.urlsafe_b64encode(b'data?x=1').decode()   # 输出 ZGF0YT94PTE=
# 解码前补齐填充:长度对 4 取模,缺几位补几个等号
raw = base64.urlsafe_b64decode(s + '=' * (-len(s) % 4))
# JWT 拆解:三段都是 Base64URL,先补填充再解码
parts = token.split('.')
payload = json.loads(base64.urlsafe_b64decode(parts[1] + '=' * (-len(parts[1]) % 4)))

与标准 Base64 对照

维度标准 Base64Base64URL
字母表含加号与斜杠换成短横线与下划线
URL 中使用需要百分号转义可直接使用
填充一般保留等号通常省略
典型载体邮件、PEM 证书JWT、OAuth、URL 参数
JWT 的 header.payload.signature 三段都是 Base64URL;直接按标准 Base64 解码会因缺少填充而报错。
Base64URL 不是加密:载荷任何人都能还原。JWT 里不要放口令或密钥类字段,签名段只保证完整性,不保证机密性。
长度对齐也值得留意:省略填充后用作文件名时可能出现超长路径或不合法的字符组合,建议固定长度或加前缀。

易错点

  • 各库对省略填充的容忍度不同,生成侧统一规则可减少对接故障
  • 把 Base64URL 字符串用于文件路径时要留意区分大小写文件系统与长度限制
  • 把它当成加密手段,在 JWT 载荷里放敏感信息
  • 解码前忘记补齐填充,报错往往指向无效字符而非填充缺失,容易误判
  • 忽略大小写差异,把 Base64URL 结果当作大小写无关的标识符使用

数据来源与参考

  • RFC 4648 §5(Base64URL)
  • RFC 7515(JWS,使用 Base64URL)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌