"Unexpected end of archive"

Eine ZIP-Datei ist kein einziger durchgehender Block — sie ist eine Abfolge von lokalen Datei-Einträgen, gefolgt von einem zentralen Verzeichnis ganz am Ende. Jeder Eintrag beginnt mit der Signatur PK\x03\x04, trägt seinen eigenen Namen, seine Kompressionsmethode und Größe und danach die per Deflate komprimierten Daten. Nach dem letzten Eintrag folgt das zentrale Verzeichnis (PK\x01\x02-Datensätze), und die Datei endet mit dem End Of Central Directory-Datensatz, PK\x05\x06. Dieses EOCD ist das Inhaltsverzeichnis: Es sagt dem Entpacker, wie viele Dateien es gibt und wo jede beginnt.

Hier liegt der Haken. Das Inhaltsverzeichnis befindet sich ganz am Ende der Datei. Wenn ein Download oder eine Kopie abbricht, ist genau das Ende das, was fehlt — der Entpacker springt also dorthin, wo das EOCD sein müsste, findet dort Daten (oder nichts) statt der Signatur PK\x05\x06 und meldet "Unexpected end of archive." Das Archiv ist nicht durcheinandergewürfelt; ihm fehlt schlicht sein Inhaltsverzeichnis und möglicherweise die letzte Datei oder zwei.

RAR und 7z scheitern auf dieselbe Weise aus demselben Grund. Ein RAR führt Block-Header und am Ende eine Archiv-Ende-Markierung; ein .7z hält seine Header-Datenbank am Ende der Datei und komprimiert normalerweise viele Dateien gemeinsam zu einem einzigen soliden Datenstrom. In jedem Fall sind die Metadaten, die das Werkzeug zuerst braucht, genau jene Metadaten, die ein Abschneiden zuerst zerstört.

Da sich jeder ZIP-Eintrag selbst beschreibt, ist das gesamte zentrale Verzeichnis für die Extraktion überflüssig — es ist ein Inhaltsverzeichnis, nicht die Daten. Das Werkzeug ignoriert das fehlende EOCD und durchläuft die Datei stattdessen von vorne nach hinten, greift jeden lokalen Header PK\x03\x04 auf, den es findet, und entpackt den darauf folgenden Deflate-Datenstrom, solange die Bytes reichen. Jede Datei, die vor dem Abbruch vollständig geschrieben wurde, kommt intakt zurück; die eine Datei, die auf dem Abschneidepunkt lag, kommt möglicherweise nur teilweise oder gar nicht zurück. Das läuft als reines TypeScript in deinem Tab — kein installiertes Archivprogramm, nichts wird irgendwohin gesendet.

RAR und 7z sind stärker eingeschränkt, aber nicht hoffnungslos. In einem RAR lassen sich die vor dem Abschneiden gespeicherten Dateien weiterhin decodieren, und ein RAR, das mit einem Wiederherstellungsdatensatz (recovery record) erstellt wurde, repariert sich erheblich besser, weil dieser Datensatz genau dafür ausgelegt ist, fehlende Blöcke zu rekonstruieren. Ein .7z ist der heikle Fall: ohne Wiederherstellungsdatensatz und mit solider Kompression, die die Dateien miteinander verkettet, kann der Verlust des Endes die Dekompression von allem nach dem letzten vollständigen Block zunichtemachen. Das Werkzeug rettet, was die überlebenden Blöcke zulassen, und ist ehrlich, wenn ein solider Datenstrom nicht fortgesetzt werden kann.

Keine Software kann Daten wiederherstellen, die nie in der Datei waren. Wenn der Download bei 60 % abbrach, existieren die letzten 40 % der komprimierten Daten nicht auf deiner Festplatte, und nichts — weder dieses Werkzeug noch WinRARs eigene Reparatur noch eine kostenpflichtige Recovery-Suite — kann sie zurückerfinden. Die Lösung dafür ist, das Archiv erneut von der Quelle herunterzuladen oder zu kopieren, damit du die vollständigen Bytes hast.

Was wir zuverlässig tun können, ist zu verhindern, dass ein nur teilweise angekommenes Archiv ein Totalverlust wird. Wenn neun von zehn Dateien ankamen, bevor die Verbindung abriss, gibt es keinen Grund, die neun zu verlieren, während man der zehnten hinterherjagt. Und weil der gesamte Vorgang in deinem Browser abläuft, wird ein Archiv, das Finanzunterlagen, Quellcode oder persönliche Dokumente enthalten könnte, nie auf einen unbekannten Server kopiert, nur um einen Blick hineinzuwerfen — du kannst den Netzwerk-Tab beobachten und bestätigen, dass kein einziges Byte deinen Rechner verlässt.