加密算法基础95 条

Base64 编码

RFC 4648 定义的二进制转文本编码:每 3 字节编码为 4 个字符,字符集含 A-Z、a-z、0-9、+ 与 /,尾部用 = 补位;体积约增加 33%。

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

Base64 是什么

Base64 是 RFC 4648 定义的二进制转文本编码:每 3 个字节映射成 4 个可见字符,字符集为 A-Z、a-z、0-9、加号与斜杠,长度不足时用等号补齐。它解决的是「二进制数据不能被文本协议安全承载」的问题,体积约增加三分之一。它只是编码,不是加密。

基本信息

标准RFC 4648 §4
字符集A-Z a-z 0-9 加号 斜杠,等号用于补位
膨胀比4/3,约 33%
变体Base64url(用减号与下划线替代加号与斜杠)、无填充变体
典型用途PEM 证书与私钥、邮件附件与 MIME、JSON 内嵌二进制、Data URI
易混淆项Base32、Base16(十六进制)与 URL 编码

典型使用场景

  • 证书与密钥文件:PEM 格式即 DER 二进制经 Base64 后再加头尾标记
  • 邮件与 HTTP:MIME 附件与 Basic 认证头依赖 Base64 承载二进制
  • JSON 与配置文件:把二进制字段编码成字符串以便放进 JSON
  • 图片内嵌:Data URI 直接把小图写进 CSS 或 HTML
  • 接口传输:把签名或密钥材料以字符串形式随 JSON 传递
  • 调试与日志:把二进制数据转成可复制文本便于排查

编码与解码

编码与解码
# 基础编解码:-n 避免把换行也编进去
echo -n 'hello' | base64
# 输出 aGVsbG8=,末尾等号是补位,解码时要带上
echo 'aGVsbG8=' | base64 -d
# 处理文件:DER 证书转 PEM,本质就是 Base64 加头尾标记
openssl base64 -in cert.der -out cert.b64
# Base64url:把加号斜杠替换,去掉等号,便于放进 URL 与文件名
printf '%s' 'a+b/c' | base64 | tr '+/' '-_' | tr -d '='
# 解码时注意换行:跨系统传输常带换行,某些解码器要求单行输入
echo 'aGVsbG8=' | tr -d '\n' | base64 -d

相关编码对照

编码膨胀比特点典型用途
Base64约 1.33 倍含加号斜杠与等号补位PEM、邮件、JSON 内嵌二进制
Base64url约 1.33 倍换成减号下划线,可省略补位URL、文件名、JWT 各段
Base16(十六进制)2 倍仅 0-9a-f,直观易比对摘要、密钥、抓包与日志
Base32约 1.6 倍仅大写字母与 2-7对大小写不敏感的场景
URL 编码视内容而定按字节转百分号编码表单、查询串、路径参数
Base64 是编码不是加密:任何人都能解码,不能用于保护敏感数据。把密码、令牌或密钥以 Base64 形式存储或传输,等价于明文暴露;需要保密必须使用加密,需要防篡改必须使用签名或 HMAC。
跨系统对接时先约定三件事:是否使用 Base64url 变体、是否保留等号补位、传输中是否包含换行。这三项不一致会表现为解码失败或数据错位,而报错信息通常只写「格式非法」。

易错点

  • 把 Base64 当加密使用:任何拿到字符串的人都能解码,敏感信息直接暴露
  • 忽略换行与补位差异:不同语言与库的默认行为不同(有的自动忽略换行,有的严格要求长度是 4 的倍数),跨系统传输要显式约定
  • 在 URL 或文件名里直接使用标准 Base64:加号会被解析成空格,斜杠会被当作路径分隔符,应改用 Base64url
  • 解码前未校验输入:非 Base64 字符会让某些实现静默跳过、另一些直接报错,建议先做字符集与长度校验
  • 对大文件整块编码再放进 JSON:体积膨胀 33% 且占用内存,应考虑分块或改用二进制传输方式

数据来源与参考

  • RFC 4648(Base16/32/64 编码)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