C2PA 集合数据哈希：如何核验一组文件

验证前先保存整个集合

在打开或整理文件前，保存实际收到的集合。记录来源、获取时间、manifest 位置、目录结构、文件名和这份副本的编号。若收到的是压缩包，把原压缩包与解压后的工作副本分开保存。这套记录方法是本文的操作建议，不是 C2PA 规定的报告格式。

使用兼容 C2PA 的验证器，保存工具名称、版本和完整输出。核查问题应限定为：验证器是否找到 c2pa.hash.collection.data assertion 列出的成员，并为每个成员算出与记录相同的 hash。只有应保存成员级输出，分别记录 URI、算法和每个清单文件是否可供核查。

首次验证前不要重命名、移动、规范化或重新导出成员。这些操作可能改变待核查的路径或字节。需要工作副本时，应另设编号并独立验证。

把 URI 清单视为声明范围

C2PA 2.2 在 manifest 指向一组资产时使用集合数据哈希，label 为 c2pa.hash.collection.data。uris 数组把相对 URI 与 hash 对应起来；一个 alg 值规定清单内各文件共同使用的加密哈希算法。成员还可以记录大小、媒体类型和数据类型。

原样抄录验证器显示的 URI。无论 manifest 位于本地、容器还是云端，URI 都相对于 manifest 的位置解释。规范要求 claim generator 检查或清理 URI，确保路径元素中不出现 . 或 ..。核查材料中若出现这类元素，应记录原 reference，在确认预期位置前停止处理。不要擅自整理可疑路径后再把它记成有效地址。

这份清单只是 assertion 声明的覆盖范围。规范不要求一个目录层级中的所有文件都进入集合哈希，因此清单外新增文件未必会破坏已列成员的 binding。应分别记录清单内成员和现场观察到的其他文件，不能把未列出的文件写成已受保护。

检查必填字段和逐文件哈希

Schema 定义了集合的 uris 与 alg，每个成员条目包含 uri 和 hash。核对这些字段是否存在；若有缺项，标记为“记录不完整”，并保存验证器实际显示的消息，不补造状态码。

清单内每个文件都按 alg 指定的算法单独计算 hash，并把结果存入对应 URI 的条目。复核时对成员从第一个字节到最后一个字节重新计算，不设排除范围，再与条目中的 hash 比较。按验证器实际用语记录一致、不一致或无法取得。

建议记录集合编号、manifest 位置、算法、URI、实际文件编号、工具显示的大小或媒体类型、比较状态和准确结果码。工具未展示的字段直接标为“未报告”，不要补猜。

分开记录完整性与内容真假

全部匹配只能支持一个有限结论：验证器找到了清单内成员，其全文件字节与 assertion 记录的 hash 一致。它不能证明集合已包含所有相关文件，也不能证明签名者可信、metadata 准确或文件描述的现实事件确实发生。

Mismatch、非法 URI、格式错误或清单文件缺失，说明这份副本没有通过规定的集合 binding 核查。这些结果不能单独确定谁改了文件、何时修改、是否故意遗漏，也不能证明文档、图片、音频或视频内容为假。

若使用 DeepFakeCheck 获取单独的概率性媒体信号，应把输出放在 C2PA 记录之外，并关联实际分析的文件。自动分析可能误报真实材料，也可能漏报合成或修改材料。高风险信号支持继续复核；低风险信号不能认证集合，也不会修复 hash 失败。

留下可重复的核查记录

把原始集合、manifest、验证器版本、完整输出、URI 表与外部来源核查放在一起。下一位复核者应能找到同一 manifest，沿相同相对 URI 重做每项比较。工具不展示成员级输出时，应记录这个限制，不能把汇总徽标拆成多个假定的 match。

文件的现实主张应通过原始发布者、标明的日期地点、责任机构及关于事件的独立证据核查。集合数据哈希回答的是哪些声明文件与加密记录一致，不回答集合是否完整，也不判断文件内容是否真实。

来源

• C2PA《C2PA Technical Specification: Collection Data Hash》：https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_collection_data_hash