ZIP in XZ umwandeln

Ein Forschungsdatenzentrum, das einen Datensatz auf GovData oder einem Uni-Repositorium ablegt, packt einmal und wird tausendfach heruntergeladen. Genau in diesem Verhältnis liegt der ganze Sinn von XZ: Die Rechenzeit beim Packen zahlt eine Maschine einmal, die Übertragungsgröße zahlt jeder, der die Datei zieht — und bei einem Forschungsdatensatz, der über Jahre zitiert und nachgeladen wird, ist das kein kleiner Unterschied.

Bei einer Datei, die ein einziges Mal an einen Kollegen geht, gibt es diese Rechnung nicht. Die Sekunden fürs Packen sind dann die einzigen Sekunden, die die Datei in ihrem ganzen Leben kostet, und ein gewöhnliches ZIP wäre längst fertig. Der Umweg über XZ lohnt sich, wenn die Datei ein Publikum hat, nicht, wenn sie einen Empfänger hat.

Ein XZ-Strom komprimiert genau einen Datensatz und weiß nichts von Dateinamen, Pfaden oder Rechten. Was in einem ZIP mehrere Einträge mit eigenen Namen sind, muss deshalb erst in ein TAR gepackt werden, das diese Struktur trägt, und dieses TAR wird dann als ein einziges Objekt komprimiert.

Das ist keine Notlösung, sondern die Anordnung, mit der praktisch jede Linux- und macOS-Distribution ihre Quellcode-Archive ausliefert — deshalb trägt so gut wie jedes veröffentlichte Archiv am Ende .tar.xz und nicht bloß .xz. Wer die Datei umbenennt, sollte diese Endung verwenden, nicht die kürzere.

Jede Datei aus dem ZIP kommt exakt so aus dem XZ-Archiv wieder heraus, wie sie hineinging. Was nicht übersteht, ist alles, was der Container über die Dateien gespeichert hat statt in ihnen: ein Passwort ist danach ohne Bedeutung, und je nach Ausgangsformat gehen auch ursprüngliche Zugriffsrechte und Zeitstempel verloren.

Für einen Datensatz, der ohnehin ohne Passwortschutz veröffentlicht wird, spielt das kaum eine Rolle. Für ein Archiv, in dem die Dateirechte etwas bedeuten — etwa ein Unix-Berechtigungsschema, das ein Skript später auswertet —, lohnt sich ein Blick vor der Veröffentlichung, statt es erst beim Empfänger zu bemerken. Der Inhalt jeder einzelnen Datei selbst ist davon nicht betroffen — es geht ausschließlich um das, was der Container zusätzlich über die Dateien wusste.

Zwischen diesen sechs Archivformaten ist jede Richtung möglich, XZ ist also nur eines von mehreren Zielen für dasselbe ZIP. RAR ist die eine Ausnahme: Es kann als Quelle gelesen, aber nie geschrieben werden — das ist eine Lizenzfrage des UnRAR-Werkzeugs, keine Lücke im Angebot.

Wer unsicher ist, ob XZ die richtige Wahl ist, kann dasselbe ZIP probeweise auch als 7Z oder als TAR.GZ umwandeln und die Ergebnisgrößen vergleichen, bevor er sich für die Veröffentlichung festlegt.

Anders als die meisten Werkzeuge auf dieser Seite verlässt die ZIP-Datei hier tatsächlich dein Gerät: Sie geht verschlüsselt an unseren Server, wird dort entpackt, in ein TAR geschrieben, mit xz komprimiert und zurückgeschickt. Das steht hier ausdrücklich, weil es die Ausnahme ist und nicht die Regel.

Der Container, der das erledigt, hat keinen eigenen Internetzugang und bekommt für jeden Auftrag ein frisches, leeres Verzeichnis. Dieses Verzeichnis wird gelöscht, sobald der Auftrag endet — auch dann, wenn etwas schiefgeht.

Client-seitige Umwandlungen auf dieser Seite erlauben bis zu 100 MB, weil dein eigenes Gerät rechnet. Sobald ein Server beteiligt ist, sinkt die freie Grenze auf 25 MB pro Datei — das ist Rechenzeit, die wir bezahlen, nicht dein Prozessor.

Für einen Quellcode-Baum oder einen tabellarischen Datensatz reicht das fast immer. Bei einem größeren Rohdatenexport lohnt es sich, das ZIP vor dem Hochladen zu teilen, statt an der Grenze zu scheitern.

Jeder aufgerufene Prozess auf dem Server wird nach sechzig Sekunden beendet, wenn er bis dahin nicht fertig ist. Weil das Umpacken mehrere Schritte hintereinander sind — entpacken, tarieren, komprimieren —, kann der ganze Auftrag insgesamt länger dauern als eine Minute, ohne dass ein einzelner Schritt die Grenze reißt.

