« The file is damaged and could not be repaired » — réparer un PDF cassé

Les erreurs exactes, et l'ironie de la formulation d'Adobe

Adobe Acrobat et Reader affichent ceci, mot pour mot, quand un PDF ne s'ouvre pas :

There was an error opening this document. The file is damaged and could not be repaired.

Le visionneur intégré de Chrome exprime le même échec de façon plus laconique :

Failed to load PDF document.

Lisez attentivement la phrase d'Adobe, car sa formulation pousse beaucoup de gens à abandonner. Elle ne dit pas que le fichier ne peut pas être réparé. Elle dit qu'Acrobat n'a pas pu le réparer. Acrobat exécute une passe de réparation intégrée qui se déclenche automatiquement lorsqu'il rencontre un PDF cassé, et cette passe est prudente : elle gère les problèmes simples et renonce dès que c'est plus difficile. Quand elle renonce, elle signale le fichier comme endommagé et hors de portée de sa propre réparation, ce qui est une affirmation sur l'effort d'Acrobat, pas sur la récupérabilité réelle du fichier. Bien des PDF qui déclenchent ce message s'ouvrent parfaitement après une reconstruction structurelle plus approfondie.

La table xref est l'index du PDF

Un PDF est construit à partir d'objets numérotés : chaque page, police, image et bloc de texte est un objet stocké quelque part dans le fichier. Pour les retrouver rapidement, un PDF conserve une table de références croisées, la xref, près de la fin du fichier. La xref est une liste de correspondance qui enregistre le décalage exact en octets de chaque objet, et juste après elle se trouve un petit trailer qui oriente le lecteur vers la xref et vers la racine du document. Quand vous ouvrez un PDF, le lecteur saute à la fin, lit le trailer, lit la xref, et utilise ces décalages pour localiser tout le reste.

Un PDF stocke d'abord ses objets de page, puis l'index xref qui les localise près de la fin. Endommagez la xref et le lecteur ne trouve plus les pages, alors qu'elles sont toujours là.

Cette conception, c'est la même histoire que l'index d'une vidéo ou le répertoire d'un ZIP : une petite carte à la fin, dont un lecteur a besoin avant de pouvoir exploiter le grand corps de données qui la précède. Et elle a la même conséquence. Si la xref est corrompue, pointe vers de mauvais décalages, ou a été entièrement coupée, le lecteur ne peut trouver un seul objet même si les pages se trouvent intactes dans le fichier. Le document est inutilisable, mais le contenu n'est pas perdu, il est seulement non indexé. Cet écart entre « inutilisable » et « perdu », c'est là que vit la réparation.

Pourquoi un téléchargement cassé casse tout le PDF

Deux choses tournent mal le plus souvent, et toutes deux laissent les objets intacts tout en détruisant l'index. La première est la troncature. Un PDF, comme la plupart des fichiers, se transfère du début à la fin : un téléchargement qui cale, une synchronisation cloud qui se ferme, ou un disque retiré en pleine copie vous laissent le début du fichier et rien après la coupure. Comme la xref et le trailer vivent à la fin, la troncature les supprime en premier tandis que les objets de page du début survivent. Une simple vérification de la taille le trahit : un contrat qui devrait peser 4 MB et qui arrive à 2,6 MB est tronqué, et les octets manquants ne sont pas endommagés, ils sont tout simplement absents.

La seconde est l'altération pendant le transfert. Un PDF est un mélange de données binaires et de structure de type texte, et un transfert qui modifie des octets en chemin — une passerelle de messagerie qui « corrige » les fins de ligne, un outil qui traite le fichier comme du texte, une étape d'encodage qui corrompt certains caractères — peut décaler la position réelle des objets, si bien qu'ils ne correspondent plus aux décalages enregistrés par la xref. La xref pointe désormais quelques octets à côté de l'endroit où chaque objet se trouve réellement, et le lecteur, suivant ces pointeurs périmés, ne trouve que du charabia et déclare le fichier endommagé.

