Réparer maintenant
- Déposez le fichier
- La réparation s'exécute en local
- Téléchargez le résultat
L'option « Télécharger le dossier » de Google Drive et « Télécharger au format .zip » de Dropbox échouent de la même façon quand la connexion tombe : il vous reste un ZIP qu'aucun outil n'ouvre. La raison est presque toujours des plus banales — le fichier est tronqué, il lui manque l'index de la fin — et non que son contenu soit brouillé. Déposez le fichier ci-dessus et l'outil lit sa véritable structure dans votre navigateur, repère les entrées qui ont été écrites intégralement avant l'arrêt du transfert et extrait celles-là, au lieu de rejeter tout le fichier. Rien n'est téléversé.
Troncature contre bit-rot : deux pannes différentes, une seule étiquette
Deux problèmes complètement différents reçoivent le même nom d'« archive endommagée », et la solution dépend de celui que vous avez. La troncature signifie que le fichier est trop court : le téléchargement s'est arrêté avant l'arrivée du dernier octet, si bien qu'il manque la fin au fichier. Le bit-rot — ici, une erreur d'octets introduite pendant le transit — signifie que le fichier a la bonne longueur mais que certains octets sont faux : un bloc inversé ou mis à zéro quelque part au milieu. Les distinguer prend dix secondes et détermine tout ce que vous pouvez récupérer.
Vérifiez d'abord la taille. Google Drive comme Dropbox affichent le nombre réel d'octets dans le volet de détails du fichier ; comparez-le à la copie sur votre disque. Si la vôtre est plus petite, elle est tronquée — un point c'est tout. Un ZIP tronqué a perdu son enregistrement End Of Central Directory — la signature PK\x05\x06 qui réside dans les 22 derniers octets (au minimum) du fichier —, si bien qu'un extracteur qui se positionne à la fin pour lire l'index n'y trouve que du n'importe quoi, ou rien. C'est pour cela qu'unzip annonce End-of-central-directory signature not found ou cannot find zipfile directory, que 7-Zip et WinRAR affichent « Unexpected end of archive » (« fin d'archive inattendue »), et que l'extracteur intégré de Windows affiche « The Compressed (zipped) Folder is invalid. » (« le dossier compressé est non valide »).
Si la taille correspond mais que l'extraction échoue quand même, vous avez du bit-rot. L'index est présent, donc l'outil entre dans l'archive et échoue fichier par fichier : 7-Zip signale « Data error » (« erreur de données ») ou « CRC failed » (« échec du CRC »), et unzip -t imprime bad CRC en regard des entrées précises. Chaque entrée ZIP conserve un CRC-32 de ses données non compressées à la fois dans son en-tête local et dans le répertoire central ; quand les octets décompressés ne donnent pas cette valeur, l'outil sait que ce fichier-là est endommagé — mais les autres, en général, ne le sont pas.
Pourquoi un téléchargement cloud endommage une archive, pour commencer
Les transferts interrompus tronquent les archives plus que toute autre cause, et le stockage cloud y ajoute ses propres subtilités. Quand vous utilisez « Télécharger le dossier » de Drive ou « Télécharger au format .zip » de Dropbox, le serveur construit le ZIP à la volée et vous l'envoie en streaming. Comme il compresse tout en envoyant, il ne connaît d'avance ni la taille ni le CRC de chaque fichier ; il active donc le bit 3 d'usage général (general-purpose bit 3) dans chaque entrée et écrit le CRC et les tailles après les données compressées, dans un descripteur de données (PK\x07\x08). Si la connexion tombe au milieu du flux, il vous reste un préfixe propre d'un ZIP valide mais sans aucun répertoire central — la troncature dans les règles de l'art.
Les gros dossiers aggravent les choses parce qu'ils franchissent le seuil de ZIP64 : plus de 65 535 fichiers ou 4 GiB de données. Une archive ZIP64 conserve un enregistrement EOCD ZIP64 PK\x06\x06 et un localisateur PK\x06\x07 tout à la fin — encore davantage de métadonnées de fin à perdre quand le transfert s'arrête trop tôt.
Deux pièges propres au cloud se font passer pour de la corruption. Premièrement : Google Drive refuse d'analyser les gros fichiers à la recherche de virus et sert une page HTML intermédiaire à la place des octets ; si vous avez récupéré le lien avec wget, curl ou un script, votre « .zip » peut en réalité commencer par <!DOCTYPE html> au lieu de PK\x03\x04 — c'est une page web, pas une archive compressée. Deuxièmement : les gestionnaires de téléchargement par segments qui récupèrent un fichier par plages d'octets en parallèle peuvent laisser un trou ou un bloc dupliqué quand une plage échoue en silence, produisant un fichier de longueur complète avec le milieu endommagé : du bit-rot, pas de la troncature. Ouvrir le fichier dans un visualiseur hexadécimal et vérifier si les quatre premiers octets sont 50 4B 03 04 (PK\x03\x04) vous dit immédiatement si vous avez ne serait-ce qu'un ZIP.
Ce que la récupération extrait réellement
Déposez le fichier ci-dessus et l'outil ignore l'index manquant ou illisible et parcourt le fichier vers l'avant depuis le début, capturant chaque en-tête de fichier local PK\x03\x04 et décompressant le flux deflate qui le suit tant que les octets tiennent. Dans une archive tronquée, chaque entrée écrite intégralement avant la coupure revient intacte ; seul l'unique fichier resté à cheval sur le point de troncature revient partiel, ou est perdu. Dans le cas du bit-rot, les entrées dont le CRC-32 concorde toujours s'extraient normalement, et l'outil signale l'entrée précise dont le hachage échoue au lieu de condamner tout le fichier. C'est du TypeScript pur qui s'exécute dans votre onglet — pas de binaire unzip, rien de transmis.
RAR et 7z suivent le même principe sur des structures différentes. Un RAR (signature Rar!\x1a\x07\x00 en v4, Rar!\x1a\x07\x01\x00 en v5) stocke les fichiers dans des blocs indépendants, si bien que ceux qui précèdent le dommage se décodent encore, et un RAR créé avec un enregistrement de récupération (recovery record) se répare bien mieux parce que cet enregistrement existe précisément pour reconstruire les blocs manquants. Un .7z (signature 7z\xBC\xAF\x27\x1C) est le cas fragile : il conserve sa base de données d'en-têtes à la fin et utilise en général une compression solide qui enchaîne de nombreux fichiers en un seul flux, de sorte qu'une fin perdue ou une erreur d'octets au milieu du flux peut casser la décompression de tout ce qui vient après le dernier bloc intact. L'outil récupère ce que permettent les blocs survivants et le dit clairement lorsqu'un flux solide ne peut pas être poursuivi.
La limite honnête : les octets manquants restent manquants
Rien ne peut récupérer des octets qui ne sont jamais arrivés sur votre disque. Si le téléchargement s'est arrêté à 70 %, les 30 % finaux des données compressées n'existent tout simplement pas en local, et aucun outil — ni celui-ci, ni la fonction Repair propre à WinRAR, ni une suite de récupération payante — ne peut les inventer. La vraie solution pour la troncature, c'est de retélécharger depuis Drive ou Dropbox, en évitant si possible un dossier compressé côté serveur : récupérez le fichier original directement, ou le dossier par lots plus petits, pour que le transfert ait plus de chances d'aboutir.
Le bit-rot à l'intérieur d'un flux compressé est tout aussi impitoyable au niveau de l'unique fichier endommagé. Deflate est un flux à état — un seul bit inversé fait dérailler le décodage Huffman/LZ77 à partir de ce point —, si bien que l'entrée touchée revient généralement tronquée à l'erreur, même si son CRC-32 vous a indiqué exactement quel fichier a pris le coup. Les archives chiffrées (ZIP AES-256, protection par mot de passe de RAR ou 7z) ne peuvent pas être analysées sans le mot de passe, parce que les entrées sont du texte chiffré. Ce que la récupération évite de façon fiable, c'est qu'une archive arrivée à moitié devienne une perte totale : si neuf fichiers sur dix sont arrivés, il n'y a aucune raison de perdre les neuf en courant après le dixième. Et comme tout s'exécute en local, une archive contenant des relevés financiers, du code source ou des documents personnels n'est jamais copiée sur un serveur inconnu juste pour regarder à l'intérieur — ouvrez l'onglet Réseau et confirmez qu'il n'en sort pas un octet.
Ce que cela peut et ne peut pas réparer
Peut réparer
- Un ZIP tronqué par un téléchargement Drive/Dropbox interrompu — les entrées écrites avant la coupure sont récupérées en parcourant les en-têtes locaux PK\x03\x04
- Du bit-rot dans une entrée : les fichiers dont le CRC-32 se vérifie encore s'extraient normalement, et l'entrée endommagée est signalée au lieu de faire tomber toute l'archive
- Les dossiers compressés côté serveur qui envoient des descripteurs de données en streaming (PK\x07\x08) et ont perdu leur répertoire central à cause d'une connexion tombée
- Les téléchargements de dossier ZIP64 (plus de 65 535 fichiers ou 4 GiB) auxquels il manque l'enregistrement PK\x06\x06 et le localisateur PK\x06\x07 de la fin
- Les archives RAR dont les blocs antérieurs au dommage se décodent encore — bien mieux avec un enregistrement de récupération
- Les archives 7z jusqu'au dernier bloc de compression (solide) complet qui a survécu
Ne peut pas réparer
- Tout fichier dont les données compressées se trouvaient après le point de troncature — ces octets ne sont jamais arrivés sur votre disque (mieux vaut retélécharger)
- Un « .zip » qui est en réalité la page HTML d'analyse antivirus de Google Drive — c'est une page web, pas une archive compressée
- L'unique entrée frappée par une erreur d'octets au milieu du flux, au-delà du point où son flux deflate s'est rompu
- Un flux solide 7z au-delà de son dernier bloc intact (les fichiers suivants de la chaîne ne peuvent pas être décompressés)
- Les archives chiffrées / protégées par mot de passe sans le mot de passe (les entrées sont du texte chiffré)
Si une réparation échoue, nous vous expliquons pourquoi (données manquantes ou structure endommagée), et vous n'êtes jamais facturé pour une réparation échouée.