GZ in XZ umwandeln

Nach den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern verlangt der Fiskus von Unternehmen, Buchungsbelege, Rechnungen und die zugehörigen Datenexporte über sechs bis zehn Jahre lesbar vorzuhalten — je nach Belegart. In der Praxis heißt das: ein Ordner voller gezippter Datenbank-Dumps, Kassensystem-Exporte und Log-Archive, die niemand mehr öffnet, aber die trotzdem irgendwo liegen müssen, auf einem Speicherplatz, für den monatlich bezahlt wird.

Für genau diesen Bestand lohnt sich diese Umwandlung. Sie ändert am Inhalt der Dateien nichts, packt dieselben Bytes aber mit einem deutlich stärkeren Verfahren neu, und bei Text — genau das, woraus Buchhaltungsexporte bestehen — ist die Ersparnis oft erheblich. Der Preis dafür ist Rechenzeit, die einmalig anfällt und niemanden warten lässt, der die Datei tatsächlich braucht.

Die Zahl erklärt fast alles. Gzip, seit Mai 1996 als RFC 1952 genormt, nutzt DEFLATE mit einem Rückschaufenster von 32 KB — beim Komprimieren von Byte eine Million kann es maximal bis Byte 968.000 zurückblicken, alles davor wird bei einer Wiederholung erneut von vorn kodiert, als wäre es nie gesehen worden. XZ, aus dem Jahr 2009, kann ein Wörterbuch von weit über einem Gigabyte fassen, arbeitet hier aber mit der Voreinstellung, mit der dieses Werkzeug tatsächlich packt: 8 MB — zweihundertsechsundfünfzigmal so weit wie gzip, nicht das Vielfache, das die maximal mögliche Einstellung suggerieren würde.

Genau das erklärt, warum die Ersparnis bei manchen Dateien riesig ausfällt und bei anderen bei null bleibt. Ein Datenbank-Dump wiederholt Spaltennamen in jeder Zeile über Gigabyte hinweg, und XZ lernt sie einmal, während gzip sie tausendfach neu entdeckt. Ein Bilderarchiv oder ein Videoordner in einer GZ-Datei hat dagegen keine solche Wiederholung mehr, weil die Redundanz schon vom JPEG- oder H.264-Codec entfernt wurde, bevor gzip die Datei überhaupt sah — und kein noch so starker Kompressor erfindet eine Struktur, die nicht mehr da ist.

Die Rechenzeit beim Komprimieren ist der auffällige Preis und der unwichtigste, weil sie einmalig von einer Maschine bezahlt wird, die auf niemanden wartet. XZ ist bei derselben Aufgabe deutlich langsamer als gzip — eine direkte Folge des um ein Vielfaches größeren Wörterbuchs — und für einen Auftrag, der über Nacht durch einen ganzen Speicherbestand läuft, ist das schlicht kein Problem, das sich zu optimieren lohnt.

Der Arbeitsspeicher beim Entpacken ist der Preis, der tatsächlich entscheidet, und er wird gern übersehen. Gzip braucht zum Auspacken seine 32-KB-Fenstergröße, praktisch also nichts. XZ braucht einen Puffer in der Größenordnung des Wörterbuchs, mit dem die Datei geschrieben wurde. Auf einem Laptop oder einem Server ist das unauffällig. Auf einem eingeschränkten System mit wenig Arbeitsspeicher entscheidet dieser Wert, ob das Archiv sich überhaupt öffnen lässt.

Beide Formate komprimieren genau einen Datenstrom und kennen deshalb weder Verzeichnis noch mehrere Mitglieder. In der Praxis ist eine .gz-Datei fast immer eine .tar.gz-Datei: ein TAR, das Namen und Ordnerstruktur trägt, umhüllt von gzip. Die Umwandlung nimmt beide Schichten ab und setzt beide wieder auf — die Mitglieder werden in ein frisches TAR gepackt, und dieses TAR wird mit xz komprimiert.

Der Fall, den man kennen sollte: War die Quelle kein Tarball, sondern eine einzelne gezippte Datei wie kassenabschluss_2019.gz, baut die Umwandlung trotzdem ein TAR darum. Zurückkommt also ein Tarball, der die eine Datei enthält, statt eines einzelnen komprimierten Stroms. Harmlos, wenn mit tar xJf ausgepackt wird, verwirrend, wenn stattdessen unxz erwartet wird und eine Datei namens output.tar auftaucht.

Ein gzip-Strom trägt im Kopf ein Feld für den ursprünglichen Dateinamen, weshalb das Auspacken von rechnung.gz auf einem Unix-System auch rechnung.pdf zurückgeben kann, ohne dass die Endung das verraten hätte. XZ kennt kein solches Feld. Es speichert eine Prüfsumme und nichts darüber, woher die Daten stammten.

Das hat eine praktische Folge an beiden Enden dieser Umwandlung: Weil gzip einen Namen speichert und xz nicht, kommt ein inneres Tarball aus einer GZ-Datei unter einem sinnvollen Namen an und aus einer XZ-Datei unter dem, was das eigene Auspackwerkzeug wählt. Die Lehre daraus ist einfach — die Endung der heruntergeladenen XZ-Datei ist die einzige Beschriftung, die sie je tragen wird, also besser gleich rechtsverbindlich benennen: etwas.tar.xz statt eines vagen Archivs.

Ein gzip-Strom endet mit einer CRC-32 und der unkomprimierten Länge, ein XZ-Strom trägt eine eigene Prüfsumme über die entpackten Daten, standardmäßig CRC-64. In beiden Fällen erzeugt ein abgeschnittener Download oder ein gekipptes Bit beim Entpacken einen Fehler statt einer Datei, die still zu kurz gelesen wird.

