摘要

  • RFC 2083 让四字节 PNG chunk type 的每个字母各携带一个属性：关键/辅助、公共/私有、保留位以及不可/可以安全复制。
  • 第四位是编辑器的依赖规则，不是内容真伪标签。关键图像数据改变后，未知且 unsafe-to-copy 的辅助 chunk 必须被丢弃，safe-to-copy 的才可保留。
  • chunk 被保留且 CRC 匹配，只证明有限的字节托管；它不证明私有名称唯一、语义仍适用、作者身份、编辑授权、隐私或图像主张准确。

设想一个编辑器改变调色板并重新写出 IDAT。它在文件中遇到一个从未见过的 type。长度可以读取，数据可以跳过，CRC 也能验证；但编辑器不知道其中保存的是直方图、物理标定、版权说明，还是某个私有工作流的中间状态。它仍必须决定这段未知字节是否属于新文件。

RFC 2083 的贡献不是要求旧软件理解未来所有扩展，而是给“不理解”规定一条诚实路径。PNG 的每个 chunk 都包含长度、四字节类型、数据和四字节 CRC。类型字节只取 ASCII 大小写字母，但实现必须把它们当作固定二进制值；真正被测试的是每个 byte 的 bit 5，而不是受语言环境影响的大小写函数。

四个字母分别承担四种责任

第一个字母表示 critical 或 ancillary。大写意味着关键：未知 type 可能包含正确解释图像不可缺少的信息，解码器不能假装成功。小写意味着辅助：未知 chunk 可以被忽略，图像仍可继续显示。辅助不等于不重要。版权、标定或位置对人类决策可能非常重要，只是它们不一定是提取可见像素的前提。

第二个字母区分 public 与 private。它主要管理命名空间，并不要求解码器采取不同功能动作。公共分配不会使用私有形式，但两个私有使用者仍可能选中同一个 type，却赋予不同含义。因此 RFC 2083 建议在私有 chunk data 起始处加入额外识别信息。private bit 不是全球唯一性、来源或身份凭证。

第三个字母是 reserved bit。Version 1.0 要求它为大写；旧解码器却不应仅因发现小写就报错，因为未来规范可能给它含义。保留空间不等于旧实现已经理解未来。

第四个字母面向编辑器。小写表示 safe-to-copy，大写表示 unsafe-to-copy。RFC 的假想名称 bLOb 因而代表辅助、公共、保留位为零且可安全复制的 chunk。TEXT 与 Text 不是同一名称的不同写法，而是两个不同的二进制 type codes。

可以复制，回答的是依赖，不是真实

未知且 safe-to-copy 的辅助 chunk 可以穿过任何程度的编辑。若它标为 unsafe-to-copy，而程序添加、删除、修改或重排了关键 chunks，就不得把它复制进输出。若编辑器只改变辅助 chunks，则仍可保留。

这条规则把责任拆开：扩展作者声明自己的数据是否依赖关键图像数据；编辑器知道自己改了哪些部分；旧软件不必理解私有语义，也能执行确定性分支。代价是扩展设计必须受限。辅助 chunk 可以依赖关键 chunk，却不应依赖另一个辅助 chunk；对全文件内容的依赖无法由一个 bit 表达。

今天的 W3C PNG 第三版 延续了这套机制，并把顺序边界写得更细：复制未知 unsafe chunk 时，不能改变它相对关键 chunks 的位置；即使是 safe chunk，也不能任意跨越 IDAT 前后。safe-to-copy 从来不等于“可以随意搬动”。

CRC 结束了一个字节问题，却没有结束语义问题

每个 chunk 的 CRC 覆盖 type 与 data，用于发现该范围内的意外损坏。RFC 2083 甚至举例：私有 chunk 可以保存其所依赖 PLTE 的 CRC，以判断调色板是否发生改变。

匹配的 CRC 不会指出是谁写入数据，也不会发现两个私有组织对同名 type 的不同解释。它不能证明一份标定在像素变化后仍然适用。若软件改写数据并重算 CRC，得到的只是“新字节与新校验值内部一致”。

这也是隐私问题容易被误判之处。PNG 第三版提醒，某些工具曾用透明度遮住像素，或只改 IHDR 尺寸而没有移除可恢复的图像数据；eXIf 还可能携带 GPS。预览画面干净不等于信息已经删除。反过来，safe-to-copy bit 也不是隐私等级，它只描述未知扩展对关键数据的依赖。

没有全局版本号，兼容性按功能结算

RFC 2083 有意不给 PNG signature 或文件加入全局 version number。过高的整体版本会让旧软件拒绝本可处理的文件，对私有扩展也无能为力。

chunk 属性让兼容性按实际功能判断。未知辅助功能可以跳过，未知关键功能必须停止。新旧软件是否能互操作，取决于文件真正用了什么，而不是一个笼统数字。W3C 的 PNG 扩展文档 至今仍把额外公共 chunks 独立列出。被登记、被识别、被正确理解是三个不同事实。

Lu Heng 关于最低初始规格、未来本地化决策与自愿采用的论述，可作为事后观察视角：PNG 用一层很薄的共同语法，让运行软件在本地接受、忽略或拒绝未来功能。这不是声称 1997 年的作者受 2026 年文章影响。

其现实层与象征性权力之分，则提醒我们精确命名证据。属性位、修改类别与复制/丢弃动作可以执行；“官方”“可信”“已授权”“内容准确”都是更大的主张，需要别的证据。

因此，一份 PNG 转换回执至少应保存输入 hash、按序 chunk 清单、type bytes、四个属性位、CRC 结果、编辑器认识的 type 集合、全部关键/辅助修改、每个未知 chunk 的保留决定、输出顺序与输出 hash。若元数据支撑公共表述，还需保存 schema、命名空间负责人、来源与其在编辑后仍适用的理由。

第四个字母没有为元数据背书。它只是把决定交给了明确的责任方。

来源