二进制载荷编码、序列化与往返验证

先把载荷分成三层

处理二进制消息时，最常见的误判是把文本包装当成数据格式。请先记录原始样本的来源、消息边界和预期消费者：结构化值经过序列化变成字节，字节有时又被 Base64、ASCII85、Base91 或十六进制转义包装成文本。三层必须分开保存，尤其不要在尚未确认内层格式时直接把可见文本当作 JSON 或 UTF-8 内容修改。

建立一个可重复的基准样本。它应覆盖普通文本、非 ASCII 字符、小数、空值、零字节、嵌套对象和数组等容易在转换中丢失的信息；同时记录原始长度与少量关键十六进制片段，供后续排查使用。

先解开传输包装，再判断内层格式

如果协议明确指定了外层表示，就使用对应转换器将其还原为字节。若来源不清楚，先保留证据并验证候选表示是否完整，而不是仅凭字符集猜测。解码成功不代表已经知道内容格式：一个看似普通的 Base64 字符串可能包着 Protobuf、CBOR 或应用自定义的二进制帧。

只有在获得原始字节并结合发送方文档、内容类型、schema 或消费者代码后，才选择 Avro、BSON、CBOR、Ion、MessagePack、Protobuf、Smile 或 UBJSON 中匹配的一种。对具备 schema 的格式，schema 版本、字段编号和默认值是载荷的一部分，不能在转换记录中遗漏。

用代表性样本完成双重往返验证

先将数据转换到目标格式，再还原回可检查的表示。第一轮比较业务语义：字段是否仍存在，数字精度和布尔值是否正确，Unicode 和空值是否保留，数组顺序与嵌套层级是否改变。第二轮检查边界条件：消息长度、零字节、二进制字段和关键十六进制片段应符合预期；如果目标格式允许不同的等价编码，应记录比较规则而非要求所有字节机械相同。

之后再把验证过的内层字节按通道要求重新包装，并立即解开交付物进行最后一次核验。这样可以区分“序列化选择错误”和“传输编码使用错误”，也让后续排障能沿着三层模型快速定位。

交付前检查与常见失败

不要只以“转换器没有报错”作为成功标准。应使用目标消费者或兼容解析器读取结果，并保存输入样本、schema 版本、目标格式、包装方式、长度和比对结论。常见失败包括把 Base64 当成内层格式、遗漏 Protobuf 字段编号、将二进制字段按文本重新编码，或在没有要求时重复套用传输包装。

当结果无法被消费者读取时，先回到最近一次通过验证的层：检查外层是否完整、schema 是否匹配、格式是否真被消费者支持，再缩小为最小复现样本。明确的层次记录比反复尝试不同转换器更可靠。