"Unexpected end of archive"

Un fichier ZIP n'est pas un unique bloc continu — c'est une série d'entrées de fichier locales suivies d'un répertoire central tout à la fin. Chaque entrée commence par la signature PK\x03\x04, porte son propre nom, sa méthode de compression et sa taille, puis les données compressées (deflate). Après la dernière entrée vient le répertoire central (enregistrements PK\x01\x02), et le fichier se termine par l'enregistrement End Of Central Directory, PK\x05\x06. Cet EOCD est l'index : il indique à l'extracteur combien de fichiers existent et où commence chacun d'eux.

Voici le piège. L'index se trouve tout à la fin du fichier. Quand un téléchargement ou une copie est interrompu, la fin est justement ce qui manque — alors l'extracteur se positionne là où l'EOCD devrait se trouver, y rencontre des données (ou rien) au lieu de la signature PK\x05\x06, et signale "Unexpected end of archive." L'archive n'est pas brouillée ; il lui manque simplement sa table des matières, et peut-être le dernier fichier ou deux.

RAR et 7z échouent de la même façon pour la même raison. Un RAR conserve des en-têtes de bloc et, à la fin, un marqueur de fin d'archive ; un .7z conserve sa base de données d'en-têtes à la fin du fichier et compresse généralement de nombreux fichiers ensemble dans un unique flux solide. Dans tous les cas, les métadonnées dont l'outil a besoin en premier sont les métadonnées qu'une troncature détruit en premier.

Comme chaque entrée ZIP se décrit elle-même, tout le répertoire central est redondant pour l'extraction — c'est un index, pas les données. L'outil ignore l'EOCD manquant et parcourt plutôt le fichier vers l'avant depuis le début, capturant chaque en-tête local PK\x03\x04 qu'il rencontre et décompressant le flux deflate qui le suit tant que les octets tiennent. Tout fichier qui a été entièrement écrit avant la coupure revient intact ; le seul fichier qui chevauchait le point de troncature peut revenir partiel ou ne pas revenir du tout. Cela s'exécute en TypeScript pur dans votre onglet — sans installer le moindre utilitaire d'archivage, sans rien envoyer où que ce soit.

RAR et 7z sont plus contraints mais pas désespérés. Dans un RAR, les fichiers stockés avant la troncature se décodent toujours, et un RAR créé avec un enregistrement de récupération se répare bien mieux car cet enregistrement est conçu pour reconstruire les blocs manquants. Un .7z est le cas fragile : sans enregistrement de récupération et avec une compression solide qui enchaîne les fichiers entre eux, perdre la fin peut casser la décompression de tout ce qui vient après le dernier bloc complet. L'outil récupère ce que les blocs survivants permettent et reste honnête quand un flux solide ne peut pas être poursuivi.

Aucun logiciel ne peut récupérer des données qui n'ont jamais été dans le fichier. Si le téléchargement s'est arrêté à 60 %, les derniers 40 % des données compressées n'existent pas sur votre disque, et rien — ni cet outil, ni la réparation intégrée de WinRAR, ni une suite de récupération payante — ne peut les réinventer. La solution consiste à retélécharger ou recopier l'archive depuis la source afin de disposer des octets complets.

Ce que nous pouvons faire de manière fiable, c'est empêcher qu'une archive arrivée à moitié soit une perte totale. Si neuf fichiers sur dix sont arrivés avant que la connexion ne tombe, il n'y a aucune raison de perdre les neuf en poursuivant le dixième. Et comme toute l'opération se déroule dans votre navigateur, une archive qui pourrait contenir des relevés financiers, du code source ou des documents personnels n'est jamais copiée sur un serveur inconnu juste pour y jeter un œil — vous pouvez surveiller l'onglet Réseau et confirmer que pas un octet ne sort.