· 全部指南
Base64 是什么、不是什么
Base64 把任意字节序列编码为可打印 ASCII 字符，常用于在 JSON、邮件、Data URL 中嵌入二进制数据。它不是加密——任何人都可以解码。标准 Base64 使用 + 和 /，在 URL 查询参数中需要改用 URL-safe 变体（- 和 _）。Towalles base64-encoder-decoder 支持文本与 UTF-8，在本地完成编解码。
常见场景：JWT 的 Header/Payload 段、图片 Data URL（data:image/png;base64,...）、Basic Auth 的 Authorization: Basic xxx、部分 API 要求二进制字段 Base64 上传。错误场景：用 Base64「隐藏」API 密钥——解码即暴露。
URL 编码（百分号编码）
URL 编码把保留字符与非 ASCII 字符转为 %XX 形式，例如空格 %20、中文 %E4%B8%AD。encodeURIComponent 编码查询参数值；encodeURI 保留 :// 等 URL 结构字符。混用是 404 与签名失败的常见原因：OAuth redirect_uri、Webhook 回调、带中文的分享链接都需要一致编码策略。
联调技巧：用 url-parser 拆解可疑链接，对比 path、query、fragment 各段；用 url-encoder 对单字段编码后再拼 URL，避免「整段 URL 编码两次」。签名类 API（如云服务回调验证）通常要求 canonical 排序后的 query string，编码方式必须与文档完全一致。
UTF-8 与二进制边界
文本 Base64 前必须明确编码：JavaScript 默认 UTF-8，但旧系统可能用 GBK。中文「你好」的 Base64 与 Latin-1 假设下的结果不同。处理文件或图片时用二进制模式，不要当文本粘贴。hex-encoder 适合查看字节级差异，排查「同样字符串不同环境哈希不一致」类问题。
团队规范建议：API 文档写明 charset；日志里 URL 存编码后还是原始值；禁止在日志打印完整 Base64 凭证。本地工具不联网，但剪贴板与录屏仍是泄露渠道——测试完清空输入框。
标准 Base64 与 Base64URL
标准 Base64 使用 +/ 与 = padding。Base64URL 使用 -_ 且常省略 padding——JWT 段即如此。混用是「A 工具能解、B 工具不能」的首因。
排障步骤
- 看字母表（
+还是-_）。 - 若标准解码器需要，补齐到 4 的倍数 padding。
- 用 base64-encoder-decoder 解码；若是二进制不要强行当 UTF-8。
- JWT 优先用 jwt-decoder，不要手拆。
安全提醒
Base64 是编码不是加密，人人可逆。包在 Base64 里的密钥仍是密钥。
三种常见 Base64 方言
标准 Base64（+/ 带 padding）、Base64URL（-_，常无 padding）以及 MIME 换行，出现在不同协议里。JWT 段是 Base64URL；Data URL 是标准 Base64。混用是解码失败的头号原因。
不是加密
Base64 只是编码。威胁模型里应把可逆内容当明文。用本地工具瞬间还原「机密」，是教新人的最好演示。
练习
用 base64-encoder-decoder 对 fixture 做往返，再把 JWT 形字符串送进 jwt-decoder，强化方言差异。
Padding 规则
有的库拒绝缺少 = padding；有的接受无 padding 的 Base64URL。互操作失败时，先尝试补 padding，再宣布载荷损坏。
Base64 互操作
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。