ZIP in GZ umwandeln

Fast niemand sucht diese Umwandlung aus eigenem Antrieb, sondern weil eine Anleitung es verlangt. Eine Uberspace- oder Hetzner-Dokumentation nennt ein „.tar.gz", ein Deploy-Skript entpackt seine Fracht mit tar, ein v-Server hat tar installiert und nichts, das ZIP ohne Nachinstallation liest. Das Archiv ist eine ZIP-Datei, weil Windows oder macOS sie so erzeugt haben — die Zielumgebung erwartet die Unix-Form desselben Inhalts.

Das Ziel ist also Formangleichung, nicht Kompression. Sobald die Datei die erwartete Form hat, ist die Aufgabe erledigt, und der Rest dieser Seite behandelt vor allem, was diese Form eigentlich bedeutet — denn genau das lässt sich bei dieser Umwandlung nicht verbergen.

Das ist der Kern des ganzen Paares. GZ, festgelegt in RFC 1952 aus dem Jahr 1992, komprimiert genau einen Bytestrom. Es speichert keine Mitgliederliste, keine Pfade, keine Verzeichnisse — laut Registrierung ist es ein Streamformat mit genau einem Eintrag, dessen bekannte Einschränkung eine völlig fehlende Verzeichnisstruktur ist.

Eine ZIP-Datei dagegen ist ein Container: eine Menge unabhängig komprimierter Einträge mit einem Verzeichnis am Ende, das sagt, wo jeder liegt. Das eine lässt sich nicht direkt ins andere gießen. Etwas muss die vielen Dateien erst zu einem einzigen Strom zusammenfassen, bevor gzip überhaupt ansetzen kann — und dieses Etwas ist TAR.

Die Verarbeitung erstellt aus dem entpackten Inhalt ein TAR-Archiv und komprimiert dieses Tar mit gzip. Die heruntergeladene Datei hat also zwei Schichten: außen einen gzip-Strom, darin ein Tar-Archiv, darin die eigentlichen Dateien. Jeder Unix-Rechner packt beides mit einem einzigen tar -xzf wieder aus.

Der Dateiname wirkt zunächst seltsam. Der Download übernimmt den Namensstamm der Originaldatei mit der Zielendung, aus „fotos.zip" wird also „fotos.gz" und nicht „fotos.tar.gz". Wer downstream auf die Endung achtet — etwa ein automatisches Deploy-Skript —, benennt die Datei entsprechend um; ein Auspacken mit einem reinen gzip-Werkzeug hinterlässt sonst ein „.tar", das noch einmal geöffnet werden muss.

Von einer Umwandlung erwartet man oft eine Ersparnis in Bytes, und die bleibt hier meist aus. Beide Formate komprimieren mit DEFLATE und schauen beide durch ein 32-KB-Fenster zurück, sie finden also weitgehend dieselben Wiederholungen und erzeugen auf denselben Daten ähnlich große Ergebnisse. Es wechselt der Container, nicht der Kompressor.

Ein struktureller Unterschied kann in beide Richtungen wirken. ZIP komprimiert jeden Eintrag einzeln, während gzip einen einzigen zusammenhängenden Tar-Strom sieht — ein Archiv mit vielen kleinen, ähnlichen Dateien kann als Tarball etwas besser komprimieren, während die Tar-Schicht ihrerseits 512-Byte-Blockpolsterung hinzufügt. Bei den meisten echten Archiven gleichen sich beide Effekte ungefähr aus. Wer wirklich eine kleinere Datei will, sollte stattdessen zu XZ umwandeln.

Ein gzip-Strom kann den ursprünglichen Dateinamen und das Änderungsdatum dessen tragen, was er komprimiert hat, und das ist ein echter Unterschied zu seinen beiden Geschwistern: Weder BZ2 noch XZ speichern überhaupt einen Namen. Eine kleine Eigenschaft mit sichtbarer Folge — ein ausgepacktes .gz liefert oft von selbst wieder einen sinnvollen Dateinamen zurück.

Hier steht in diesem Header „output.tar", weil das Tarball tatsächlich das war, was komprimiert wurde. Gut zu wissen, wenn man den Download von Hand auspackt und sich wundert, wo der eigene Dateiname geblieben ist: Der liegt auf der äußeren Datei, die frei gewählt wurde, während das innere Tar den Namen trägt, den dieser Zwischenschritt vergeben hat.

Die Registrierung führt GZ als von allen Browsern unterstützt, was richtig ist und regelmäßig falsch verstanden wird. Browser handeln gzip als Übertragungskodierung aus: Der Server komprimiert eine Antwort, der Browser entpackt sie, bevor irgendetwas davon zu sehen ist, und es entsteht nie eine Datei. Deshalb ist praktisch das gesamte Web gezippt, ohne dass es auffällt.

