Zusammenfassung

  • RFC 1952 beschreibt eine gzip-Datei als Folge selbständiger Member mit eigenem Header, komprimierten Blöcken und CRC32/ISIZE-Trailer.
  • Ein angehängtes Member erweitert die entpackte Ausgabe, ohne den alten Präfix zu ändern; Index, Direktzugriff und optimale Kompression über die Grenze entstehen dadurch nicht.
  • Optionale Namen und Zeiten sind keine authentisierte Herkunft. CRC32 erkennt Beschädigung, ISIZE zählt modulo 2^32, und beide gelten nur für ein Member.

Der unveränderte Anfang und das neue Ende

Ein Archiv kann gestern vollständig gewesen sein und heute mehr Inhalt liefern, obwohl jedes gestrige Byte gleich blieb. Ein Prozess hat ein weiteres vollständiges gzip-Member angehängt. Wer von vorn dekomprimiert, erhält beide Eingaben nacheinander.

RFC 1952 legt diese Struktur fest: Eine gzip-Datei ist eine Reihe unmittelbar aufeinanderfolgender Member. Jedes beginnt mit einem erkennbaren Header und endet mit seinem Trailer. Die Grenze schließt die Einheit, nicht jede künftige Fortsetzung unter demselben Dateinamen.

Der RFC-Editor-Eintrag datiert P. Deutschs Informational RFC auf Mai 1996. Er ist kein Standards-Track-Internetstandard und kein Nachweis einheitlicher Implementierungen. Ziele waren Portabilität, Streaming mit begrenztem Zwischenspeicher, patentfreie Implementierbarkeit und gzip-Kompatibilität. Direktzugriff gehörte ausdrücklich nicht dazu.

Pflichtfelder tragen andere Autorität als Beschreibungen

Zwei feste Bytes erkennen gzip, CM=8 bezeichnet DEFLATE. FLG kündigt optionale Felder an; reservierte Bits müssen null sein. Darüber müssen unabhängige Leser übereinstimmen.

MTIME, FNAME, FCOMMENT, FEXTRA und FTEXT können Zeit, ursprünglichen Namen, Kommentar, Erweiterung oder Textcharakter beschreiben. Ein Leser muss sie überspringen können, selbst wenn er sie nicht nutzt. Zeitwert null bedeutet keine verfügbare Zeit; OS darf ignoriert werden.

Ein eingebetteter Name beweist keine Herkunft. Ein Kommentar ist keine Signatur. Eine Zeit sagt nicht, wann das Member in die heutige Datei gelangte. Die Felder sind Behauptungen, deren Vertrauen außerhalb des Formats entsteht.

FHCRC enthält, falls gesetzt, die unteren 16 Bits eines CRC32 über den vorherigen Header. CRC32 im Trailer gilt für die dekomprimierten Member-Daten. ISIZE enthält deren ursprüngliche Länge modulo 2^32. Nähe im Layout bedeutet keine gleiche Beweiskraft.

Ein gültiger CRC nennt keinen Autor

CRC32 macht zufällige Beschädigung sichtbar. Wer absichtlich ein anderes Member erzeugt, kann jedoch einen passenden CRC berechnen. Die Prüfung bestätigt interne Konsistenz, nicht Identität, Berechtigung oder Gewahrsam.

ISIZE läuft nach 2^32 über und ist pro Member. Eine absolute Gesamtlänge einer beliebigen Multi-Member-Datei steht nicht im letzten Trailer; sie entsteht durch vollständiges Lesen und Summieren.

Auch die Kompression ist eine andere Schicht. RFC 1951 definiert DEFLATE. RFC 1950 verwendet dafür den anderen zlib-Wrapper mit eigenem Header und Adler-32. RFC 6713 registrierte später application/gzip und application/zlib und unterschied gzip mit dateigerechtem Header und Trailer vom zlib-Streamformat.

Implementierung zeigt unterschiedliche Sichtweiten

Das GNU-gzip-Handbuch dokumentiert, dass verkettete komprimierte Dateien von gunzip vollständig entpackt werden. Es nennt auch die Kosten: Gemeinsame Kompression ist meist effizienter, und --list meldet bei mehreren Membern nur unkomprimierte Größe und CRC des letzten.

Damit können Dekompression und Auflistung zwei korrekte, aber verschieden breite Ansichten liefern. Ein Audit, das die letzte lokale Zahl als Gesamteigenschaft ausgibt, überschreitet seine Evidenz.

RFC 9110 führt gzip als HTTP-Inhaltskodierung mit Verweis auf RFC 1952. Das definiert den Begriff, nicht identisches Verhalten aller Proxys, Clients und Scanner gegenüber mehreren Membern.

Der kleinste gemeinsame Vertrag wiederholt sich

Running-Code Primacy trennt Publikation, Implementierung und Betrieb. Der RFC belegt das Format; GNU gzip liefert begrenzte Implementierungsevidenz. Eine universelle Verbreitungsbehauptung folgt daraus nicht.

Minimum Initial Specification erklärt die Strenge der kleinen Grenze: Erkennung, Methode, Längen, reservierte Bits und Trailer müssen gemeinsam sein. Anzeige von Kommentaren und Nutzung der Zeit dürfen lokal bleiben.

Reality Layers trennt das Symbol „eine Datei“ von der ausgeführten Folge mehrerer Anfänge, Abschlüsse und Kontrollen. Der Name ist einheitlich; die operative Struktur ist es nicht.