Bei einem sehr großen oder stark verschachtelten Archiv kann trotzdem genau ein Schritt daran scheitern. Ein zu tief verschachteltes ZIP mit vielen tausend kleinen Dateien ist der Fall, bei dem das am ehesten passiert. Der ganze Auftrag selbst darf dabei durchaus länger als eine Minute dauern, solange kein einzelner der drei Schritte — Entpacken, Tarieren, Komprimieren — für sich allein diese Grenze reißt.

Ein GZ-Strom kann den ursprünglichen Dateinamen im Kopf mitführen, ein XZ-Strom nicht. Es speichert lediglich eine Prüfsumme und die verwendeten Kompressionsfilter, keinen Namen und keinen Zeitstempel für das Ganze.

Die gesamte Beschreibung der Datei liegt danach also im Dateinamen, den du selbst vergibst. Aus release-1.4.zip wird zunächst release-1.4.xz — vor der Veröffentlichung lohnt es sich, daraus release-1.4.tar.xz zu machen, damit sofort klar ist, was in der Datei steckt.

Ein Datensatz, der sowohl per Skript geladen als auch von Hand angeschaut wird, profitiert davon, in beiden Formen zu existieren: dem ZIP für alle, die per Doppelklick hineinschauen wollen, und dem TAR.XZ für alles, was per Kommandozeile weiterverarbeitet. Beide entstehen aus demselben Ordner, keine der beiden Formen ist ein Kompromiss.

Wer nur eine Datei veröffentlichen will, sollte diejenige nehmen, die die eigentlichen Empfänger auch tatsächlich öffnen können. Ein hervorragend komprimiertes Archiv, das niemand entpacken kann, spart keine Zeit — es verschiebt sie nur in die Support-Anfrage danach.

Windows öffnet ein ZIP ohne Zusatzsoftware direkt im Explorer, eine .xz- oder .tar.xz-Datei dagegen nicht. Für eine interne Weitergabe an Kolleginnen und Kollegen, die überwiegend mit Windows arbeiten, ist das ZIP deshalb oft die pragmatischere Wahl, auch wenn es größer ist.

Das Umpacken lohnt sich vor allem dann, wenn die Datei tatsächlich viele Male von einem Werkzeug abgerufen wird, das mit tar und xz umgehen kann — ein Paketmanager, ein Build-Skript, ein Download-Spiegel. Für alles andere ist der Aufwand größer als der Gewinn.

Der Auftrag legt seine eigene, hochgeladene Datei unter einem festen Namen ab, nicht unter dem Namen, den sie auf dem eigenen Rechner trägt — der ursprüngliche Dateiname erreicht die Festplatte des Servers also gar nicht erst. Das entpackte ZIP, das erzeugte TAR und die fertige XZ-Datei liegen für die Dauer des Auftrags in genau diesem einen Verzeichnis.

Dieses Verzeichnis wird gelöscht, sobald der Auftrag endet, und zwar in einem Codepfad, der auch bei einem Fehler durchläuft — ein abgebrochener Auftrag hinterlässt also keine Reste. Die zurückgegebene Datei trägt außerdem eine Anweisung, sie nirgendwo zwischenzuspeichern, sodass auch auf dem Weg zurück zu deinem Browser keine Kopie liegen bleibt.

Bevor überhaupt ein Byte entpackt wird, prüft der Server, wie viel Platz das ZIP nach dem Entpacken beanspruchen würde. Meldet das Archiv mehr als zwei Gigabyte an entpacktem Inhalt an, wird der Auftrag abgelehnt, statt den Speicher des Containers mit einer einzigen großen Datei zu füllen.

Das trifft in der Praxis selten ein gewöhnliches Quellcode-Archiv, aber gelegentlich einen Datensatz mit vielen unkomprimierten Rohdateien. Wo das passiert, ist das Teilen in mehrere kleinere ZIP-Dateien vor dem Hochladen der einzige Weg um diese Grenze herum.

Der Inhalt jeder einzelnen Datei bleibt beim Umpacken exakt erhalten, das Archiv drumherum aber wird neu geschrieben — Reihenfolge, Zeitstempel und die Kompressionsentscheidungen entstehen neu bei jedem Lauf. Zwei Umwandlungen desselben ZIP können sich deshalb als Ganzes unterscheiden, obwohl beide korrekt sind.

Das ist nur dann wichtig, wenn irgendwo im Anschluss die Prüfsumme des ganzen Archivs verglichen wird statt der Prüfsummen der einzelnen Dateien. Eine Veröffentlichungs-Pipeline, die einen Hash-Wert neben den Download stellt, sollte diesen Wert immer aus der tatsächlich ausgelieferten Datei berechnen, nicht aus einem früheren Umpack-Vorgang.