先把问题解决
正确v1包含docs/note.txt（3字节）与data/list.csv（5字节），有效载荷合计8字节。v2只给note多加一个LF，变成4字节，核验应显示一项内容不符、一项一致。8字节不是ZIP大小，哈希一致也不代替人工确认交付版本和内容。
解开练习包，把参考答案与输入分开
使用本文下载区的本地生成练习包；它是虚构演示材料。先用操作系统解开外层ZIP，里面有handoff-v1、handoff-v2两个输入文件夹、reference-v1.json参考清单和accepted-v1.zip。不要把README、参考清单或嵌套ZIP一起选进待核验文件夹。
- 双方先确认handoff-v1是本次接受的版本。在真实交付中，这一步需要独立确认渠道；收到文件后现生成一份新清单，不能反过来证明它就是原定版本。
- 打开文件校验，用文件夹选择入口选择handoff-v1，使相对路径保留docs和data；当前入口去掉最外层文件夹名。
- 导入reference-v1.json，再点“计算并核验”。浏览器要求确认文件夹选择时，核对文件夹名称与2个文件后继续。
| 输入路径 | v1的精确内容 | 字节数 |
|---|---|---|
| docs/note.txt | UTF-8 abc；没有BOM或末尾换行 | 3 |
| data/list.csv | id、LF、7、LF；没有BOM | 5 |
先通过v1，再用v2主动制造一次失败
- v1应有2项一致，没有缺失或额外文件。核对note的SHA-256为ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad，保存JSON清单与CSV核验报告。
- 重选handoff-v2，继续对照同一份reference-v1.json计算；note多一个LF应失败，不能因为文本看起来同为abc而忽略。CSV文件应仍通过。
- 若换行确实是批准的改动，由负责人确认新版本再生成新清单；若不是，恢复已接受的v1重新核验。不要编辑参考哈希来“消除错误”。
- 用ZIP解压检查accepted-v1.zip的条目，可下载单项或重新打包选择项；要在磁盘得到文件夹，请用操作系统解压。选中解压后的文件夹再次核验，再打开note与CSV检查显示内容。
| 选择的文件夹 | docs/note.txt | data/list.csv |
|---|---|---|
| handoff-v1 | 3字节；一致 | 5字节；一致 |
| handoff-v2 | 4字节；内容不符 | 5字节；一致 |
若两个文件都显示缺失、同时出现两个额外文件，先查外层目录或路径是否不同。若只有note失败，先比较字节、换行和BOM，再检查编码与真正的内容变更。
用八个字节理解校验清单在比什么
自编最小交付包含两个 UTF-8 文本文件：docs/note.txt 的精确内容是 abc，没有行尾换行，共 3 字节；data/list.csv 的精确内容是 id、换行、7、换行，即 id\n7\n，共 5 字节。两份正文合计 8 字节。这里的数字是正文大小，不是 ZIP 大小，也不包括清单本身。
对 abc 计算 SHA-256，完整值应为 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad。若编辑器保存时在末尾补了换行，它变成 4 字节，摘要也改变，即使肉眼仍看到 abc。用这个无敏感内容的样本，能检查你选择的是文件字节，而不是复制到文本框后的另一份文字。
| 相对路径 | 精确内容说明 | 字节数 |
|---|---|---|
| docs/note.txt | abc，末尾没有换行 | 3 |
| data/list.csv | id\n7\n，使用 LF | 5 |
| 合计 | 仅以上两个正文文件 | 8 |
字节相同但改了名，为什么仍提示缺件
当前文件校验按相对路径找对应文件，再比较大小和 SHA-256。若把 docs/note.txt 改成 docs/notes.txt，正文即使仍是 abc，旧清单会看到前者缺失、后者额外出现。这不是摘要计算错误，而是接收方约定的文件名没有满足。恢复约定路径，或在双方确认变更后从已审核的新文件集合重新导出清单。
选择整个文件夹时，工具会去掉最外层文件夹名，保留里面的相对目录；单独多选文件则通常只有文件名。两份来自不同目录却同名的文件因此可能冲突，应通过文件夹选择保留结构。不要为了消除额外条目，把清单手工改成恰好符合任意收到的文件；参考清单需要来自已接受的交付版本。
校验压缩包，与核对解压后的交付是两项检查
接收后核对 ZIP 自身的摘要，可以确认它与参考 ZIP 的字节是否相同；但如果参考包最初就漏了最终 PDF，相同的包仍然漏件。先审核应该有的相对路径、格式和版本，形成包内正文清单，再制作 ZIP。接收后解压到新位置，与这份正文清单比较，最后在目标软件打开关键文件。
清单宜与受检正文集合分开保存。若把 checksums.json 也放入文件夹后整夹选择，它可能作为额外文件出现；应明确此次受检集合是否包含清单，并避免让一份清单要求包含它自己的最终摘要。修订交付时保留旧清单和新清单，用版本比较说明增删改项，防止为让校验通过而把过期文件重新混入新包。
输入不同或继续处理时，再选这些工具
- 核验交付要求: 设置必需项和限制，检查缺件、重复与空文件，再为已核对集合导出清单。
- 核对文件完整性: 对实际交付文件计算 SHA-256，在解压或传输后与可信清单比较；哈希不认证内容正确。
- 整理交付副本: 导出前预览批量命名与重复处理选择，防止只因名称相近便移除不同版本。
- 比较交付包版本: 选择基线与当前文件夹或 ZIP，检查增删改条目，并查看可用预览。
- 上传前检查文件: 输入实际目标的体积与像素规则，检查拟修复图片，并对最终输出重新核验。
- 创建 ZIP: 仅打包已验收的待交付集合，在清单中保留名称与目录结构。
- 查看并解压 ZIP: 检查内部名称和数量，解压到明确位置并打开代表性文件；不要执行不熟悉的内容。
- 中转已检查副本: 配对目标设备，查看界面说明的服务与有效期信息，并检查接收文件；配对成功不等于交付完成。
- 复用处理配方: 检查导入处理链，先用不同尺寸或字段的小批次测试，再用于新交付。
交付完成要同时满足三个层次
美国国会图书馆将 ZIP 说明为文件包；内部内容应与外部文件名单独核对。
表格分组生成文件时，应按预期分组核对 ZIP 清单。 体积规则之外，还可能有像素与宽高比要求。
文件交付验收
- 版本：参考清单来自已确认的交付版本，不是从未知接收文件反向生成。
- 字节：2个相对路径、大小与哈希匹配，无未解释的缺失、额外或内容不符。
- 用途：从最终交付ZIP解出的文件再次核验，并在接收方应用中打开；表格编号和换行显示符合预期。
- 记录：保存版本确认与核验报告；练习包下载、打开ZIP或算出哈希本身不表示实际业务交付成功。
常见问题
哈希一致证明文档内容正确吗？
不证明，只说明字节与参考一致；参考本身须来自可信且经过检查的文件集合。
ZIP 会把所有文件压得很小吗？
不会，已经压缩的图片和媒体可能变化很小，应检查实际包体积。
保存的配方能代替最终核验吗？
不能，新输入可能有不同尺寸、字段或异常值，应检查实际输出。
参考资料与延伸阅读
按步骤开始处理
进入对应工具，预览处理结果，检查导出的文件。
