Konverter GZIP til Deflate
Konvertering af en GZIP-strøm til rå DEFLATE fjerner den ydre filindpakning og overskriftsmetadata, så kun den komprimerede nyttelast er tilbage til specialiserede netværksprotokoller og lavniveau-arkiver.
Formatsammenligning & tekniske specifikationer
| Specifikation | GZIP | DEFLATE |
|---|---|---|
| MIME-type | application/ | application/ |
| Type | DEFLATE-strømcontainer | rå DEFLATE-strøm |
| Komprimering | DEFLATE (RFC 1951) | LZ77 + Huffman-kodning |
| Standardspecifikation | IETF RFC 1952 | IETF RFC 1950 / RFC 1951 |
| Magic Bytes-header | 1F 8B (gzip ID1/ID2) | 78 01 / 78 9C / 78 DA (zlib header bytes) |
Formatoversigt og anvendelse
Konvertering af en GZIP-strøm til rå DEFLATE forekommer ofte i webudvikling, netværksprogrammering og arbejdsgange med lavniveaudatalagring. Udviklere arbejder ofte med GZIP, når enkelte filer gemmes på disk, fordi formatet indeholder nyttige metadata som originale filnavne og ændringstidsstempler. Moderne HTTP-komprimeringsprotokoller og specifikke binære formater forventer imidlertid udelukkende den komprimerede nyttelast uden indpakningsbytes. Udførelsen af denne konvertering sætter ingeniører i stand til at sende standardiserede komprimerede data direkte ind i netværksstrømme eller tilpassede parsere. Opbygning af en tilpasset HTTP-svarhåndterer eller arbejde med ZIP-arkiver kræver f.eks. ofte fjernelse af GZIP-overskriften og CRC32-fodnoten for at isolere det rå algoritme-output. Fjernelse af disse ekstra beholderdata reducerer overhead, når hver eneste byte tæller i ressourcebegrænsede programmeringsmiljøer.
Tekniske specifikationer og codec-oversigt
En GZIP-strøm med MIME-typen application/gzip bruger en containerstruktur defineret i RFC 1952. Den begynder med en to byte lang signatur (0x1F, 0x8B), efterfulgt af komprimeringsflag, ændringstidspunkt, operativsystem-id og eventuelt et filnavn. De komprimerede data ligger i midten, og filen afsluttes med en fire byte lang CRC32-kontrolsum og en fire byte lang angivelse af den ukomprimerede størrelse. Rå DEFLATE er derimod en bitstrøm efter RFC 1951 uden fast signatur, rammeheader eller afsluttende felt. MIME-typen application/zlib beskriver en zlib-indpakning omkring DEFLATE efter RFC 1950, ikke en rå DEFLATE-strøm. Konvertering fra GZIP til rå DEFLATE fjerner GZIP-metadata og kontrolsum, mens den komprimerede nyttelast bevares.
OS- og browserkompatibilitet
Rå DEFLATE-strømme kører indbygget på tværs af moderne operativsystemer og webmiljøer gennem standardiserede programmeringssprog som Python, Node.js og C++. Browsere håndterer DEFLATE indbygget via HTTP content-encoding-overskriftsstakken. Operativsystemer som Windows, macOS og Linux understøtter rå strømme gennem systemkomprimeringsbiblioteker som zlib. Mobilplatforme, herunder Android og iOS, leverer direkte API-adgang til DEFLATE-rutiner til tilpassede lagringslag i apps.
Nyttig information
Kontrollér altid, at din målparser forventer en ren RFC 1951-strøm snarere end en zlib-indpakket strøm, fordi zlib tilføjer en overskrift på to bytes, som rå DEFLATE-analysatorer vil afvise.
Ofte stillede spørgsmål
Hvordan konverterer man GZIP-strøm til rå DEFLATE uden kvalitetstab?
Begge formater anvender identiske tabsfrie komprimeringsalgoritmer. Konvertering af dem betyder ganske enkelt at indlæse GZIP-beholderen, fjerne headeren på ti byte og traileren på otte byte samt gemme de indre komprimerede blokke. Ingen data går tabt, fordi den underliggende algoritme forbliver uændret.
Hvad er forskellen mellem en GZIP-strøm og rå DEFLATE?
GZIP er en komplet filbeholder, der indeholder en magic byte-overskrift, originale filnavne, ændringstidsstempler og en kontrolsumstrailer. Rå DEFLATE er blot de komprimerede data i sig selv, uden overskrifter, afsluttende data eller filmetadata.