Les deux cas partagent le même ordre de résolution. Puisque la réparation la plus sûre pour un fichier tronqué ou altéré est une copie propre des octets qui ont disparu ou changé, commencez par retélécharger ou recopier le fichier depuis sa source d'origine. Récupérez-le à nouveau sur une connexion stable, ou tirez-le directement de l'appareil ou du disque d'où il vient, puis ouvrez la copie fraîche. Un téléchargement propre répare le document entier d'un coup, là où la réparation ne peut reconstruire qu'autour de ce que vous détenez déjà, alors cela vaut toujours les deux minutes nécessaires pour essayer la source d'origine avant toute autre chose.

Reconstruire le xref

Quand aucune copie propre n'est disponible, la réparation consiste à reconstruire l'index. Chaque objet d'un PDF porte un marqueur reconnaissable dans le fichier, si bien qu'un outil de réparation peut ignorer complètement la xref cassée et scanner le fichier depuis le début, trouvant chaque objet survivant et notant où il se trouve véritablement. À partir de ce balayage, il construit une table de références croisées neuve et correcte ainsi qu'un trailer assorti, puis écrit un nouveau PDF dont l'index pointe réellement vers ses objets. Un lecteur qui ouvre le fichier reconstruit parcourt la nouvelle xref, trouve chaque objet là où la table indique qu'il est, et rend le document.

C'est exactement le travail que tente la propre passe de réparation d'Acrobat, et qu'elle abandonne souvent, mené plus à fond. Quand les objets ont survécu et que seul l'index était cassé — ce qui est le cas courant derrière cette erreur — la reconstruction récupère le document dans son intégralité. Elle est aussi non destructive lorsqu'elle est bien faite : l'outil lit votre fichier endommagé et en écrit un nouveau, si bien qu'une tentative ratée laisse l'original exactement tel qu'il était, sans que cela vous coûte rien d'essayer.

Quand reconstruire ne suffit pas

Reconstruire la xref récupère un document dont les objets sont intacts derrière un index cassé. Cela ne peut pas faire apparaître du contenu qui n'est pas dans le fichier, et quelques situations échappent à ce que toute réparation peut faire. Les nommer clairement est plus utile qu'une promesse :

• Les objets eux-mêmes manquent. Si la troncature a coupé une partie du fichier, les pages qui vivaient dans la section supprimée ont disparu. Une reconstruction récupère les objets qui ont survécu jusqu'à la coupure, et le document revient incomplet plutôt qu'entier. Il n'y a rien à indexer là où les octets n'existent plus.
• Le PDF est chiffré et vous n'avez pas le mot de passe. Un PDF protégé par mot de passe stocke son contenu chiffré. La structure peut être reconstruite, mais les pages restent chiffrées : sans le mot de passe, le fichier récupéré demeure illisible. La réparation ne contourne pas le chiffrement, et ne le devrait pas.
• C'est un PDF d'images numérisées aux pages endommagées. Un document numérisé, c'est essentiellement une image par page enveloppée dans un PDF. La récupération se fait page par page : les pages dont les données d'image ont survécu reviennent proprement, et celles dont les données d'image ont été tronquées ou écrasées, non, car il n'y a aucune redondance à l'intérieur d'une image compressée à partir de laquelle reconstruire. Attendez-vous à récupérer certaines pages et à en perdre d'autres, plutôt qu'à un flou partiel sur toutes les pages.
• Le fichier est presque vide. Un PDF revenu sous la forme de quelques kilo-octets d'un original de plusieurs méga-octets, ou qui se lit comme presque rien que des zéros, ne contient aucun objet réel à indexer. C'est un problème de téléchargement ou de récupération, pas de réparation.

En dehors de ces cas, un PDF qu'Acrobat a qualifié d'endommagé et qu'il n'a pas pu réparer relève fréquemment d'une simple reconstruction de l'index, car l'erreur concerne la carte bien plus souvent que le territoire.