HTTP Header 中的 Base64 编码

← 返回博客

HTTP Header 中的 Base64 编码

· 5 分钟阅读

HTTP 头部为什么使用 Base64

HTTP/1.1 协议规定头部字段的值必须是 ASCII 可打印字符（RFC 7230），且不能包含换行符。这个限制意味着任何包含二进制数据或非 ASCII 字符的值，都必须经过编码才能放入 HTTP 头部。Base64 正是满足这一要求的标准解决方案：它将任意二进制数据转换为安全的 ASCII 字符串。

HTTP/2 和 HTTP/3 通过头部压缩（HPACK/QPACK）改进了头部传输效率，但对字段值的字符限制仍然基本保持与 HTTP/1.1 兼容。因此 Base64 在 HTTP 头部中的使用，即便在现代协议中也同样普遍。

Authorization 头部

Authorization 头部是 HTTP 中最常见的使用 Base64 的场合。HTTP Basic Authentication 格式：Authorization: Basic [Base64(username:password)]。服务器响应 401 Unauthorized 时，通过 WWW-Authenticate: Basic realm="API" 告知客户端需要 Basic Auth。

# 手动构建 Authorization 头部
# Manually construct Authorization header
username="[email protected]"
password="MySecretPass123"
credentials=$(echo -n "${username}:${password}" | base64)
echo "Authorization: Basic ${credentials}"
# Authorization: Basic dXNlckBleGFtcGxlLmNvbTpNeVNlY3JldFBhc3MxMjM=

# 使用 curl / Using curl
curl -H "Authorization: Basic dXNlckBleGFtcGxlLmNvbTpNeVNlY3JldFBhc3MxMjM=" \
  https://api.example.com/v1/resource

# curl 自动处理 / curl handles automatically
curl -u "[email protected]:MySecretPass123" https://api.example.com/v1/resource

Bearer Token 与 JWT

Bearer Token 认证方案（OAuth 2.0）的格式为：Authorization: Bearer [token]。当 token 是 JWT 时，整个 JWT 字符串（由三个 Base64URL 编码部分组成）就是 Bearer Token 的值。例如：Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c。

注意 JWT 使用 Base64URL（非标准 Base64），所以 JWT 中不会出现 + 和 / 字符。如果你在 JWT 中看到这些字符，说明该 JWT 是格式错误的或者使用了非标准实现。

Content-Disposition 与文件名编码

Content-Disposition 头部用于指定文件名。当文件名包含非 ASCII 字符（如中文文件名）时，需要特殊编码。RFC 5987 定义了 filename* 参数格式，使用 UTF-8 字符集和 percent-encoding；而较旧的实现使用 RFC 2047 的 B（Base64）或 Q（quoted-printable）编码。

# RFC 5987 方式（现代，推荐）
# RFC 5987 approach (modern, recommended)
Content-Disposition: attachment; filename*=UTF-8''%E4%B8%AD%E6%96%87%E6%96%87%E4%BB%B6.pdf

# RFC 2047 Base64 方式（旧式，部分客户端仍使用）
# RFC 2047 Base64 approach (legacy, still used by some clients)
Content-Disposition: attachment; filename="=?UTF-8?B?5Lit5paH5paH5Lu2.pdf?="

# 兼容性写法（同时提供两种格式）
# Compatibility approach (provide both formats)
Content-Disposition: attachment;
  filename="=?UTF-8?B?5paH5Lu2.pdf?=";
  filename*=UTF-8''%E6%96%87%E4%BB%B6.pdf

Proxy-Authorization 与 Proxy-Authenticate

代理服务器认证使用与 HTTP Basic Auth 相同的 Base64 机制，但使用不同的头部：Proxy-Authorization: Basic [Base64(username:password)] 和 Proxy-Authenticate: Basic realm="proxy"。这在企业内部网络中使用需要认证的 HTTP 代理时很常见。

在配置使用代理的应用程序时，代理凭据通常以 URL 格式提供：http://username:[email protected]:8080。许多 HTTP 客户端库会自动解析这个格式并生成对应的 Proxy-Authorization 头部（包括 Base64 编码）。

自定义头部中的 Base64

API 开发者有时在自定义头部（如 X-API-Key、X-Auth-Token）中使用 Base64 编码数据。这通常没有特别的技术原因，只是一种约定。如果你的 API 接受这类头部，记录清楚头部值是否需要 Base64 编码，以及使用哪种变体（标准 Base64 还是 Base64URL）。

一个常见的模式是在自定义头部中传递 JSON 对象（Base64 编码）。例如：X-User-Context: eyJ1c2VySWQiOiIxMjMifQ==（{"userId":"123"} 的 Base64 编码）。这种模式允许在 HTTP 头部中传递结构化数据，而无需额外的 JSON 反序列化步骤（因为头部解析阶段通常只处理字符串）。

调试 HTTP 头部中的 Base64

在调试 API 问题时，经常需要检查 HTTP 头部中的 Base64 值。浏览器开发者工具（Network 选项卡）会显示原始的 Base64 值，你可以复制这些值到我们的在线工具中即时解码。对于命令行调试，使用 curl -v 可以显示完整的请求和响应头部。

# 显示请求和响应头部（包括 Authorization）
# Display request and response headers (including Authorization)
curl -v -u "user:pass" https://api.example.com/endpoint 2>&1 | head -30

# 解码 Authorization 头部中的 Base64
# Decode Base64 in Authorization header
AUTH_HEADER="YWRtaW46c2VjcmV0"
echo "${AUTH_HEADER}" | base64 --decode
# admin:secret

立即尝试在线工具，无需安装，免费使用。

打开工具 →