XZ in GZ umwandeln

Die Person, die diese Umwandlung braucht, hat die Datei meist nicht selbst erstellt. Ein Open-Source-Projekt veröffentlicht ein .tar.xz, und jemand muss es weiterreichen: auf einem internen Spiegel-Server bereitstellen, in ein Firmen-Repository einspielen, an ein Build-Image aus einer Zeit hängen, in der xz noch nicht selbstverständlich war.

Deutsche Hochschulrechenzentren betreiben einige der größeren Linux- und Software-Spiegelserver Europas, und genau dort trifft ein modernes xz-Archiv gelegentlich auf ein älteres, minimales Abbild ohne xz-Unterstützung. Wer ohne eine solche externe Vorgabe konvertiert, sollte die XZ-Datei stattdessen einfach so lassen, wie sie ist.

Der Vorteil von gzip ist historisch gewachsen, nicht technisch begründet. DEFLATE, der Algorithmus hinter gzip, wurde im Mai 1996 als RFC 1951 veröffentlicht, gzips eigener Behälter im selben Monat als RFC 1952 — derselbe Algorithmus steckt seither in PNG, in jeder ZIP-Datei, in HTTPs Content-Encoding und in jedem Git-Objekt. Jede Plattform, die eines davon beherrscht, bringt DEFLATE ohnehin schon mit.

XZ kam erst 2009 dazu und musste als eigenständige Bibliothek nachgerüstet werden. Auf einem gewöhnlichen Linux-System ist das trivial, weil der Paketmanager davon abhängt; in einem minimalen Container-Image oder auf einer abgesicherten Umgebung ist es eine bewusste Entscheidung, die jemand treffen muss — und häufig nicht getroffen wurde.

Der Unterschied liegt in einer einzigen Zahl: gzips DEFLATE durchsucht ein Fenster von 32 KB, XZs LZMA2 arbeitet mit einem Wörterbuch von bis zu 64 MB. Beim millionsten Byte sieht gzip nur bis zum 968.000sten zurück, xz dagegen bis zum Anfang des gesamten Archivs.

Bei einem Archiv aus vielen ähnlichen Dateien — hunderten Quelldateien mit gleichem Lizenzkopf, einem Jahr an Logzeilen aus denselben vierzig Vorlagen — lernt xz jedes Muster einmal, gzip lernt es ständig neu. Bei einem Archiv aus bereits komprimierten Bildern oder Videos verschwindet der Unterschied fast völlig, und genau dann kostet diese Umwandlung fast nichts.

Die Umwandlung entpackt das Archiv und schreibt aus dem Inhalt ein neues TAR, bevor gzip komprimiert. Jede einzelne Datei darin kommt Byte für Byte identisch heraus — verlustfrei —, aber das Archiv selbst ist neu, mit möglicherweise anderer Reihenfolge, anderen Zeitstempeln und anderen Rechten, und eine veröffentlichte Prüfsumme des Originals passt danach nicht mehr.

Beim Spiegeln einer Veröffentlichung ist das eine Frage der Darstellung, keine der Richtigkeit: eine eigene Prüfsumme über die tatsächlich ausgelieferte Datei veröffentlichen und daneben klar sagen, dass die maßgebliche Version das Original mit der Signatur des Projekts ist. Wer beides braucht, stellt beide Dateien bereit, statt die eine durch die andere zu ersetzen.

Ein kleiner, aber praktischer Vorteil entsteht auf diesem Weg: Ein gzip-Stream trägt ein Feld für den ursprünglichen Dateinamen, ein xz-Stream nicht — xz speichert nur eine Prüfsumme, keine Herkunft. Deshalb liefert gunzip datensatz.gz gelegentlich direkt den Namen datensatz.tar zurück, während unxz datensatz.xz eine namenlose Datei hinterlässt, die sich erst als Archiv entpuppt.

Verlassen sollte man sich darauf nicht — viele Werkzeuge schreiben nur einen generischen Namen hinein oder ignorieren das Feld beim Entpacken. Wichtiger ist die Endung: Die Datei vor der Veröffentlichung tar.gz nennen, sonst entpackt jemand mit gunzip und hält am Ende ein loses TAR-Archiv in der Hand.