Was beide nicht können, ist zu sagen, welche einzelne Datei beschädigt ist, denn auf dieser Ebene gibt es keine einzelnen Dateien. Ein ZIP oder ein 7Z führt je Eintrag eine eigene Prüfsumme und kann melden, dass ein Mitglied von vierzig beschädigt ist; ein komprimierter Strom kann nur melden, dass der ganze Strom beschädigt ist. Wird eine Integritätsprüfung je Mitglied gebraucht, weil im Ernstfall der Rest des Archivs gerettet werden soll, ist ein Stromkompressor die falsche Bauform für diese Aufgabe.

Diese Umwandlung läuft nicht auf dem eigenen Gerät. Die meisten Werkzeuge auf dieser Website halten die Datei lokal — das Neupacken von Archiven gehört zu den Ausnahmen, weil dafür echte Programme wie 7-Zip und xz gebraucht werden. Die Datei geht verschlüsselt an einen Container, der diese Programme ausführt und keinen eigenen Zugang zum offenen Internet besitzt.

Jeder Auftrag bekommt ein eigenes Arbeitsverzeichnis auf einem speicherbasierten Dateisystem, gelöscht, sobald der Auftrag endet, unabhängig vom Ausgang. Läuft ein Vorgang länger als sechzig Sekunden, wird er beendet — ein beschädigtes Archiv treibt einen Kompressor häufiger in eine Endlosschleife, als dass es sauber scheitert. Der kostenlose Tarif nimmt 25 MB je hochgeladener Datei an, was für einen einzelnen Log-Export viel Text ist und für einen kompletten Datensatz eine echte Grenze.

BZ2 war lange die zweite Antwort auf „gzip komprimiert nicht genug", und auf den meisten Textinhalten unterliegt es XZ inzwischen auf beiden Achsen zugleich — schlechteres Verhältnis, langsameres Entpacken. Die Registry führt BZ2 deshalb als veraltet. Sein einziger verbliebener Vorteil ist die Kehrseite des Speicherpunkts von oben: bzip2 arbeitet in Blöcken von höchstens 900 KB, das Entpacken braucht also nie viel Arbeitsspeicher.

Die Entscheidung ist also selten eine Frage der Kompressionsrate. XZ wählen, wenn die auspackende Maschine ein gewöhnlicher Rechner ist, was fast immer zutrifft, und BZ2 nur, wenn das nicht der Fall ist — ein altes Gerät, ein Container mit engem Speicherlimit, ein System, auf dem xz tatsächlich nicht verfügbar ist und nicht werden kann.

Eine repräsentative Datei zuerst umwandeln und beide Größen vergleichen sagt zuverlässiger, was der Rest des Bestands tun wird, als jede Faustregel — die Antwort entscheidet sich am Inhalt, nicht am Format, und dieselbe Umwandlung halbiert ein Log-Archiv und bewegt einen Ordner voller Fotos kaum. Bewegt sich die erste Datei kaum, ist damit schon gezeigt, dass die Daten keine langreichweitige Wiederholung enthalten, die ein Kompressor finden könnte.

Anschließend die Inhaltsliste prüfen, nicht nur die Größe. tar tJf auf das Ergebnis anwenden und die Anzahl der Einträge und die Pfade mit dem vergleichen, was die GZ-Datei enthielt, besonders auf der obersten Ebene — ein aus einem Verzeichnis heraus gepacktes Archiv und eines, das von dessen Elternverzeichnis aus gepackt wurde, unterscheiden sich um einen führenden Ordner in jedem Pfad, und dieser Unterschied bricht Skripte lange, nachdem sich jemand an die Umwandlung erinnert.

Beide Formate sind verlustfrei, jedes Byte, das in die GZ-Datei hineinging, kommt aus der XZ-Datei wieder heraus. Verloren gehen kann nur, was der alte Behälter über die Dateien wusste, statt in ihnen zu tragen — ein von gzip gespeicherter Name, und auf manchen Wegen Rechte und Zeitstempel.

Ist die Liste geprüft und die Größe wie erwartet, hat das Original keine Aufgabe mehr. Bei einer Buchhaltungsdatei mit gesetzlicher Aufbewahrungsfrist lohnt sich trotzdem eine kurze Notiz im eigenen Ablagesystem, wann und womit umgepackt wurde — nicht weil die Umwandlung etwas verändert, sondern weil eine Prüfung Jahre später wissen sollte, warum die Datei heute anders heißt als beim Ursprung.

Nicht jeder Bestand profitiert. Eine Handvoll kleiner Dateien, insgesamt wenige Megabyte, spart durch das Umpacken kaum etwas ein, das den zusätzlichen Schritt in der eigenen Ablage rechtfertigen würde — hier zählt eher, dass alle Dateien am selben Ort liegen und einheitlich benannt sind, als dass sie ein paar Prozent kleiner sind. Und ein Archiv, das ohnehin bald wieder gebraucht wird, gehört nicht in diesen Arbeitsgang: Bei häufigem Zugriff zahlt sich die langsamere Kompression nicht aus, wenn dafür jedes Mal eine längere Entpackzeit in Kauf genommen wird.

Der ehrliche Anwendungsfall bleibt der Bestand, der wegen einer Aufbewahrungsfrist liegen bleiben muss, aber praktisch nie geöffnet wird. Dort zahlt sich die einmalige Rechenzeit über Jahre gegen die laufenden Speicherkosten, und genau diese Rechnung — einmaliger Aufwand gegen wiederkehrende Kosten — ist es wert, vor einem größeren Migrationslauf kurz aufzuschreiben, statt sie stillschweigend vorauszusetzen.