DEFLATE-Datenstrom ohne Header (.deflate)
IETF StandardDEFLATE ist der weit verbreitete verlustfreie Datenkomprimierungsalgorithmus in der Geschichte der Informatik und treibt seit über drei Jahrzehnten ZIP-Archive, GZIP-Streams, PNG-Bilder und die HTTP-Webkomprimierung an.
Von GZIP zu DEFLATE konvertieren
Kostenloser Konverter von GZIP zu DEFLATE im Browser. Konvertieren Sie Dateien sofort auf Ihrem Gerät.
Untersuchen & Metadaten
Betriebssysteme und Dateianalyseprogramme identifizieren DEFLATE-Dateien anhand der führenden binären Bytefolge:
Headersignatur auf Byte-Ebene (Magic Bytes)
Betriebssysteme und Dateianalyseprogramme identifizieren DEFLATE-Dateien anhand der führenden binären Bytefolge:
HEX-SIGNATUR (OFFSET 0):
Raw DEFLATE hat keine feste SignaturASCII-DARSTELLUNG: Keine feste Signatur
Standardisierung: IETF RFC 1951 / RFC 1950 (zlib)
Technische Daten
| Container-Architektur | Roh-Bitstream nach RFC 1951 oder zlib-eingebetteter Stream nach RFC 1950 mit 2-Byte-Header und Adler-32-Prüfsumme |
| Kompression | LZ77-Gleitwörterbuch (mit einem Fenster von bis zu 32 KB), kombiniert mit dynamischer/statischer Huffman-Entropiekodierung |
| Byte-Reihenfolge | Little-Endian-Bitpackreihenfolge |
| Farbräume | Nicht zutreffend (Datenkompressionsstrom) |
| Kanäle und Struktur | Roh-Binär- oder Textdatenstrom |
| Max. Abmessungen | Unbegrenzte Datenstromlänge |
| Transparenz | 100% bitgenaue verlustfreie Datenwiedergabe |
| Streaming und progressive Darstellung | Blockbasierter Bitstream unterstützt beliebiges kontinuierliches Byte-Streaming |
Technische Vergleichsmatrix: DEFLATE und Konkurrenzformate
| Technisches Attribut | DEFLATE (Aktuelles Format) | GZ | BROTLI | ZSTD |
|---|---|---|---|---|
| Standardisierung | IETF RFC 1951 (Roh) / RFC 1950 (zlib) | IETF RFC 1952 (Gzip) | IETF RFC 7932 (Brotli) | IETF RFC 8878 (Zstandard) |
| Schiebefenster | Maximal 32 Kilobyte | Maximal 32 Kilobyte | Bis zu 16 Megabyte | Bis zu 2 Gigabyte |
| Prüfsummenmodus | Adler-32 (im zlib-Wrapper) | CRC-32 (im gzip-Wrapper) | Keine integrierte Prüfsumme im Datenstrom | xxHash64 (schneller 64-Bit-Hash) |
| Alltägliche Verwendung | PNG-Bilder, PDF-Streams, ZIP | Unix .tar.gz, HTTP gzip | Webschriften (WOFF2), HTTP br | Linux-Kernel, Datenbanken, Gaming |
Häufige Datenbeschädigungen und Leitfaden zur Wiederherstellung anhand von Hex-Daten
Dekomprimierung schlägt fehl mit „Z_DATA_ERROR: incorrect data check“.
Ursache: Abweichung in der 4-Byte-Adler-32-Prüfsumme am Ende des in zlib gekapselten Datenstroms.
Wiederherstellung: Umgehen Sie die Adler-32-Prüfung mit Raw-Inflate oder reparieren Sie die Datei mit der Deflate-Wiederherstellung von File2File.app.
Sicherheitsanalyse und Angriffsvektoren für Parser
DEFLATE-Parser müssen Codes für die Konstruktion von Huffman-Bäumen strikt validieren, um Zeigerschreibvorgänge außerhalb der Grenzen zu verhindern.
Bekannte Angriffsvektoren
- Unvollständige oder überbelegte Bitlängentabellen für dynamische Huffman-Bäume führen zu ungültigen Speicherlesevorgängen.
- Dekomprimierungsbombe (Zip-Bombe), die winzige Nutzlasten auf Hunderte von Gigabyte RAM ausdehnt.
- Puffer-Überlesen bei nicht validierten Schiebefenster-Distanzcodes.
Empfohlene Schutzmaßnahmen: Erzwingen Sie begrenzte maximale Speicherzuweisungen und Begrenzungen der Expansionsrate während der Dekomprimierung.
Historische Ursprünge & Meilensteine
Hauptvorteile & Stärken
- Der unbestrittene globale Standard: implementiert in Hardware, Betriebssystemen und jeder Programmierlaufzeitumgebung.
- Das patentfreie und lizenzgebührenfreie Design garantiert offenen Zugang in der gesamten Computerindustrie.
- Schnelle Dekomprimierung bei minimalem Speicherbedarf (benötigt nur 32 KB Schiebefensterspeicher).
Technische Einschränkungen & Nachteile
- Das Schiebefenster ist auf 32 KB begrenzt, wodurch die Komprimierungseffektivität bei großen Dateien mit weiter entfernten Redundanzen verringert wird.
- Geringere Komprimierungsverhältnisse bei modernen Web-Assets im Vergleich zu neueren Algorithmen wie Brotli und Zstandard.
- Rohe DEFLATE-Datenströme enthalten ohne zlib- oder gzip-Hülle keine selbstbeschreibenden Metadaten oder Containerrahmen.
Interessante technische Fakten
- Phil Katz erfand DEFLATE, nachdem er von Unisys wegen des patentierten LZW-Algorithmus verklagt worden war, der in frühen PKARC-Dienstprogrammen verwendet wurde.
- Die standardmäßigen zlib-Headerbytes „78 9C“ zeigen die Standardkomprimierung an, „78 01“ eine geringe Komprimierung und „78 DA“ die maximale Komprimierung.
- Jedes PNG-Bild auf der Erde verwendet DEFLATE, um seine IDAT-Pixelblöcke zu komprimieren.
Häufig gestellte technische Fragen
Was ist der Unterschied zwischen DEFLATE, zlib und gzip?
DEFLATE ist der rohe Komprimierungsalgorithmus (RFC 1951). Zlib verpackt DEFLATE mit einem 2-Byte-Header und einer Adler-32-Prüfsumme (RFC 1950). Gzip verpackt DEFLATE mit Dateimetadaten und einer CRC-32-Prüfsumme (RFC 1952).
Warum verwendet PNG DEFLATE?
Das PNG-Format wurde 1995 entwickelt, um GIF zu ersetzen, ohne patentierte LZW-Algorithmen zu verwenden. Für die Komprimierung wurde der offene, lizenzgebührenfreie DEFLATE-Algorithmus gewählt.
Wie kann ich eine rohe .deflate-Datei dekomprimieren?
Sie können rohe DEFLATE- oder zlib-Bytestreams direkt in Ihrem Webbrowser mit File2File.app in originale unkomprimierte Dateien dekomprimieren.
Passende DEFLATE-Konvertierungen
Die Umwandlung eines GZIP-Datenstroms in einen unverpackten DEFLATE-Datenstrom entfernt den äußeren Datei-Wrapper und die Header-Metadaten. Übrig bleibt die komprimierte Nutzlast für spezielle Netzwerkprotokolle und Archive auf niedriger Ebene.
Die Umwandlung eines unverpackten DEFLATE-Datenstroms in einen GZIP-Datenstrom verpackt die komprimierte Nutzlast mit Metadaten-Headern in einen Standardcontainer, den Betriebssysteme und Webtools korrekt lesen können.