C2PA 验证结果：如何解读状态码

先保存文件和完整验证输出

保存实际收到的媒体副本，不要编辑；同时记下文件名、来源页面、获取时间和验证工具。平台如果提供多个下载版本，明确标注真正产生验证结果的副本。这套记录方法是本文的操作建议，不是 C2PA 规定的流程。

用兼容的 C2PA 验证工具检查这份副本，并保存完整输出。C2PA 2.2 规范说明，验证算法会返回资产 C2PA Manifest Store 中各个 manifest 的汇总结果，其中包括 active manifest，以及 ingredient assertion 引用的其他 manifest。只截一张红色或绿色标记，容易丢掉状态码、对应项和解释文字。工具能提供完整输出时，应一并保存。

分开记录三类结果

C2PA 使用标准的 success、informational 和 failure 状态码表达验证结果。三个数组都可以为空。不要把它们压缩成一句“已验证”或“假的”，而应按工具显示的原始分组分别保存。

每条结果都有 code，还可能包含指向适用 JUMBF box 的 URI，以及供人阅读的 explanation。这些字段应保持在一起。规范也允许为特定流程记录信息的自定义状态码。遇到陌生状态码时，保留原文，不凭印象把它塞进某个标准分类。

可以用一行记一条结果：文件、结果分类、完整状态码、URI 和解释，以及仍待解决的问题。这张表是本文提出的复核方法，用来防止与签名、assertion、credential、time stamp 或 ingredient 相关的状态码，被悄然扩写成对整个文件的结论。

解读失败的检查项，不推断画面真伪

标准列表包含多种不同检查。failure 状态码可能指向 claim signature 缺失或不匹配、assertion 无法访问、算法不受支持、hash 不匹配、credential 结果或其他验证步骤。准确状态码能帮助定位需要调查的技术检查项，但它不能单独证明谁修改了文件、为什么修改，也不能证明画面中的事件发生过。

success 和 informational 结果同样有范围限制。success 状态码记录某项定义好的检查通过，informational 状态码记录验证工具报告的情况。它们都不能独立验证说明文字、日期、地点、说话人身份或现实事件。这些主张需要结合最初发布页面和独立来源核对。

两份副本返回不同结果时，保留两份文件和输出。这种差异只能说明副本或其当前可用的 provenance 记录没有以相同方式通过验证。没有其他证据时，不推断编辑者和动机。

分开记录 provenance 与检测结果

C2PA 验证检查 provenance 记录及其定义的技术项。如果还把保存的媒体提交给 DeepFakeCheck，将这条概率性风险信号放在单独部分，并关联到实际被分析的副本。

自动检测会出现误报和漏报。误报会把真实媒体标成可疑，漏报会放过合成或篡改媒体。高风险结果是继续复核的理由；低风险结果不能认证文件，也不能取代验证工具的完整状态码。

最后保留文件、完整验证输出、待解决的技术检查、来源页面核对、检测结果和实际处置决定。下一位复核者应该可以重复每项检查，无需依赖颜色标记或后补的解释。

来源

• C2PA《Content Credentials: C2PA Technical Specification, Returning Validation Results》：https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_returning_validation_results