编码后的文字不对？区分 URL、Base64 与 Unicode 并核对往返结果

01先规划输入与核查

1. 1
   先用 A+B、一个汉字和一个表情作为已知样本，写清接收系统期望的格式。
2. 2
   每次只解一层，与原始内容比较，再按相同约定编码回去。
3. 3
   图片区分字节与媒体类型，文字区分字符与编码；把 Data URL 前缀和 Base64 负载分开检查。

02按步骤选择具体操作

• 恢复 Base64 图片: 有完整 Data URL 时优先粘贴完整内容，检查解码后的尺寸，下载副本后再放进网页。
• 文字 Base64 编解码: 用已知多语言样本逐字核对解码结果；Base64 是可逆表示，不是加密。
• 检查 URL 编解码: 先确定处理的是哪个网址组成部分；整体解码可能把转义分隔符变成结构，打开前核对目的地址。
• 查看 HTML 实体: 比较 & 与解码后的与号；解码出的标记仍是不可信输入，不应直接执行。
• 检查 Unicode 转义: 对照字面转义与实际字符。当前正向编码不能保留表情的完整代理对；此类文本应保留原始字符并使用合适的目标格式编码器。
• 解析网址参数: 用 tag=a&tag=b 检查重复键；当前工具会将其扁平化为最后的 b，需要全部值时应保留来源网址。
• 转换数字进制: 用 255 与 FF 做小样本，明确输入进制，不要把带前导零的账号标识当数值。

03对照一个编辑示例

04A+B 与 A B 在查询字符串里怎样分开

自编输入为 https://example.com/?q=A%2BB&tag=a&tag=b。URL 查询解析后，q 是 A+B，tag 有 a、b 两个值。若把 q 写成 A+B，查询解析会把裸加号解释为空格，得到 A B。要传递真实加号，应编码为 %2B；空格则可以在查询编码中表示为 +，具体表示取决于发送方采用的编码方式。

URL 编解码工具的正向操作使用 encodeURIComponent，反向使用 decodeURIComponent，因此对单独的 A+B 解码不会把 + 换成空格；它和查询解析器的语义不同。URL 参数工具当前把参数转成扁平对象，对 tag=a&tag=b 只显示最后一个 b。检查重复键时保留原 URL，不能拿这个对象当作无损的查询字符串备份。

05用一个固定字符串检查 Base64 的字节约定

固定自编样本 A+B 中😀 的 UTF-8 十六进制字节是 41 2B 42 20 E4 B8 AD F0 9F 98 80；标准 Base64 是 QStCIOS4rfCfmIA=。其中汉字占三个 UTF-8 字节，表情占四个；不能用“可见字符数乘一”预测字节长度。

将完整的 QStCIOS4rfCfmIA= 放入Base64 文本工具反向处理，应恢复 A+B 中😀。当前工具按 UTF-8 编解码文本。若来源其实是二进制图片，应使用图片入口并保留媒体类型；若来源采用另一字符编码，盲目按 UTF-8 读取可能产生替代字符。重新编码后可读也不能反证丢失的原始字节已恢复。

06一个表情的转义需要完整代理对

A 的 UTF-16 转义是字面序列 \u0041；中是 \u4e2d。😀 对应两个 UTF-16 码元，完整的代理对写作 \ud83d\ude00，仅有 \ud83d 不是完整表情。JSON.stringify("😀") 也可能直接保留表情字符，不能把是否出现反斜杠当成合法性的唯一判断。

当前Unicode 工具的正向处理对补充平面字符存在限制，会漏掉表情的低代理部分；不要用它导出含此类字符的生产文本。保留原始字符串，并用完整的目标格式编码器或解析器核对往返结果。反向处理完整代理对与正向生成完整代理对是不同能力；一个方向看起来可用，不能替另一个方向背书。

07检查最终结果并保留依据

MDN 说明了重复查询键与解析行为，排查时应保留原网址。

图片负载无法使用时，应单独检查 Data URL 前缀。 解码内容属于数据文件时，再检查数据结构。