Base64 解码实操：中文、URL-safe、补位与 Data URL

1. 先跑通 UTF-8 往返样例

选择“编码”，输入 你好，世界，使用全角中文逗号，首尾不加空格，再执行转换。结果应为 5L2g5aW977yM5LiW55WM。切换到“解码”并粘贴该结果，应还原原来的五个字符；它们的 UTF-8 编码占 15 字节，不是五字节。

这个样例固定了字符集和标点。如果结果不同，先对照源字符，再检查上游是否重复编码。当前文本转换流程会去除输入首尾空白，因此不能用本页面核验必须保留首尾空格的文本协议。

2. 核对 URL-safe 字符和缺失补位

在“解码”模式分别输入 8J+YgA== 和不带补位的 URL-safe 形式 8J-YgA，两者都应得到 😀。另一个替换字符可用 Pz8/ 与 Pz8_ 对照，两者都解码成 ???。工具会先把 - 换成 +、把 _ 换成 /。

保持“解码”模式，Zg 与 Zg== 都应得到 f；Zm8 与 Zm8= 都应得到 fo。工具会把长度补到四的倍数，并去除编码输入中的空白。这些兼容处理不能找回丢失的载荷字节，也不能证明输入符合某个严格协议的编码要求。

这些短串不要交给“自动”判断：规范化后不足八个字符的输入会被当成待编码文本。例如自动模式会把 Zg== 转成 Wmc9PQ==，而不是 f。明确选择“解码”即可避开这个启发式判断。

3. 每次只拆一层传输包装

在“解码”模式粘贴 data:text/plain;base64,SGVsbG8=，预期得到 Hello。这是带 Base64 标记的 Data URL。另一种输入 data:text/plain,Hello%20world 使用百分号编码文本，应交给 Data URL 解析器，不能套用这里的 Base64 提取流程。

如果抓到的查询参数是 SGVsbG8%3D，先执行一次 URL 解码得到 SGVsbG8=，再做 Base64 解码得到 Hello。Base64 工具不会自行还原 %3D。排查时保留原始请求：表单式查询参数解析可能把字面的 + 变成空格，后续移除空格也找不回原来的 +。

JWT 应用 JWT 解码器按段检查。读出载荷不等于验证签名、签发方、受众或过期时间；可读的文本不能作为令牌已经通过认证的证据。

4. 区分有效 Base64 与有效文本

明确选择“解码”后输入 /w==。它表示单字节 FF，不是有效的独立 UTF-8 序列。当前工具会回退到替换解码，显示 �（U+FFFD），而不是把这个情况当成错误拒绝。

压缩包、PDF、压缩消息和任意二进制都应保留为字节；带替换字符的文本不能还原原始字节序列。工具可以预览识别出的部分图片类型，但预览成功或文字看起来正常都不是通用文件校验。应对照预期 MIME 类型，用适合该格式的工具检查原始内容。

5. 写下能复现的字段约定

一条明确的约定可以是：UTF-8 文本、无补位的 URL-safe Base64、放在一个 JSON 字符串字段中。保留 😀 → 8J-YgA 这样的固定样例，让收发两端都对照验证。字段经查询参数传输时，还要单独规定 URL 转义规则。

Base64 是可逆编码，不是加密，也不是签名。不要以为编码后的密码或令牌已经隐藏；共享排障记录时使用一次性公开样例。