Surowy DEFLATE (.deflate)
IETF StandardDEFLATE to najbardziej wszechobecny algorytm bezstratnej kompresji danych w historii informatyki, od ponad trzech dekad napędzający archiwa ZIP, strumienie GZIP, obrazy PNG oraz kompresję sieciową HTTP.
Konwertuj GZIP na DEFLATE
Darmowy konwerter z GZIP na DEFLATE w przeglądarce. Konwertuj pliki natychmiast na swoim urządzeniu.
Inspekcja i metadane
Systemy operacyjne i analizatory plików identyfikują pliki DEFLATE, sprawdzając początkową sekwencję bajtów binarnych:
Podpis nagłówka na poziomie bajtów (Magic Bytes)
Systemy operacyjne i analizatory plików identyfikują pliki DEFLATE, sprawdzając początkową sekwencję bajtów binarnych:
PODPIS HEX (OFFSET 0):
Surowy strumień DEFLATE nie ma stałej sygnatury; strumienie z opakowaniem zlib zaczynają się od zmiennych bajtów CMF/FLG.REPREZENTACJA ASCII: Brak stałej sygnatury ASCII
Normalizacja: IETF RFC 1951 / RFC 1950 (zlib)
Specyfikacja techniczna
| Architektura kontenera | Surowy strumień bitów RFC 1951 lub strumień RFC 1950 opakowany w zlib, z 2-bajtowym nagłówkiem i sumą kontrolną Adler-32 |
| Kompresja | Przesuwny słownik LZ77 (okno o rozmiarze do 32 KB) połączony z dynamicznym/statycznym kodowaniem entropijnym Huffmana |
| Kolejność bajtów (Endianness) | Kolejność pakowania bitów w formacie Little-Endian |
| Przestrzenie kolorów | Nie dotyczy (Strumień kompresji danych) |
| Kanały i struktura | Surowy strumień danych binarnych lub tekstowych |
| Maks. wymiary | Nieograniczona długość strumienia |
| Przezroczystość | 100% dokładne bitowo bezstratne odtwarzanie danych |
| Streaming i progresywne ładowanie | Strumień bitów oparty na blokach obsługuje dowolne ciągłe przesyłanie strumieniowe bajtów |
Techniczna macierz porównawcza: DEFLATE a konkurencja
| Atrybut techniczny | DEFLATE (Bieżący) | GZ | BROTLI | ZSTD |
|---|---|---|---|---|
| Standaryzacja | IETF RFC 1951 (Surowy) / RFC 1950 (zlib) | IETF RFC 1952 (Gzip) | IETF RFC 7932 (Brotli) | IETF RFC 8878 (Zstandard) |
| Okno przesuwne | Maksymalnie 32 kilobajty | Maksymalnie 32 kilobajty | Do 16 megabajtów | Do 2 gigabajtów |
| Tryb sumy kontrolnej | Adler-32 (w otoczce zlib) | CRC-32 (w otoczce gzip) | Brak wbudowanego strumienia | xxHash64 (szybki skrót 64-bitowy) |
| Codzienne użycie | Obrazy PNG, strumienie PDF, ZIP | Unix .tar.gz, HTTP gzip | Czcionki internetowe (WOFF2), HTTP br | Jądro systemu Linux, bazy danych, gry |
Typowe tryby uszkodzeń i przewodnik odzyskiwania szesnastkowego
Dekompresja kończy się błędem z komunikatem „Z_DATA_ERROR: incorrect data check”.
Główna przyczyna: Niezgodność 4-bajtowej sumy kontrolnej Adler-32 na końcu strumienia opakowanego w zlib.
Odzyskiwanie: Pomiń weryfikację Adler-32, używając surowej funkcji inflate, albo napraw plik za pomocą narzędzia Deflate Recovery w File2File.app.
Analiza bezpieczeństwa i wektory ataku na parser
Analizatory składni DEFLATE muszą ściśle weryfikować kody konstrukcji drzewa Huffmana, aby zapobiec zapisom wskaźników spoza zakresu.
Znane wektory ataku
- Niekompletne lub przekraczające dozwolone limity tablice długości kodów dynamicznego drzewa Huffmana mogą powodować nieprawidłowe odczyty pamięci.
- Bomba dekompresyjna (bomba zip) rozszerzająca małe ładunki do setek gigabajtów pamięci RAM.
- Przekroczenie bufora podczas odczytu w niezweryfikowanych kodach odległości okna przesuwnego.
Najlepsze praktyki obronne: Podczas dekompresji ogranicz maksymalny przydział pamięci i współczynnik rozrostu danych.
Pochodzenie historyczne i kamienie milowe
Główne zalety
- Niekwestionowany globalny standard: zaimplementowany w sprzęcie, systemach operacyjnych i każdym środowisku uruchomieniowym języka programowania.
- Wolny od patentów i opłat licencyjnych projekt gwarantujący otwarty dostęp w całej branży informatycznej.
- Szybka dekompresja przy niewielkim zużyciu pamięci (wymaga tylko 32 KB pamięci na okno przesuwne).
Ograniczenia techniczne i wady
- Okno przesuwne ograniczone do 32 KB zmniejsza skuteczność kompresji dużych plików zawierających powtarzające się dane w odległych miejscach.
- Niższa skuteczność kompresji nowoczesnych zasobów internetowych w porównaniu z nowszymi algorytmami, takimi jak Brotli i Zstandard.
- Surowe strumienie DEFLATE nie zawierają metadanych opisujących format ani ramki kontenera, jeśli nie zostaną opakowane w zlib lub gzip.
Ciekawe informacje techniczne
- Phil Katz opracował DEFLATE po tym, jak firma Unisys pozwała go w związku z opatentowanym algorytmem LZW używanym we wczesnych narzędziach PKARC.
- Standardowe bajty nagłówka zlib „78 9C" oznaczają domyślną kompresję, „78 01" niską kompresję, a „78 DA" maksymalną kompresję.
- Każdy obraz PNG na świecie używa DEFLATE do kompresji bloków pikseli IDAT.
Często zadawane pytania techniczne
Jaka jest różnica między DEFLATE, zlib i gzip?
DEFLATE to surowy algorytm kompresji (RFC 1951). Zlib dodaje do strumienia DEFLATE 2-bajtowy nagłówek i sumę kontrolną Adler-32 (RFC 1950). Gzip dodaje metadane pliku i sumę kontrolną CRC-32 (RFC 1952).
Dlaczego PNG używa algorytmu DEFLATE?
Format PNG został stworzony w 1995 roku, aby zastąpić GIF bez używania opatentowanych algorytmów LZW, wybierając do kompresji otwarty, wolny od opłat licencyjnych DEFLATE.
Jak mogę zdekompresować surowy plik .deflate?
Możesz zdekompresować surowe strumienie bajtów DEFLATE lub zlib do oryginalnych nieskompresowanych plików za pomocą aplikacji File2File.app bezpośrednio w przeglądarce internetowej.
Powiązane pary konwersji DEFLATE
Konwersja strumienia GZIP na surowy format DEFLATE usuwa zewnętrzną otoczkę pliku i metadane nagłówka, pozostawiając jedynie skompresowaną zawartość dla specjalistycznych protokołów sieciowych i niskopoziomowych archiwów.
Konwersja surowego strumienia DEFLATE na strumień GZIP pakuje skompresowany ładunek w standardowy kontener z nagłówkami metadanych, dzięki czemu systemy operacyjne i narzędzia sieciowe mogą go poprawnie odczytać.