摘要

  • RFC 9649 为 WebP 容器与重建行为提供共同规范，但媒体类型、魔数和成功解码都不能证明来源、元数据真实性、资源安全或实际呈现结果。
  • 读取器应忽略未知块，而写入器在无意修改时应保留未知块；“不理解”“继续保管”和“认可其含义”是三项不同决定。
  • 可审计的媒体凭证应从原始字节与块清单，一直连接到解码器版本和限制、元数据选择、像素与帧、衍生文件，以及用户真正看到的画面。

名称只说明语法入口

RFC 9649 为 WebP 提供稳定的公开说明，并完成 image/webp 的注册。一个 RIFF 容器可以承载有损 VP8 图像、无损位流、透明度、色彩配置、动画、EXIF、XMP，以及应用自定义块。生产方与读取方因此有了一条共同的重建边界。

这条边界很重要，但它的权力有限。HTTP 中的媒体类型是发送方声明；魔数和 RIFF 结构是接收方观察；成功解码是某个具体实现的一次运行结果。三者可以相互支持，却不能互相替代。类型标签不能证明字节没有被替换，容器形状不能证明元数据真实，能打开的图片也不能证明解码过程没有越过本地资源上限。

治理失误常从一次无声的概念升级开始。“识别为 WebP”被写成“这是安全图片”；“浏览器显示成功”被写成“文件有效且可信”；“画面与原件相同”被写成“所有证据都被保留”。RFC 9649 并没有授予这些推论。它让语法可互操作，却把信任、资源和呈现留给真正执行决定的系统。

重建次序不是完整保管次序

扩展格式对参与图像重建和色彩修正的块规定了次序。视文件内容而定，这些块可能包括 VP8X、ICCP、ANIM、ANMF、ALPH、VP8 与 VP8L。如果重建所需块次序错误，读取器应当失败。这是明确的互操作契约。

EXIF、XMP 与未知块并不完全沿用这条路径。它们可以位于重建次序之外；未知块可以出现在文件末尾，也可以出现在动画帧负载末尾。读取器应忽略不认识的块。写入器若无意修改它们，则应按原次序保留。

这种不对称是扩展能力，而不是语义空白。今天的读取器可以显示带有明日扩展的文件，同时诚实承认自己无法解释新块。编辑器可以修改可见内容，而不至于顺手毁掉另一应用所需的数据。但规范没有说未知块因此无害，也没有说保留下来的块因此可信。

一次转换至少包含三种独立判断：哪些块能够解释，哪些块虽不能解释但继续保管，哪些块被删除、移动或改写。输出文件哈希只能标识结果，无法说明这些判断。若一个服务宣称“优化”或“清理”，它必须额外交代究竟改变了什么。

元数据存在，不代表陈述成立

WebP 可以容纳 EXIF 与 XMP。RFC 9649 指出，每种类型至多应出现一个块。如果重复，读取器可以只采用第一个而忽略后续实例。于是，同一文件在不同工具手中可能产生不同的语义结果：一项工具保留首块，一项工具重新生成规范化块，另一项工具全部剥离。三者仍可能给出完全相同的可见图片。

CIPA 的 Exif 规范定义字段结构；Adobe 的 XMP 规范定义可扩展模型与嵌入方式。这些容器并不会自动验证相机名称、拍摄时间、地点、作者、修改历史或权利声明。字段中的值仍然是陈述，需要另外检查来源、签名环境与保管连续性。

Lu Heng 关于现实层次的论述在这里可以转化为具体操作。存储字节、解析字段、来源主张、解码像素和读者信念彼此相邻，却不属于同一层。错误元数据可以原封不动地流转；准确元数据也可能在不改变画面的转换中消失。存在不是事实认证，转换后的缺失也不能证明原本不存在。

完全透明的像素仍有颜色

无损格式会精确恢复 ARGB 像素值，包括 alpha 为零的像素颜色。常规合成时，这个像素不会影响画面，但它的红、绿、蓝分量并没有消失。

这不意味着每个文件都藏有信息，而是提醒审查者区分“不可见”与“不存在”。后续操作可能移除 alpha、把图像置于意外背景上、使用颜色通道参与计算，或在转码中以不同方式处理它们。仅看缩略图的隐私检查可能遗漏字节检查或解码像素检查能够发现的数据。

