Zusammenfassung

  • RFC 2083 gab jedem Buchstaben eines vier Byte langen PNG-Chunktyps eine Eigenschaft: kritisch/ergänzend, öffentlich/privat, reserviert sowie unsicher/sicher zu kopieren.
  • Das vierte Bit regelte die Bearbeitung, nicht die Wahrheit. Nach Änderungen an kritischen Bilddaten musste ein unbekannter unsicherer Zusatzchunk entfallen; ein sicherer durfte erhalten bleiben.
  • Erhalt und passende CRC belegten begrenzte Byteverwahrung, nicht Eindeutigkeit privater Namen, semantische Aktualität, Urheberschaft, Erlaubnis, Privatsphäre oder eine zutreffende Bildaussage.

Ein Editor ändert die Palette und schreibt IDAT neu. Zwischen bekannten Chunks findet er einen fremden Typ. Länge, Datenbereich und CRC sind lesbar, doch der Inhalt könnte Histogramm, Kalibrierung, Rechtehinweis oder proprietärer Arbeitszustand sein. Ohne die Bedeutung zu kennen, muss das Programm entscheiden, ob die Bytes in die Ausgabe gehören.

RFC 2083 verlangte nicht, dass alte Software jede künftige Erweiterung versteht. Es definierte einen ehrlichen Pfad für Unwissen. Jeder Chunk besteht aus Länge, vier Typbytes, Daten und CRC. Die Typbytes liegen in den ASCII-Buchstabenbereichen, müssen aber als feste Binärwerte behandelt werden. Maßgeblich ist Bit 5 jedes Bytes, nicht eine sprachabhängige Groß-/Kleinschreibungsfunktion.

Vier Buchstaben trennten vier Aufgaben

Der erste Buchstabe markiert critical oder ancillary. Groß bedeutet kritisch: Ein unbekannter Typ kann für die Bildinterpretation notwendig sein, daher darf der Decoder keinen Erfolg vortäuschen. Klein bedeutet ergänzend: Der unbekannte Chunk kann ignoriert und das Bild weiter dargestellt werden. Ergänzend heißt nicht unwichtig; Rechte, Ort oder Kalibrierung können für Menschen entscheidend sein, ohne zur Pixelgewinnung nötig zu sein.

Der zweite Buchstabe trennt öffentliche und private Namen. Er ist eine Namespace-Regel, keine Authentisierung. Künftige öffentliche Zuweisungen meiden die private Form, doch zwei Organisationen können denselben privaten Namen verschieden verwenden. Deshalb empfahl der RFC zusätzliche Identifikation in den privaten Daten.

Der dritte Buchstabe war reserviert. Version 1.0 verlangte Großschreibung, alte Decoder sollten bei Kleinschreibung jedoch nicht allein deshalb scheitern: Eine spätere Spezifikation konnte dem Bit Bedeutung geben.

Der vierte Buchstabe steuert den Editor. Klein heißt safe-to-copy, groß unsafe-to-copy. bLOb steht im Beispiel für ergänzend, öffentlich, Reserved-Bit null und kopiersicher. TEXT und Text sind verschiedene Binärcodes.

Kopiersicher war kein Wahrheitsurteil

Ein unbekannter sicherer Zusatzchunk darf trotz umfangreicher Änderungen kopiert werden. Ist er unsicher und wurden kritische Chunks hinzugefügt, gelöscht, verändert oder umgeordnet, darf er nicht in die Ausgabe. Bei ausschließlich ergänzenden Änderungen kann er erhalten bleiben.

Der Erweiterungsautor erklärte damit die Abhängigkeit, der Editor kannte seine Änderung. Zugleich begrenzte die Regel das Design: Zusatzchunks durften von kritischen Chunks abhängen, nicht voneinander. Eine Abhängigkeit vom gesamten Datenstrom ließ sich in diesem Bit nicht ausdrücken.

Die heutige W3C PNG Third Edition bewahrt die Trennung und präzisiert die Reihenfolge. Ein unbekannter unsicherer Chunk darf gegenüber kritischen Chunks nicht verschoben werden; selbst ein sicherer darf nicht frei über die IDAT-Grenze wandern. Safe-to-copy war nie safe-to-move.

Die CRC schloss eine Bytefrage, nicht die Bedeutungsfrage

Die CRC deckt Typ und Daten des Chunks ab und entdeckt versehentliche Beschädigung. RFC 2083 schlug sogar vor, in einem privaten Chunk die CRC des abhängigen PLTE zu speichern, um Palettenänderungen festzustellen.

Eine Übereinstimmung authentisiert keinen Autor und erkennt keine private Namenskollision. Sie beweist nicht, dass eine Kalibrierung noch zum bearbeiteten Bild passt. Eine neu berechnete CRC zeigt nur, dass neue Bytes und neuer Prüfwert zusammenpassen.

Die Datenschutzgrenze ist ähnlich. Die Third Edition erinnert an Werkzeuge, die Pixel nur per Transparenz verdeckten oder Abmessungen änderten, ohne wiederherstellbare Daten zu entfernen; eXIf kann GPS enthalten. Eine saubere Vorschau belegt keine Löschung. Das Safe-to-copy-Bit ist ebenso wenig eine Datenschutzklasse: Es beschreibt nur die Abhängigkeit von kritischen Daten.

Kompatibilität pro Funktion statt globaler Versionsnummer

RFC 2083 ließ bewusst eine globale Versionsnummer weg. Ein hoher Wert hätte alte Decoder Dateien ablehnen lassen, obwohl keine unbekannte kritische Funktion benutzt wurde; private Erweiterungen wären weiterhin unbeschrieben geblieben.

Unbekannte Zusatzfunktionen konnten ignoriert werden, unbekannte kritische Funktionen erzwangen den Stopp. Die tatsächlich vorhandenen Merkmale entschieden. Das W3C-Dokument zu PNG-Erweiterungen listet weitere öffentliche Chunks weiterhin separat. Registrierung, Erkennung und semantische Unterstützung sind verschiedene Tatsachen.

Lu Hengs spätere Beschreibung einer minimalen Anfangsspezifikation und lokalisierter Zukunftsentscheidung bietet eine rückblickende Linse: Eine dünne gemeinsame Grammatik erlaubte lokales Annehmen, Ignorieren oder Ablehnen. Das behauptet keinen Einfluss eines Textes von 2026 auf das Design von 1997.

Die Trennung von Realitätsebenen und symbolischer Macht diszipliniert die Beweise. Bit, Änderungsklasse und Kopier-/Löschaktion sind ausführbar. „Offiziell“, „wahr“, „autorisiert“ und „vertrauenswürdig“ sind zusätzliche Behauptungen.

Ein Transformationsbeleg sollte Eingabehash, geordnetes Chunkinventar, Typbytes, vier Eigenschaften, CRCs, bekannte Typen des Editors, kritische und ergänzende Änderungen, jede Entscheidung, Ausgabereihenfolge und Ausgabehash halten. Stützen Metadaten eine öffentliche Aussage, kommen Schema, Namespace-Verantwortlicher, Herkunft und fortbestehende Anwendbarkeit hinzu.

Der vierte Buchstabe zertifizierte keine Metadaten. Er ordnete die Entscheidung zu.

Quellen