"Unexpected end of archive" — was es bedeutet und was sich noch retten lässt

Der genaue Fehler, und was er dir sagt

Je nachdem, welches Tool die Datei öffnet, ändert sich der Wortlaut, aber nicht die Bedeutung. WinRAR zeigt:

Unexpected end of archive, und oft daneben The archive is either in unknown format or damaged.

7-Zip formuliert denselben Fehler als Unexpected end of dataoder, wenn der Schaden den Anfang der Datei erreicht, Cannot open the file as archive. Unter Linux oder macOS meldet das Kommandozeilen-unzip unexpected end of file oder das präzisere End-of-central-directory signature not found.

Jede einzelne dieser Zeichenketten beschreibt eine einzige Situation: Dem Tool ist die Datei ausgegangen, bevor das Format es zuließ. Ein ZIP oder RAR hat eine definierte Form, mit bestimmten Strukturen, die an bekannten Stellen sitzen sollen. Wenn die Datei kürzer ist, als diese Form es verlangt, stößt das Tool unerwartet auf das Ende und hält an. Das ist es, was "unexpected" hier bedeutet. Es ist kein zufälliger Aussetzer, und es sind normalerweise keine durcheinandergewürfelten Daten. Es ist eine Datei, der das Ende fehlt.

Ein ZIP führt seinen Index ganz am Ende

Um zu verstehen, warum ein fehlendes Ende so verheerend ist, hilft es zu wissen, wie ein ZIP aufgebaut ist. Ein Archiv sind zwei zusammengenähte Dinge. Zuerst kommen die Einträge: jede Datei, die du hinzugefügt hast, komprimiert und hintereinander weggeschrieben, und jede mit einem kleinen lokalen Header davor, der Name und Größe angibt. Zweitens, nach allen Einträgen, kommt das zentrale Verzeichnis: eine Tabelle, die jede Datei im Archiv auflistet und den exakten Byte-Offset, an dem jede beginnt.

Ein ZIP speichert zuerst die Dateien und zuletzt das Verzeichnis, das sie auflistet. Ein abgeschnittener Download verliert das Verzeichnis, nicht die Dateien davor.

Das zentrale Verzeichnis ist der Index des Archivs. Wenn du ein ZIP doppelklickst, springt das Tool ans Ende, liest dieses Verzeichnis und zeigt dir damit die Dateiliste. Den Index zuletzt zu platzieren ist Absicht: Es erlaubte dem ursprünglichen ZIP-Format, Dateien an ein Archiv anzuhängen, ohne das Ganze neu zu schreiben. Der Haken ist, dass die eine Struktur, die ein Tool zuerst braucht, genau die eine ist, die zuletzt gespeichert wird — jeder Schaden, der am Ende der Datei beginnt, trifft also direkt den Index. Das ist dasselbe Muster, das eine Tabelle so zerbrechlich macht, denn eine .xlsx-Datei ist in Wirklichkeit ein ZIP mit ihrem eigenen Verzeichnis am Ende.

Warum ein abgebrochener Download den Index verliert, nicht die Dateien

Ein ZIP wird von vorne nach hinten geschrieben und übertragen. Wenn ein Download stockt, eine Cloud-Synchronisation aufgibt oder ein USB-Stick mitten im Kopieren herausgezogen wird, ist die Datei, die auf deiner Festplatte landet, das, was vor der Unterbrechung ankam: Der Anfang ist intakt, das Ende schlicht abwesend. Weil das Verzeichnis hinten liegt, ist es das erste Opfer jedes Abschneidens. Die Einträge nahe dem Anfang, die eigentlichen komprimierten Dateien, sitzen unberührt da.

Das ist der ganze Grund, warum der Fehler so gut zu beheben ist. Das Tool findet das Verzeichnis nicht, weigert sich also, das Archiv auf die normale Weise zu öffnen, und meldet ein unerwartetes Ende. Aber die Dateien selbst waren nie das Problem. Ein Reparaturdurchlauf ignoriert das fehlende Verzeichnis und durchläuft das Archiv stattdessen vom Anfang her, liest jeden lokalen Header, nimmt die komprimierten Daten, die darauf folgen, und baut aus dem, was er findet, ein frisches Verzeichnis neu auf. Das Archiv öffnet wieder und listet jeden Eintrag, der physisch überlebt hat.