Gzip decodiert linear mit einem festen 32-KB-Fenster und ohne Index — genau das macht curl https://… | tar xzf - möglich, ein Download, der nie auf der Festplatte landet. Ein Webserver kann eine Antwort komprimieren, bevor sie fertig ist, und ein Log-Versand komprimiert im laufenden Betrieb, ohne die Gesamtmenge zu kennen.

XZ lässt sich zwar ebenfalls streamen, benötigt dafür aber Speicher proportional zum gewählten Wörterbuch statt eines festen Werts. Auf einem eingebetteten Gerät, in einem speicherbegrenzten Container oder hinter einer harten Funktionsgrenze kann das den Unterschied machen zwischen Datenstrom, der einfach durchläuft, und einem, der scheitert.

Geht es tatsächlich um Speicher statt um Verbreitung, lohnt ein Blick auf bzip2: Es arbeitet in unabhängigen Blöcken von höchstens 900 KB und braucht dadurch beim Entpacken fast nichts, bei Textdateien komprimiert es sogar besser als gzip. Der Preis ist die Zeit — eine Burrows-Wheeler-Transformation rückgängig zu machen ist echte Rechenarbeit, nicht bloßes Kopieren.

Entscheidend ist, welches Problem tatsächlich vorliegt. Meldet ein System, dass kein Speicher zugewiesen werden kann, und ist Zeit kein Problem, ist bzip2 eine sinnvolle Antwort. Erkennt ein System das Format schlicht nicht, oder geht die Datei an Menschen statt an eine Pipeline, bleibt gzip ohne Umweg die richtige Wahl, weil bz2 in der Registry als veraltet geführt wird und längst nicht so verbreitet ist.

Diese Umwandlung läuft nicht im Browser, sondern auf dem Server, weil sie echte Programme wie 7-Zip, xz und gzip benötigt. Die Datei reist verschlüsselt zu einem Container, der diese Werkzeuge ausführt und ohne eigenen Zugang zum offenen Internet arbeitet.

Jeder Auftrag bekommt ein eigenes, temporäres Arbeitsverzeichnis, das nach Abschluss gelöscht wird — unabhängig vom Ergebnis. Diese Umwandlung ist dabei kein einziger Aufruf, sondern mehrere hintereinander — entpacken, das TAR auswickeln, neu einpacken, gzip darüberlegen —, und jeder einzelne Schritt für sich wird nach sechzig Sekunden abgebrochen, weil ein fehlerhaftes Archiv einen Kompressor eher in eine Endlosschleife schickt als es zum Absturz zu bringen. Der ganze Auftrag darf dadurch länger als sechzig Sekunden dauern, ohne dass ein einzelner Schritt die Grenze reißt. Der kostenlose Tarif nimmt Dateien bis 25 MB an, und ein Archiv wird schon vor dem Entpacken abgelehnt, wenn es eine Entpackgröße über 2 GB angibt.

Wer die eigene Download-Seite kontrolliert, fährt meist besser mit einer Ergänzung statt einer Umwandlung: das originale .tar.xz für alle, die es lesen können, daneben das .tar.gz für alle, die es nicht können, beide klar beschriftet. Das kostet ein wenig Speicherplatz, spart aber den Support-Aufwand.

Muss man sich für eine Datei entscheiden, entscheidet die Zielgruppe, nicht das bessere Format an sich. Ein öffentlicher Download für ein allgemeines Publikum, ein internes Artefakt für ungeprüfte Werkzeuge, ein Anhang an ein Kundenticket — dort gewinnt gzip. Eine Veröffentlichung, die sich gezielt an Linux-Entwicklerinnen und -Entwickler richtet, oder ein Archiv, das nur aufbewahrt und nicht verteilt wird — dort bleibt XZ die richtige Wahl, und diese Seite hat ihren Zweck erfüllt, wenn sie genau davon abrät.