"Unexpected end of archive"

Le message que vous voyez est un indice solide sur quel outil et quel format vous avez entre les mains — cela vaut la peine de le décoder avant toute chose, car chacun échoue à un point légèrement différent.

• WinRAR — "Unexpected end of archive." Le classique. WinRAR a atteint la fin du fichier alors que l'en-tête d'un bloc ou le marqueur de fin d'archive annonçait encore qu'il devait y avoir davantage. Vaut aussi bien pour les .rar que pour les ZIP que WinRAR ouvre.
• 7-Zip — "Unexpected end of data" (parfois "Unexpected end of archive"). 7-Zip distingue une troncature nette ("end of data") d'une signature incorrecte ("is not archive") et d'un octet altéré ("Data error"). "End of data" signifie précisément que le flux s'est arrêté en cours de route — une troncature, pas un brouillage.
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip cherche à rebours depuis la queue pour trouver PK\x05\x06 et ne le trouve jamais, si bien qu'il ne peut même pas construire sa liste de fichiers. Les données sont peut-être intactes ; c'est l'index qui a disparu.
• Explorateur Windows — "The compressed (zipped) folder is invalid." L'extracteur intégré est le moins précis de tous. C'est en général la même histoire d'EOCD manquant — voyez "Compressed folder is invalid" pour ce message exact.
• Utilitaire d'archive de macOS — "Error 2 – No such file or directory." Fameusement opaque : le "file" qu'il ne trouve pas est l'enregistrement du répertoire central qu'il attendait à la fin. La même troncature, avec un message exceptionnellement inutile.
• Python zipfile — BadZipFile: File is not a zip file, ou une erreur lors du .read(). Si l'EOCD manque, zipfile refuse même d'ouvrir ; si seule une entrée tardive est tronquée, il ouvre sans souci et n'échoue qu'au moment où vous lisez ce membre.
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." Une structure entièrement différente (aucun index central) — traitée plus bas.

Si votre message figure dans cette liste, vous avez presque à coup sûr un fichier court, pas un fichier brouillé — et la récupération est la même quel que soit l'outil qui l'a signalé.

Tout format d'archive conserve une petite structure critique qui dit "l'archive est complète et voici où son contenu est indexé." Cette structure vit dans la queue du fichier, ou tout près — c'est justement la région qu'une troncature détruit en premier. Savoir quel marqueur manque vous indique ce qui est récupérable.

• ZIP — End Of Central Directory (PK\x05\x06). Un ZIP est une suite d'entrées locales (chacune commençant par PK\x03\x04), puis un répertoire central de registres PK\x01\x02, et enfin l'EOCD de 22 octets. L'EOCD est l'index. Les archives volumineuses ou de plus de 4 Go ajoutent un registre EOCD ZIP64 (PK\x06\x06) et un localisateur (PK\x06\x07) juste avant. Perdez la queue et vous perdez l'index — mais pas les entrées locales, qui se décrivent elles-mêmes.
• RAR 4 — bloc de fin d'archive (HEAD_TYPE 0x7B). Après la signature Rar!\x1A\x07\x00, RAR4 stocke des blocs décodables indépendamment et se termine par un bloc de clôture. Les fichiers antérieurs à la coupure se décodent encore ; un RAR créé avec un enregistrement de récupération peut reconstruire d'un coup les blocs manquants.
• RAR 5 — en-tête de fin d'archive (type d'en-tête 5). Signature Rar!\x1A\x07\x01\x00, un format d'en-tête repensé, la même idée : un en-tête de fin dédié qu'une troncature supprime.
• 7z — la Start Header pointe vers une End Header en queue. Après la signature 37 7A BC AF 27 1C et deux octets de version se trouve une Start Header de 20 octets contenant NextHeaderOffset, NextHeaderSize et un CRC — un pointeur vers la base de données d'en-têtes tout à la fin du fichier. Tronquez le fichier et ce pointeur vise au-delà du dernier octet. Pire, .7z utilise par défaut la compression solide, enchaînant les fichiers en un seul flux, si bien qu'une queue perdue peut casser tous les fichiers postérieurs au dernier bloc complet.

Le schéma est universel : les métadonnées dont l'extracteur a besoin en premier sont stockées en dernier, donc ce sont les métadonnées qu'une troncature tue en premier. C'est pourquoi "unexpected end" est si fréquent et pourquoi les données elles-mêmes restent en général récupérables.

Tar est l'exception, et mérite sa propre note car le diagnostic diffère. Un .tar n'a aucun index central : c'est une séquence plate de registres de 512 octets — un bloc d'en-tête par fichier (l'en-tête ustar avec le nom, la taille et une somme de contrôle), puis les données du fichier complétées jusqu'à la limite de 512 octets suivante. L'archive est déclarée terminée par deux blocs consécutifs de 512 octets entièrement à zéro. Si ces blocs de zéros finaux ne sont jamais arrivés, tar affiche "Unexpected EOF in archive" même si chaque fichier écrit en entier reste parfaitement extractible — tar parcourt simplement les registres du début à la fin, il récupère donc tout jusqu'à l'octet où il s'est retrouvé à court.

Un .tar.gz (ou .tgz) enveloppe ce flux tar dans du gzip. Un membre gzip est un en-tête de 10 octets (1F 8B 08 …), le flux deflate et une remorque de 8 octets contenant un CRC-32 des données non compressées et l'ISIZE (la taille d'origine modulo 2³²). Tronquez-le et gzip signale "unexpected end of file" — il décompresse correctement jusqu'à la coupure, puis n'a plus de remorque contre laquelle vérifier. Le sauvetage suit le même principe qu'en ZIP : décoder vers l'avant tout ce que les octets intacts permettent.

"Unexpected end" est le symptôme. La cause décide de votre meilleur coup, et il y en a trois :

• Un téléchargement de navigateur qui a calé ou a été annulé. Si l'archive venait d'un lien et que le transfert ne s'est jamais terminé (un .crdownload/.part resté en plan, un "Failed – Network error"), la mécanique de savoir quels octets exacts survivent est particulière — voyez un téléchargement de ZIP interrompu.
• Un fichier du cloud qui semble complet mais ne l'est pas. Drive, Dropbox et OneDrive peuvent vous remettre une page d'erreur HTML renommée .zip, ou une synchronisation partielle — une troncature qui se fait passer pour de la corruption. Pour distinguer un fichier court d'une vraie dégradation de bits, voyez comment diagnostiquer une archive du cloud endommagée.
• La source elle-même est courte. Si l'original manque vraiment de sa queue, aucun outil ne peut inventer les octets absents — mais IntactFile extrait tout de même tout ce qui a été écrit avant la coupure. Déposez-le ci-dessus pour récupérer les entrées intactes.

Dans tous les cas, le sauvetage lui-même est identique et s'exécute entièrement dans votre onglet : IntactFile ignore le marqueur de fin absent, scanne vers l'avant depuis le début du fichier en attrapant chaque entrée intacte et décompresse ce que les octets survivants permettent — du TypeScript pur, sans aucun utilitaire d'archives installé, et vous pouvez regarder l'onglet Réseau confirmer que pas un seul octet d'une archive privée ne quitte jamais votre machine.