Eine heruntergeladene .gz-Datei ist etwas anderes. Der Browser behandelt sie als undurchsichtige Datei und speichert sie unverändert, weil die Kompression hier der Inhalt ist und nicht der Transportweg. Weder der Windows-Explorer noch der macOS-Finder packt sie von sich aus aus, wer sie empfängt, braucht 7-Zip, Keka oder eine Shell — ein guter Grund, ein Archiv als ZIP zu belassen, wenn es an eine Person geht statt an einen Server.

Enthält die ZIP nur eine einzige Datei, verschwindet die Unstimmigkeit, um die es auf dieser Seite geht — genau dafür wurde GZ entworfen, und das Ergebnis ist der schlichte, naheliegende Fall: ein komprimierter Strom, kein Container, keine Unklarheit über den Inhalt.

Die Verarbeitung schickt die Datei trotzdem durch denselben Tar-Schritt, aus Gründen der Einheitlichkeit — heruntergeladen wird also weiterhin ein gezipptes Tar-Archiv und kein direktes Gzip der Datei selbst. Wer ausdrücklich Letzteres braucht — ein „.sql.gz" oder „.log.gz" für ein Werkzeug, das genau das erwartet —, erledigt das lokal mit gzip; für diesen Fall ist die falsche Form schlimmer als gar keine Umwandlung.

Anders als die meisten Umwandlungen hier verlässt diese das eigene Gerät. Die ZIP wird über eine verschlüsselte Verbindung hochgeladen, auf dem eigenen Server mit 7-Zip entpackt und neu gepackt, und Upload, Zwischen-Tar und Ergebnis liegen in einem eigenen Arbeitsverzeichnis, das nach Abschluss des Auftrags gelöscht wird — auch wenn der Auftrag fehlschlägt.

Damit sind die Grenzen gesteckt: 25 MB je Datei auf der kostenlosen Stufe, sechzig Sekunden je einzelnem Verarbeitungsschritt, bevor er abgebrochen wird — das Entpacken, das Tarren und das Gzippen zählen dabei getrennt, ein Auftrag mit mehreren Schritten kann also insgesamt länger als eine Minute dauern —, und eine Ablehnung für jedes Archiv, das mehr als 2 GB entpackter Größe ankündigt. Auch ein passwortgeschütztes ZIP endet hier mit einer Meldung statt einer Hängepartie, weil der Entpacker bewusst ein leeres Passwort erhält, damit er das Problem meldet, statt auf eines zu warten.

Alle drei Ziele erzeugen dieselbe Tar-in-einem-Kompressor-Form und unterscheiden sich nur im umgebenden Kompressor. GZ schaut durch ein 32-KB-Fenster zurück, ist der schnellste der drei und auf praktisch jedem System vorhanden. BZ2 sortiert Blöcke von bis zu 900 KB, komprimiert Text besser als gzip und ist im hiesigen Bestand das einzige Archivformat, das als veraltet statt aktuell geführt wird. XZ führt in seiner Standardstufe ein 8-MB-Wörterbuch und erzeugt die kleinste der drei Dateien mit deutlichem Abstand, allerdings mit der längsten Packzeit.

Die Wahl ist meist vorgegeben durch das, was man beliefert. Deploy-Werkzeuge, Container-Ebenen und die meisten Upload-Endpunkte setzen gzip voraus; Quellcode-Veröffentlichungen sind größtenteils zu xz gewechselt; bz2 taucht meist dort auf, wo ein Jahre altes Archiv nachgebildet werden soll. Gibt nichts eine Antwort vor, ist gzip die sichere Standardwahl, und genau deshalb wird dieses Paar deutlich häufiger gesucht als seine beiden Geschwister.

Es lohnt sich zu prüfen, ob wirklich drinsteckt, was hochgeladen wurde, und die Kontrolle unterscheidet sich je nach Plattform. Unter Linux oder macOS listet tar -tzf den Inhalt, ohne etwas auszupacken — der schnellste Weg zu sehen, ob Pfade und Dateizahl stimmen. Unter Windows öffnet 7-Zip oder Keka die Datei direkt und zeigt zunächst das Tar darin, dann mit einem zweiten Klick dessen Inhalt.

Dieser zweite Klick ist zu erwarten und kein Zeichen für einen Fehler. Grafische Archivprogramme entfernen für gewöhnlich eine Schicht nach der anderen, sodass ein gezipptes Tarball zunächst wie ein Archiv mit genau einer .tar-Datei darin wirkt, und erst die Ebene darunter zeigt die eigentlichen Dateien. Das ist dieselbe zweischichtige Struktur, um die es hier die ganze Zeit ging, nur von außen betrachtet.