先看记录文件真正包含什么

从一次具体交接开始

例如支持交接包含保存的邮件、HAR 记录和两版 ZIP 导出。接收方需要附件、一份捕获的响应和发生变化的文档。比较整个 ZIP 字节流或重新下载所有 HAR 地址，无法直接回答这些任务。先恢复已保存的内容层，再比较内容。

把来源映射与恢复结果一起保留

邮件附件名可能含 Unicode 或不适合作为本地路径的字符。安全下载名便于使用，却可能改变原始拼写。保留源邮件、MIME 部件与恢复文件名的映射；零字节附件应保留为零字节文件，不能因为看似无内容而消失。

HAR 中需要区分捕获的 Base64 字节和重新序列化为 UTF-8 的文本字段。缺少正文的记录应单独报告，不能算成成功恢复。未进入记录的内容需要另行、明确地取得。

先判断什么差异影响交付

归档交付适合比较解压路径和字节。相同文档重新打包，可能仅改变时间、排序和压缩方式。对于未知格式的二进制文件，同偏移差异能够定位变化字节，却不能解释插入记录或文件结构；报告应明确其对齐方式。

字幕可见文字需要明确计数方式

格式标签会使原始字符计数偏大。字幕审查应明确标签、空格、换行和 Unicode 码点怎样参与规则。结合播放时长与重叠上下文查看被标记片段；数值报告没有问题，仍不能证明译文自然。

实际验证接收方的下一步

• 打开一个恢复附件并核对名称映射。
• 确认需要的响应正文确实进入 HAR。
• 查看归档中真正变化的完整路径。
• 在播放中阅读一个被标记的字幕片段。
• 遇到不支持的格式或范围时保留原件。

保存上下文，恢复记录才可继续使用

演示备注属于具体幻灯片，评论对应正文选区，脚注对应可见引用。只导出文字、丢掉关联，会让交接含义不清。保留这些关系，明确逻辑坐标或受支持编号，不能虚构排版位置。

内嵌 Source Map 也有类似边界：源路径不保证正文存在。将不可用记录与恢复的 UTF-8 文件一起保留，让接收方知道记录真正提供了什么。归档映射把安全下载名与源索引相连，却不能补出缺失材料。

本文相关工具