« Unexpected end of archive » — ce que ça veut dire et ce qui ressort quand même

L'erreur exacte, et ce qu'elle vous dit

Selon l'outil qui ouvre le fichier, la formulation change mais pas le sens. WinRAR affiche :

Unexpected end of archive, et souvent à côté The archive is either in unknown format or damaged.

7-Zip formule le même échec par Unexpected end of data ou, quand le dommage atteint le début du fichier, Cannot open the file as archive. Sous Linux ou macOS, la commande unzip signale unexpected end of file ou le plus précis End-of-central-directory signature not found.

Chacune de ces chaînes décrit une seule et même situation : l'outil s'est retrouvé à court de fichier avant ce que le format prévoyait. Un ZIP ou un RAR a une forme définie, avec des structures précises censées se trouver à des emplacements connus. Quand le fichier est plus court que cette forme ne l'exige, l'outil atteint la fin de façon inattendue et s'arrête. C'est ce que veut dire « unexpected » ici. Ce n'est pas un pépin aléatoire, et ce ne sont généralement pas des données brouillées. C'est un fichier auquel il manque la fin.

Un ZIP garde son index tout à la fin

Pour comprendre pourquoi une fin manquante est si perturbante, il aide de savoir comment un ZIP est agencé. Une archive, ce sont deux choses cousues ensemble. D'abord viennent les entrées : chaque fichier que vous avez ajouté, compressé et écrit les uns à la suite des autres, chacun précédé d'un petit en-tête local qui donne son nom et sa taille. Ensuite, après toutes les entrées, vient le répertoire central : une table qui liste chaque fichier de l'archive et le décalage exact en octets où chacun commence.

Un ZIP stocke d'abord les fichiers et, en dernier, le répertoire qui les liste. Un téléchargement tronqué perd le répertoire, pas les fichiers qui le précèdent.

Le répertoire central est l'index de l'archive. Quand vous double-cliquez sur un ZIP, l'outil saute à la fin, lit ce répertoire et s'en sert pour vous montrer la liste des fichiers. Placer l'index en dernier est délibéré : cela permettait au format ZIP d'origine d'ajouter des fichiers à une archive sans la réécrire en entier. Le hic, c'est que la seule structure dont un outil a besoin en premier est justement celle qui est stockée en dernier, si bien que tout dommage qui commence à la fin du fichier tombe en plein sur l'index. C'est le même schéma qui rend une feuille de calcul fragile, car un fichier .xlsx est en réalité un ZIP avec son propre répertoire à la fin.

Pourquoi un téléchargement coupé perd l'index, pas les fichiers

Un ZIP s'écrit et se transfère du début à la fin. Quand un téléchargement s'enlise, qu'une synchronisation dans le cloud abandonne ou qu'on retire une clé USB en pleine copie, le fichier qui atterrit sur votre disque est ce qui est arrivé avant l'interruption : le début est intact, et la fin est tout simplement absente. Comme le répertoire vit à la fin, il est la première victime de toute troncature. Les entrées du début, les vrais fichiers compressés, sont là, intactes.

C'est toute la raison pour laquelle l'erreur est si récupérable. L'outil ne trouve pas le répertoire, alors il refuse d'ouvrir l'archive de la manière normale et signale une fin inattendue. Mais les fichiers eux-mêmes n'ont jamais été le problème. Une passe de réparation ignore le répertoire absent et parcourt plutôt l'archive depuis le début, lisant chaque en-tête local, prenant les données compressées qui le suivent, et reconstruisant un répertoire neuf à partir de ce qu'elle trouve. L'archive s'ouvre de nouveau, listant chaque entrée qui a physiquement survécu.

