ZIP aus einem abgebrochenen Download

Ein ZIP wird von vorn nach hinten geschrieben, aber von hinten nach vorn gelesen. Jede Datei, die du hinzugefügt hast, wird als lokaler Dateieintrag gespeichert — ein Header, der mit der Signatur PK\x03\x04 beginnt und den Namen, die Kompressionsmethode (0 = gespeichert, 8 = Deflate) und dann die komprimierten Bytes trägt —, doch der maßgebliche Index dafür, wo diese Einträge liegen, ist das zentrale Verzeichnis (PK\x01\x02-Datensätze), das zuletzt geschrieben wird, unmittelbar vor dem 22 Byte großen End Of Central Directory-Datensatz, PK\x05\x06. Ein Entpacker öffnet die Datei, indem er ans Ende springt und rückwärts nach dieser PK\x05\x06-Signatur sucht — bis zu rund 65 557 Bytes zurück, weil der Datensatz mit einem Kommentarfeld variabler Länge endet. Erst wenn er den EOCD gefunden hat, weiß er, wie viele Einträge das Archiv enthält und wo jeder Datensatz des zentralen Verzeichnisses beginnt.

Stell dir nun den Download vor, der bei 70 % stehen blieb. Die Bytes, die nie ankamen, sind die zuletzt geschriebenen: das zentrale Verzeichnis und der EOCD. Der Entpacker springt ans Ende, sucht rückwärts, sieht nie PK\x05\x06 und gibt auf, bevor er eine einzige Datei anrührt. Genau das ist die Ursache für das "End-of-central-directory signature not found" von unzip, das "Unexpected end of archive" von 7-Zip und WinRAR, das "The Compressed (zipped) Folder is invalid" des Explorers und das "Unable to expand … (Error 2)" des macOS-Archivierungsprogramms. Keine dieser Meldungen bedeutet, dass die gespeicherten Dateien durcheinandergeraten sind — sie bedeuten, dass das Inhaltsverzeichnis am Ende verschwunden ist.

Abgebrochene Downloads sind dafür besonders anfällig, weil so viele ZIPs erzeugt werden. Ein Archiv, das ein Server spontan zusammensetzt — ein "Alle herunterladen" aus einem Cloud-Speicher, das ZIP-Pendant eines GitHub-Quelltext-Tarballs, ein Export-Paket —, wird meist per Streaming ausgeliefert: Bit 3 der Allzweck-Bitflag (0x0008) ist gesetzt, die komprimierte Größe und die CRC-32 in jedem lokalen Header werden auf null gelassen, und die echten Werte werden nach den Daten des Eintrags in einem Data Descriptor (PK\x07\x08) angehängt. Für solche Archive ist das zentrale Verzeichnis der einzige Ort, an dem die Größen garantiert sind, sodass der Verlust des Endes einen normalen Entpacker doppelt trifft. Die halb geschriebene Datei, die dein Browser hinterlassen hat — eine .crdownload von Chrome/Edge, eine .part von Firefox oder eine .zip, die schlicht kürzer ist als das Content-Length der Antwort —, enthält immer noch jeden vollständigen Eintrag bis zum Abschnitt und nichts danach.

Die Rettung braucht den fehlenden Index überhaupt nicht, denn in einem ZIP beschreibt sich jeder lokale Eintrag selbst. Statt ans Ende zu springen, durchläuft das Werkzeug die Datei vorwärts ab Offset 0, hält an jedem lokalen Header PK\x03\x04 an, den es findet, liest den Dateinamen und die Kompressionsmethode und dekomprimiert dann den nachfolgenden Deflate-Stream. Deflate terminiert sich selbst: Ein Stream ist eine Folge von Blöcken, und der letzte Block trägt ein auf 1 gesetztes BFINAL-Bit, sodass der Decoder erkennen kann, wo die Daten eines Eintrags enden — selbst wenn das Größenfeld im lokalen Header von einem Streaming-Writer auf null gelassen wurde. Wenn der Stream sauber endet, verzeichnet das Werkzeug eine wiederhergestellte Datei, überspringt einen etwaigen nachfolgenden Data Descriptor PK\x07\x08 und fährt beim nächsten PK\x03\x04 fort. Das läuft als reines TypeScript in deinem Tab — kein unzip-Binary, nichts wird übertragen.

Das Ergebnis: Jede vor der Unterbrechung vollständig geschriebene Datei kommt zurück, in der richtigen Reihenfolge, mit ihrem ursprünglichen Namen und Verzeichnispfad. Ist der Download mitten in der vierten von zehn Dateien gestorben, erhältst du die ersten drei intakt und eine vierte, die unvollständig oder verworfen ist; die sechs, die nie ankamen, lassen sich nicht herbeizaubern, aber darum ging es ohnehin nie. Ein "gespeicherter" Eintrag (Methode 0, keine Kompression — üblich für bereits komprimierte Inhalte wie JPEGs oder MP4s, die ins ZIP gelegt werden) lässt sich noch einfacher retten: Seine Bytes werden bis zum Abschneidepunkt unverändert kopiert, sodass selbst eine nur zur Hälfte angekommene große Datei häufig ein brauchbares Anfangsfragment liefert statt gar nichts.

Kein Werkzeug kann Bytes zurückgeben, die deine Festplatte nie erreicht haben. Ist die Verbindung bei 70 % abgerissen, existieren die letzten 30 % der komprimierten Daten lokal nicht, und nichts — weder diese Seite noch die "Repair"-Funktion von WinRAR noch eine kostenpflichtige Recovery-Suite — kann sie rekonstruieren. Die einzige echte Lösung für das fehlende Ende ist, das Archiv erneut herunterzuladen — von der Quelle, idealerweise mit einem Client, der HTTP-Range-Requests unterstützt, damit eine unterbrochene Übertragung dort fortsetzt, wo sie stehen blieb, statt neu zu beginnen. Hat der Server ein ETag oder ein Content-Length gesendet, zeigt dir der Vergleich dieser Länge mit der Größe deiner unvollständigen Datei genau, wie viel wirklich fehlt.

Ein paar ehrliche Grenzfälle. Ein verschlüsseltes ZIP (ein beim Packen gesetztes Passwort, Bit 0 der Allzweck-Bitflag) lässt sich ohne das Passwort nicht durchlaufen, weil die Eintragsdaten Chiffretext sind, dem keine Deflate-Struktur folgt. Ein sehr großes Archiv im ZIP64-Format führt eigene abschließende Strukturen — den ZIP64-EOCD-Datensatz (PK\x06\x06) und seinen Locator (PK\x06\x07) —, die mit dem Ende genauso verloren gehen wie der klassische EOCD, doch der Vorwärtsdurchlauf stellt die lokalen Einträge unabhängig vom Format weiterhin wieder her. Und ein Download, der so kurz ist, dass nur ein Fragment des allerersten lokalen Headers ankam, bietet nichts zum Durchlaufen. Alles zwischen diesen Extremen ist erreichbar.

Weil der gesamte Vorgang in deinem Browser abläuft, wird das Archiv nie auf einen Server kopiert, nur um hineinzuschauen — was zählt, wenn ein "Alle herunterladen"-Paket Steuerdokumente, exportierte Chatverläufe oder privaten Quelltext enthält. Du kannst den Netzwerk-Tab öffnen, die Wiederherstellung ausführen und bestätigen, dass 0 Bytes der Datei jemals deinen Rechner verlassen.