Eine schnelle Plausibilitätsprüfung unterscheidet ein Abschneiden von etwas Schlimmerem: Vergleiche die Dateigröße mit dem Original, falls du es kennst. Ein 240-MB-Archiv, das als 180 MB ankam, ist ein Lehrbuch-Abschnitt, und die fehlenden 60 MB sind nicht beschädigt, sie sind woanders. Auch deshalb ist der erneute Download der erste Zug. Die fehlenden Bytes existieren noch an der Quelle, und eine saubere Kopie schlägt jede Rettung einer unvollständigen. Wenn das Archiv aus einem Web-Download oder einem E-Mail-Anhang kam, versuche diesen Weg, bevor du reparierst. Die Windows-spezifische Fassung derselben Geschichte, in der der eingebaute Entpacker des Explorers strenger ist als die Tools oben, wird in „Der komprimierte (gezippte) Ordner ist ungültig“ behandelt.

Teilweises Entpacken: herausholen, was überlebt hat

Wenn keine saubere Kopie verfügbar ist, ist das teilweise Entpacken das realistische Ziel — und oft ein sehr gutes Ergebnis. Weil jeder Eintrag seinen eigenen lokalen Header und seinen eigenen komprimierten Block trägt, sind die vor dem Schnitt gespeicherten Dateien unabhängig von den danach verlorenen. Ein Reparatur-Tool liest das Archiv sequenziell und stellt jeden Eintrag wieder her, bis es den Punkt erreicht, an dem die Daten abgeschnitten wurden. Das Ergebnis ist kein Alles-oder-Nichts; es ist „42 von 50 Dateien sind zurückgekommen“, wobei die fehlenden acht die sind, die noch unterwegs waren, als die Übertragung stoppte.

Es gibt einen Grenzfall, den man ehrlich benennen sollte. Die Datei, die genau am Schnitt sitzt, ist oft halb vorhanden: Ihr Header und der erste Teil ihrer komprimierten Daten kamen an, der Rest aber nicht. Diese Datei lässt sich vielleicht als abgeschnittene Version ihrer selbst extrahieren oder überhaupt nicht dekomprimieren, je nach Format und wie weit fortgeschritten der Schnitt fiel. Alles davor entpackt sauber. Eine vernünftige Erwartung ist also: vollständige Dateien bis zum Schnitt, eine möglicherweise beschädigte Datei an der Grenze und nichts darüber hinaus. WinRARs Option „beschädigte Dateien behalten“ und entsprechende Einstellungen in anderen Tools existieren genau dafür, diese Grenzdatei herauszuschreiben, für das, was sie noch wert ist.

Wann es wirklich aussichtslos ist

Eine strukturelle Reparatur baut den Index um die überlebenden Daten neu auf. Sie kann keine Daten herstellen, die nicht da sind, und ein paar Situationen liegen außerhalb dessen, was irgendein Tool leisten kann. Darüber ehrlich zu sein, spart dir Zeit:

• Der Schaden liegt mitten im Datenstrom, nicht am Ende.DEFLATE, die Kompression, die ZIP verwendet, hat keine Redundanz: Es ist ein fortlaufender Strom, in dem jeder Teil von dem abhängt, was zuvor kam. Wenn Bytes innerhalb des komprimierten Blocks einer Datei beschädigt sind oder fehlen, statt sauber am Ende abgeschnitten zu sein, verliert die Dekomprimierung an der Schadensstelle die Synchronisation, und alles nach diesem Punkt in der Datei ist unwiederbringlich. Du bekommst vielleicht noch den Anfang dieser Datei, aber nicht die ganze.
• Das Archiv ist verschlüsselt. Ein passwortgeschütztes oder AES-verschlüsseltes Archiv lässt sich strukturell reparieren, sein Verzeichnis neu aufbauen, seine Einträge neu auflisten, aber die komprimierten Daten bleiben verschlüsselt. Ohne das Passwort können die wiederhergestellten Einträge nicht in nutzbare Dateien entschlüsselt werden. Die Reparatur repariert den Container; sie knackt die Verschlüsselung nicht, und kein seriöses Tool behauptet das Gegenteil.
• Ein benötigter Teil eines mehrteiligen Sets fehlt. Ein geteiltes Archiv (.z01, .z02 oder .part1.rar und Konsorten) speichert einen fortlaufenden Strom über mehrere Dateien hinweg. Wenn ein mittlerer Teil nie ankam, hat der Strom eine echte Lücke, und die Volumes nach der Lücke lassen sich nicht mit denen davor verbinden.
• Die Datei ist nahezu leer. Ein Archiv, das als ein paar Kilobyte eines mehrere Megabyte großen Originals zurückkam oder das sich als überwiegend Nullen liest, enthält keine echten Einträge zum Wiederherstellen. Das ist ein Download- oder Wiederherstellungsproblem, kein Reparaturproblem.

Außerhalb dieser Fälle ist ein abgeschnittenes Archiv eines der freundlicheren Korruptionsprobleme, denen man begegnen kann, weil der Aufbau des Formats selbst die überlebenden Dateien eine nach der anderen erreichbar macht.