要約

  • RFC 2083 は四バイトの PNG チャンク型の各文字に、critical/ancillary、public/private、reserved、unsafe/safe-to-copy という別々の属性を持たせた。
  • 四文字目は編集時の依存関係を示す規則で、真実性の印ではない。critical データを変更した後、未知の unsafe ancillary チャンクは捨て、safe なものは保持できた。
  • チャンクが残り CRC が一致しても、証明できるのは限定されたバイトの保全だけである。私的名称の一意性、意味の鮮度、著者、権限、プライバシー、画像の主張までは証明しない。

編集ソフトがパレットを変え、IDAT を再生成したとする。既知のチャンクの間に見慣れない型がある。長さを読み、データを飛ばし、CRC を確認することはできる。しかし、それがヒストグラムなのか、物理校正なのか、権利情報なのか、独自工程の状態なのかは分からない。それでも出力に残すか決めなければならない。

RFC 2083 は未来の拡張をすべて理解するよう旧ソフトに要求しなかった。未知であることを正直に扱う小さな決定面を作った。各チャンクは長さ、四バイトの型、データ、四バイトの CRC からなる。型は ASCII の英字範囲に限定されるが、実装は文字列ではなく固定されたバイナリ値として扱う。各バイトの bit 5 が属性であり、ロケール依存の大小文字変換を使ってはならない。

四つの文字は四つの役割を分けた

一文字目は critical と ancillary を分ける。大文字の未知 critical 型に出会えば、デコーダーは安全に解釈できるふりをしてはいけない。小文字の未知 ancillary 型なら、無視して画像表示を続けられる。ancillary は「価値がない」という意味ではない。著作権、校正、位置情報は、人の判断には重要でも画素を取り出すためには不要な場合がある。

二文字目は public と private の名前空間を分ける。これはデコーダーの動作を変える認証ビットではなく、管理上の境界である。将来の public 割り当てと private 名の衝突は避けられるが、二つの組織が同じ private 名を別の意味に使う可能性は残る。そのため RFC は private データの先頭に追加の識別情報を置くよう勧めた。

三文字目は予約された。Version 1.0 では大文字が必要だったが、将来の仕様が小文字に意味を与えるかもしれないので、古いデコーダーはそれだけでエラーにすべきではないとされた。

四文字目は編集用である。小文字が safe-to-copy、大文字が unsafe-to-copy を示す。例の bLOb は ancillary、public、予約ビット 0、safe-to-copy となる。TEXT と Text は同じ名前の表記違いではなく、異なるバイナリ型である。

コピー可能とは、信じてよいという意味ではない

未知の safe ancillary チャンクは、大きな編集を受けてもコピーできる。unsafe なら、critical チャンクを追加・削除・変更・並べ替えた後は出力してはならない。ancillary だけを変更した場合は保持できる。

拡張の作者は critical 画像データへの依存を宣言し、編集ソフトは自分が行った変更を把握する。両者の知識を混ぜずに決定できる一方、拡張設計には制約が生じる。ancillary は critical に依存できるが、別の ancillary に依存してはならない。データストリーム全体への依存は一ビットでは表現できない。

現在の W3C PNG 第三版も同じ構造を維持し、順序の制約を明確にした。未知の unsafe チャンクは critical チャンクに対する位置を変えられず、safe チャンクでさえ IDAT の前後を自由にまたげない。safe-to-copy は safe-to-move ではない。

CRC は破損を検査しても意味を検証しない

CRC は各チャンクの型とデータを覆い、偶発的な破損を見つける。RFC 2083 は private チャンクが依存先 PLTE の CRC を記録し、パレット変更を検出する例も示した。

しかし CRC の一致は作者を認証せず、private 名の衝突も発見しない。編集前の校正が新しい画素に適用できることも示さない。変更後に CRC を再計算すれば、新しいバイト列と検査値が整合したというだけである。

この境界はプライバシーでも重要だ。第三版は、透明度だけで画素を隠したり、IHDR の寸法だけを変えて復元可能なデータを残した例、eXIf の GPS を挙げる。見た目が消えていても情報の削除は証明されない。逆に safe-to-copy はプライバシー分類ではなく、critical データへの依存宣言にすぎない。

全体版番号を置かず、機能ごとに互換性を判定した

RFC 2083 はファイル全体の version number を意図的に置かなかった。高い番号だけで旧デコーダーが処理可能な画像まで拒否する危険があり、private 拡張も表現できないからである。

未知 ancillary 機能は無視でき、未知 critical 機能は停止させる。互換性は抽象的なバッジではなく、実際に含まれる機能で決まった。W3C の PNG 拡張文書も追加の public チャンクをコアとは別に記録する。登録、認識、意味の理解は別々の状態である。

Lu Heng の最小初期仕様とローカルな将来判断は、後世から見るための有用なレンズになる。薄い共通規則が、実行中のソフトによる受容・無視・拒否を可能にした。ただし 2026 年の文章が 1997 年の設計に影響したという意味ではない。

現実の層と象徴的権力の区別も証拠を整理する。属性ビット、編集区分、コピーまたは削除は実行可能な事実である。「公式」「正確」「許可済み」「信頼できる」は追加の証明を要する。

変換記録には入力 hash、順序付きチャンク一覧、型の四バイト、属性解釈、CRC、編集ソフトが理解した型、critical/ancillary の変更、未知チャンクごとの判断、出力順序と出力 hash を残すべきだ。メタデータが公的主張を支えるなら、スキーマ、名前空間管理者、来歴、編集後も適用できる根拠がさらに必要になる。

四文字目が保証したのは内容ではない。判断責任の所在だった。

出典