Une vérification rapide distingue la troncature de quelque chose de pire : comparez la taille du fichier à celle de l'original si vous la connaissez. Une archive de 240 Mo arrivée à 180 Mo est un cas d'école de troncature, et les 60 Mo manquants ne sont pas endommagés, ils sont ailleurs. C'est aussi pourquoi retélécharger est le premier geste. Les octets manquants existent toujours à la source, et une copie propre bat tout sauvetage d'une copie partielle. Si l'archive venait d'un téléchargement web ou d'une pièce jointe d'e-mail, essayez cette voie avant de réparer. La version propre à Windows de cette même histoire, où l'extracteur intégré de l'Explorateur est plus strict que les outils ci-dessus, est traitée dans « The Compressed (zipped) Folder is invalid ».

Extraction partielle : sortir ce qui a survécu

Quand aucune copie propre n'est disponible, l'extraction partielle est l'objectif réaliste, et c'est souvent un très bon résultat. Comme chaque entrée porte son propre en-tête local et son propre bloc compressé, les fichiers stockés avant la coupure sont indépendants de ceux perdus après elle. Un outil de réparation lit l'archive de façon séquentielle et récupère chaque entrée jusqu'à atteindre le point où les données ont été tronquées. Le résultat n'est pas du tout ou rien ; c'est « 42 fichiers sur 50 sont revenus », les huit manquants étant ceux qui étaient encore en transit quand le transfert s'est arrêté.

Il y a un cas limite qui mérite d'être nommé honnêtement. Le fichier qui se trouve juste à la coupure est souvent à moitié présent : son en-tête et la première partie de ses données compressées sont arrivés, mais pas le reste. Ce fichier peut s'extraire comme une version tronquée de lui-même, ou ne pas se décompresser du tout, selon le format et le stade où la coupure est tombée. Tout ce qui le précède s'extrait proprement. Une attente raisonnable est donc : des fichiers complets jusqu'à la coupure, un fichier peut-être endommagé à la frontière, et rien au-delà. L'option « keep broken files » de WinRAR et les réglages équivalents des autres outils existent précisément pour écrire ce fichier de frontière, pour ce qu'il vaut.

Quand c'est vraiment sans espoir

La réparation structurelle reconstruit l'index autour des données survivantes. Elle ne peut pas fabriquer des données qui ne sont pas là, et quelques situations dépassent ce que n'importe quel outil peut faire. Être direct à leur sujet vous fait gagner du temps :

• Le dommage est en plein flux, pas à la fin. DEFLATE, la compression qu'utilise le ZIP, n'a aucune redondance : c'est un flux continu où chaque partie dépend de ce qui a précédé. Si des octets sont corrompus ou manquants à l'intérieur du bloc compressé d'un fichier plutôt que nettement coupés à la fin, la décompression perd la synchronisation au niveau du dommage et tout ce qui suit ce point dans le fichier est irrécupérable. Vous pourrez peut-être obtenir le début de ce fichier, mais pas son intégralité.
• L'archive est chiffrée. Une archive protégée par mot de passe ou chiffrée en AES peut être réparée structurellement, son répertoire reconstruit, ses entrées de nouveau listées, mais les données compressées restent chiffrées. Sans le mot de passe, les entrées récupérées ne peuvent pas être déchiffrées en fichiers utilisables. La réparation répare le conteneur ; elle ne casse pas le chiffrement, et aucun outil légitime ne prétend le contraire.
• Une partie nécessaire d'un ensemble multivolume est manquante. Une archive scindée (.z01, .z02, ou .part1.rar et compagnie) stocke un unique flux continu réparti sur plusieurs fichiers. Si une partie intermédiaire n'est jamais arrivée, le flux a un vrai trou, et les volumes situés après le trou ne peuvent pas être joints à ceux d'avant.
• Le fichier est presque vide. Une archive revenue sous la forme de quelques kilo-octets d'un original de plusieurs mégaoctets, ou qui se lit comme essentiellement des zéros, ne contient aucune entrée réelle à récupérer. C'est un problème de téléchargement ou de récupération, pas un problème de réparation.

En dehors de ces cas, une archive tronquée est l'un des problèmes de corruption les plus faciles à affronter, parce que l'agencement même du format rend les fichiers survivants atteignables un par un.