反过来，优化器也可能归一化透明像素下的颜色，表面画面没有变化，解码像素矩阵却已经不同。“无损”描述指定编解码往返，并不承诺所有中间服务都保留原容器、元数据、未知块或应用专用信息。

动画指令与观看事实之间还有软件

WebP 动画帧包含位置、尺寸、时长、混合与处置指令。时长以毫秒表示，但零时长，以及许多十毫秒或更短的时长，会被实现自行解释；不少浏览器和工具会设置最短显示时间。背景色即使带有非不透明 alpha，也只应被视作提示。混合与处置规则决定下一帧到来前画布如何变化。

所以，字节序列并不是完整的观看记录。若要声称用户看到了什么，就要记录读取器与版本、时长归一化策略、色彩管理、合成背景、播放条件，必要时还要捕获呈现结果。编码指令和人类观察之间，始终存在一项软件政策。

同一个有效文件可能在两个合规读取器中呈现不同的节奏。差异不一定意味着任何一方违反规范，却可能影响安全提示、证据序列、品牌动画或受监管展示。把这种差异压缩成“都能打开”，等于删除实际影响发生的那一层。

有效文件仍可能触发危险行为

RFC 9649 的安全部分明确列出整数溢出、越界读写、未初始化数据、空指针、内存或磁盘耗尽，以及长时间计算。输入可能进入浏览器、邮件客户端与上传服务。后果可能包括代码执行、信息泄露、进程崩溃和拒绝服务。

WebP 没有主动内容机制，但处理它绝非被动动作。画布尺寸决定内存分配；动画增加帧数和状态；前缀码、变换与压缩数据推动复杂解析；EXIF、XMP 与自定义块还可能进入其他解释器。一个语法正确的文件完全可能超过接收方的资源政策。

因此，安全凭证必须独立于语法接受。它至少应记录解码库与版本、进程隔离、内存和时间上限、最大尺寸与帧数、被调用的元数据解析器、错误结果，以及是否生成衍生文件。合规对象可以被本地安全政策拒绝；错误对象也可能被宽容实现部分显示。两者都不能被提升为普遍的格式判断。

建立“字节—块—呈现”凭证

第一步是固定保管对象。对收到的精确字节计算哈希，记录字节数、传输声明的类型、文件名主张和独立类型识别。随后检查 RIFF 边界，但暂不宣布对象安全；为每个块记录 FourCC、偏移、声明长度、填充和次序。

然后分类：重建必需块、已知元数据、已知应用数据或未知块。每次操作都要注明自己理解、忽略、保留、删除、重排或改写了哪一项。若 EXIF 或 XMP 重复，记录具体选择。对 VP8X 保存画布尺寸与功能位；对动画保存帧矩形、时长、混合与处置方式。

解码必须置于有界环境，凭证纳入实现身份、版本和资源政策。根据比较目标，可以对像素或每帧计算哈希，并记录 ICC 处理、alpha 政策、合成背景与时长归一化。编辑器或优化器一旦生成衍生文件，就为新对象计算新哈希并重新盘点块，而不是继续称它为“同一张图”。

最后检查交付面：客户端实际获取了哪个对象，由哪个解码器处理，是否播放全部帧，观察到了什么结果。Lu Heng 的运行代码优先在这里给出最后一条纪律：登记语法决定共同边界，实际执行的读取器和观察输出决定发生过什么。

让规范保持最小，让本地决定保持可见

RFC 9649 无需承担一整部来源宪章。它最有价值之处，是对共享字节与重建边界作出有限而准确的规定。最小初始规范强调，先规定互操作所必需之物，再让未来选择和本地决定保持明确、自愿并可调整。

一家机构可以在公开交付时剥离所有元数据；另一家可以在档案中保留所有未知块；第三家可以拒绝动画、设置更低画布上限，或要求外置签名清单。这些都是合理政策，前提是政策有名称、有版本、有责任人，效果可以观察。若“优化”“净化”之类模糊标签遮住了证据删除，技术服务就会悄悄获得决定何种事实能够留存的权力。

最终判断应当狭窄而清楚：RFC 9649 可以证明字节符合共同 WebP 语法，却不能证明谁创作了其中的主张、未知数据未来是否重要、解码是否安全、转换是否保留保管链，也不能证明用户最后看到了什么。作出这些决定的系统，必须各自提供凭证。

来源