从 Basic Auth 头读取凭据
一次 Base64 解码、一次冒号分割，并清醒认识为什么 Basic Auth 凭据需要谨慎处理。
- 1
HTTP Basic 认证将凭据作为 Authorization 头发送：'Basic ' 后跟 username:password 的 Base64 编码。解码它恰好是一次 Base64 操作——这也是安全要点：Base64 是传输编码，不是保护。HTTPS 才是在线路上保护这些凭据的手段。
- 2 Base64 解码器 →
先去掉 'Basic ' 前缀，再用 UTF-8 字符集解码剩余部分。输出即 username:password。
- 3
只在第一个冒号处分割：某些系统中用户名技术上可含冒号，密码则经常含冒号。第一个冒号之后的所有内容都是密码。将解码后的值当作现役密钥处理——不要粘贴到日志、工单或截图中；尽量用一次性测试账号做此练习。
常见问题
- Basic Auth 这么简单为什么还在用？
- 因为在 TLS 之上该方案对机器间端点足够胜任，且实现极简。其弱点是凭据复用以及缺少过期、作用域或撤销——这正是基于令牌的方案所补充的。
- 解码后的值像乱码——为什么？
- 要么是前缀没去掉，要么是凭据含非 ASCII 字符且用了别的字符集编码。在解码器选项中用正确字符集重试。
解决此任务的工作流
解码 Basic Auth 凭证对
将 HTTP Basic Authorization 头中的 Base64 部分解码为 username:password。 管道
Base64 编码→解码→验证
将文本编码为 Base64 再解码回来，验证往返过程完整保留原始数据。 管道
Base64 转 Base85
将 Base64 解码并重新编码为 Base85。 管道
Base64 转 Hex
将 Base64 字符串解码为原始字节，再编码为十六进制以便检视或互操作。 管道
解码并格式化 JWT 载荷
解析 JWT 令牌，提取其载荷，并格式化 JSON 以便检视。 管道
解码嵌套 URL 参数（Base64 JSON）
将承载 URL 编码 Base64 JSON 的 URL 参数解包为可读的格式化 JSON。 管道