Jetzt reparieren
- Datei ablegen
- Reparatur läuft lokal
- Ergebnis herunterladen
Die Funktion „Ordner herunterladen“ von Google Drive und „Als .zip herunterladen“ von Dropbox scheitern auf dieselbe Weise, wenn die Verbindung abbricht: Du bleibst mit einem ZIP zurück, das kein Werkzeug öffnet. Der Grund ist fast immer völlig banal — die Datei ist abgeschnitten, ihr fehlt das Verzeichnis am Ende — und nicht etwa, dass ihr Inhalt durcheinander wäre. Lege das Archiv oben ab, und das Werkzeug liest seine tatsächliche Struktur in deinem Browser, findet die Einträge, die vor dem Abbruch der Übertragung vollständig geschrieben wurden, und extrahiert diese, statt die ganze Datei abzulehnen. Es wird nichts hochgeladen.
Abschneiden vs. Bit-Rot: zwei verschiedene Fehler, ein Etikett
Zwei völlig verschiedene Probleme werden beide „beschädigtes Archiv“ genannt, und die Lösung hängt davon ab, welches du hast. Abschneiden bedeutet, dass die Datei zu kurz ist: Der Download stoppte, bevor das letzte Byte ankam, dem Archiv fehlt also das Ende. Bit-Rot — hier ein während der Übertragung eingeschleppter Byte-Fehler — bedeutet, dass die Datei die richtige Länge hat, aber einige Bytes falsch sind: ein gekippter oder auf null gesetzter Block irgendwo in der Mitte. Sie auseinanderzuhalten dauert zehn Sekunden und entscheidet alles darüber, was du zurückbekommen kannst.
Prüfe zuerst die Größe. Google Drive und Dropbox zeigen beide die tatsächliche Byte-Anzahl im Detailbereich der Datei; vergleiche sie mit der Kopie auf deiner Festplatte. Ist deine kleiner, ist sie abgeschnitten — Punkt. Einem abgeschnittenen ZIP fehlt sein End Of Central Directory-Datensatz — die Signatur PK\x05\x06, die in den letzten gut 22 Bytes der Datei liegt —, sodass ein Entpacker, der ans Ende springt, um das Verzeichnis zu lesen, Müll oder nichts findet. Deshalb sagt unzip End-of-central-directory signature not found oder cannot find zipfile directory, 7-Zip und WinRAR sagen „Unexpected end of archive“ und der in Windows integrierte Entpacker sagt „The Compressed (zipped) Folder is invalid.“
Stimmt die Größe überein, schlägt das Entpacken aber trotzdem fehl, hast du Bit-Rot. Das Verzeichnis ist vorhanden, das Werkzeug gelangt also in das Archiv und scheitert stattdessen dateiweise: 7-Zip meldet „Data error“ oder „CRC failed“, und unzip -t gibt bad CRC gegen die betreffenden Einträge aus. Jeder ZIP-Eintrag speichert eine CRC-32-Prüfsumme seiner unkomprimierten Daten sowohl in seinem lokalen Header als auch im zentralen Verzeichnis; wenn die dekomprimierten Bytes nicht diesen Wert ergeben, weiß das Werkzeug, dass diese eine Datei beschädigt ist — die anderen aber meist nicht.
Warum ein Cloud-Download überhaupt ein Archiv beschädigt
Abgebrochene Übertragungen schneiden Archive häufiger ab als alles andere, und Cloud-Speicher fügt seine eigenen Besonderheiten hinzu. Wenn du „Ordner herunterladen“ von Drive oder „Als .zip herunterladen“ von Dropbox verwendest, baut der Server das ZIP zur Laufzeit und streamt es zu dir. Weil er komprimiert, während er sendet, kennt er Größe und CRC jeder Datei nicht im Voraus, also setzt er General-Purpose-Bit 3 in jedem Eintrag und schreibt CRC und Größen nach den komprimierten Daten, in einen Data Descriptor (PK\x07\x08). Bricht die Verbindung mitten im Stream ab, bekommst du einen sauberen Anfang eines gültigen ZIP ganz ohne zentrales Verzeichnis — Abschneiden wie aus dem Lehrbuch.
Große Ordner verschlimmern das, weil sie die ZIP64-Schwelle überschreiten: mehr als 65.535 Dateien oder 4 GiB Daten. Ein ZIP64-Archiv führt am ganz Ende einen ZIP64-EOCD-Datensatz PK\x06\x06 und einen Locator PK\x06\x07 — noch mehr Metadaten am Ende, die verloren gehen, wenn die Übertragung zu früh stoppt.
Zwei cloud-spezifische Fallen geben sich als Beschädigung aus. Erstens: Google Drive weigert sich, große Dateien auf Viren zu prüfen, und liefert eine HTML-Zwischenseite statt der Bytes; hast du den Link mit wget, curl oder einem Skript geholt, beginnt deine „.zip“ womöglich tatsächlich mit <!DOCTYPE html> statt mit PK\x03\x04 — es ist eine Webseite, kein Archiv. Zweitens: segmentierte Download-Manager, die eine Datei in parallelen Byte-Bereichen holen, können eine Lücke oder einen doppelten Block hinterlassen, wenn ein Bereich stillschweigend fehlschlägt, und erzeugen so eine Datei voller Länge mit beschädigter Mitte: Bit-Rot, kein Abschneiden. Öffnest du die Datei in einem Hex-Viewer und prüfst, ob die ersten vier Bytes 50 4B 03 04 (PK\x03\x04) lauten, weißt du sofort, ob du überhaupt ein ZIP hast.
Was die Rettung tatsächlich extrahiert
Lege die Datei oben ab, und das Werkzeug ignoriert das fehlende oder unlesbare Verzeichnis und durchsucht das Archiv von oben nach vorne, fängt jeden lokalen Datei-Header PK\x03\x04 ab und dekomprimiert den darauf folgenden Deflate-Stream, solange die Bytes reichen. Bei einem abgeschnittenen Archiv kommt jeder Eintrag, der vor dem Abbruch vollständig geschrieben wurde, unversehrt zurück; nur die eine Datei, die genau auf dem Abschneidepunkt liegt, ist unvollständig oder verloren. Bei Bit-Rot werden die Einträge, deren CRC-32 noch stimmt, normal extrahiert, und das Werkzeug markiert den konkreten Eintrag, dessen Prüfsumme fehlschlägt, statt das ganze Archiv zu verurteilen. Das ist reines TypeScript, das in deinem Tab läuft — keine unzip-Binärdatei, nichts wird übertragen.
RAR und 7z folgen demselben Prinzip über andere Strukturen. Ein RAR (Signatur Rar!\x1a\x07\x00 bei v4, Rar!\x1a\x07\x01\x00 bei v5) speichert Dateien in unabhängigen Blöcken, sodass die vor dem Schaden noch dekodiert werden, und ein RAR, das mit einem Recovery-Record erstellt wurde, lässt sich weit besser reparieren, weil dieser Datensatz genau dafür da ist, fehlende Blöcke wiederherzustellen. Eine .7z (Signatur 7z\xBC\xAF\x27\x1C) ist der heikle Fall: Sie hält ihre Header-Datenbank am Ende und nutzt meist solide Kompression, die viele Dateien zu einem einzigen Stream verkettet, sodass ein verlorenes Ende oder ein Byte-Fehler mitten im Stream die Dekompression von allem nach dem letzten intakten Block zerstören kann. Das Werkzeug rettet, was die überlebenden Blöcke zulassen, und sagt es klar, wenn ein solider Stream nicht fortgesetzt werden kann.
Die ehrliche Grenze: Fehlende Bytes bleiben fehlend
Nichts kann Bytes wiederherstellen, die nie auf deiner Festplatte ankamen. Stoppte der Download bei 70 %, existieren die letzten 30 % der komprimierten Daten schlicht nicht lokal, und kein Werkzeug — weder dieses, noch WinRARs eigene Funktion Repair, noch eine kostenpflichtige Recovery-Suite — kann sie erfinden. Die echte Lösung für Abschneiden ist, erneut von Drive oder Dropbox herunterzuladen und dabei möglichst einen serverseitig gepackten Ordner zu vermeiden: Hol die Originaldatei direkt oder den Ordner in kleineren Paketen, damit die Übertragung eher zu Ende kommt.
Bit-Rot in einem komprimierten Stream ist auf der Ebene der einen beschädigten Datei genauso unerbittlich. Deflate ist ein zustandsbehafteter Stream — ein einziges gekipptes Bit bringt die Huffman-/LZ77-Dekodierung ab diesem Punkt aus der Spur —, sodass der betroffene Eintrag meist am Fehler abgeschnitten zurückkommt, obwohl seine CRC-32 dir genau sagte, welche Datei es getroffen hat. Verschlüsselte Archive (AES-256-ZIP, Passwortschutz bei RAR oder 7z) lassen sich ohne das Passwort nicht durchsuchen, weil die Einträge Chiffretext sind. Was die Rettung zuverlässig verhindert, ist, dass ein nur teilweise angekommenes Archiv zum Totalverlust wird: Wenn neun von zehn Dateien angekommen sind, gibt es keinen Grund, die neun zu verlieren, während man der zehnten hinterherjagt. Und weil alles lokal läuft, wird ein Archiv mit Finanzunterlagen, Quellcode oder persönlichen Dokumenten nie auf einen unbekannten Server kopiert, nur um hineinzuschauen — öffne den Tab „Netzwerk“ und bestätige, dass kein einziges Byte hinausgeht.
Was sich reparieren lässt und was nicht
Kann repariert werden
- Ein ZIP, das durch einen abgebrochenen Drive-/Dropbox-Download abgeschnitten wurde — Einträge, die vor dem Abbruch geschrieben wurden, werden durch das Durchsuchen der lokalen Header PK\x03\x04 wiederhergestellt
- Bit-Rot in einem Eintrag: Dateien, deren CRC-32 noch stimmt, werden normal extrahiert, und der beschädigte Eintrag wird markiert, statt das ganze Archiv scheitern zu lassen
- Serverseitig gepackte Ordner, die Data Descriptors (PK\x07\x08) streamen und ihr zentrales Verzeichnis durch eine abgebrochene Verbindung verloren haben
- ZIP64-Ordner-Downloads (über 65.535 Dateien oder 4 GiB), denen der Datensatz PK\x06\x06 und der Locator PK\x06\x07 am Ende fehlen
- RAR-Archive, bei denen die Blöcke vor dem Schaden noch dekodiert werden — dramatisch besser mit einem Recovery-Record
- 7z-Archive bis zum letzten vollständigen (soliden) Kompressionsblock, der überlebt hat
Kann nicht repariert werden
- Jede Datei, deren komprimierte Daten hinter dem Abschneidepunkt lagen — diese Bytes kamen nie auf deiner Festplatte an (stattdessen erneut herunterladen)
- Eine „.zip“, die in Wirklichkeit die HTML-Virenscan-Seite von Google Drive ist — es ist eine Webseite, kein Archiv
- Der einzelne Eintrag, den ein Byte-Fehler mitten im Stream getroffen hat, jenseits der Stelle, an der sein Deflate-Stream brach
- Ein solider 7z-Stream jenseits seines letzten intakten Blocks (spätere Dateien in der Kette lassen sich nicht dekomprimieren)
- Verschlüsselte / passwortgeschützte Archive ohne das Passwort (die Einträge sind Chiffretext)
Wenn eine Reparatur fehlschlägt, sagen wir dir warum (fehlende Daten gegenüber beschädigter Struktur), und für eine fehlgeschlagene Reparatur wird dir nie etwas berechnet.