Extraire les liens d'un PDF

L'extracteur de liens PDF lit la liste d'annotations page par page d'un PDF — exactement ce qu'une bibliothèque de lecture comme pdf.js renvoie depuis getAnnotations — et retourne chaque hyperlien trouvé, avec son numéro de page et son URL cible. C'est l'étape qui manquait entre « j'ai les annotations » et « je sais où pointe ce document » : un passage déterministe, sans rendu, sans OCR et sans conjecture. Les liens purement internes et les annotations qui ne sont pas des liens sont écartés, de sorte que vous récupérez une liste propre et ordonnée des références externes que fait le document, prête pour un audit, une liste de départ pour un crawler ou un contrôle de conformité.

Pourquoi les annotations et pas le texte brut

Chercher des liens en parcourant le texte extrait n'est pas fiable : une URL visible dans le texte peut ne pas être cliquable, et un lien cliquable peut afficher un texte d'ancre qui ne ressemble en rien à sa cible. La source qui fait autorité pour extraire les liens d'un PDF est la couche d'annotations. Les lecteurs PDF stockent les éléments interactifs sous forme d'annotations rattachées à une page, et les hyperliens y vivent comme des entrées de sous-type Link avec une URI.

Cette capacité prend cette liste en entrée — un enregistrement par annotation avec son numéro de page, son sous-type et son URI optionnelle — et la filtre jusqu'aux véritables hyperliens sortants. Comme le numéro de page voyage avec chaque annotation, chaque résultat vous dit exactement où se trouve le lien dans le document, ce qui rend la sortie exploitable pour des relectures et des audits plutôt qu'une simple liste d'URLs.

Ce que l'extracteur garde et ce qu'il écarte

Le filtre est délibérément strict. Seules les annotations dont le sous-type est Link sont prises en compte ; les commentaires, les surlignages, les widgets de formulaire et tout autre type d'annotation sont ignorés. Parmi les annotations Link, seules survivent celles qui portent une URI non vide : une annotation de lien sans URI est généralement un saut interne vers une autre page, c'est-à-dire une navigation à l'intérieur du document et non un hyperlien vers une cible externe, donc elle est exclue.

Les URIs sont débarrassées des espaces environnants, mais sinon renvoyées telles quelles : sans réécriture, sans résolution, sans déduplication. Si la même URL apparaît sur trois pages, vous obtenez trois entrées, car le fait qu'elle apparaisse trois fois est une information. La sortie est ordonnée exactement comme arrivent les annotations, ce qui en pratique correspond à l'ordre du document.

La même URL peut légitimement apparaître plusieurs fois dans un long document — dans le pied de page répété, dans une bibliographie et dans une page de contact — et fusionner ces occurrences effacerait la distinction entre une citation ponctuelle et une référence systématique ; l'extracteur les conserve donc toutes et laisse l'appelant décider quoi agréger ensuite.

Où elle s'insère dans un pipeline

Le flux typique est le suivant : ouvrir le PDF avec une bibliothèque de lecture, collecter les annotations page par page, les aplatir dans la liste d'enregistrements attendue par cette capacité, puis les envoyer. Vous récupérez un compteur et un tableau de paires {page, url}. Les équipes s'en servent pour inventorier les références sortantes des contrats et des rapports avant publication, pour constituer la liste de départ d'une passe de vérification des liens, ou pour confirmer qu'un document anonymisé ne pointe plus là où il ne devrait pas.

Une liste d'annotations vide est traitée comme une erreur et non comme un résultat vide, car une liste vide signifie presque toujours que l'étape d'extraction amont a échoué ou que le fichier n'a jamais eu de couche d'annotations — et renvoyer silencieusement zéro lien le masquerait. Le même code s'exécute gratuitement dans votre navigateur sur cette page : vous pouvez donc valider une charge en la collant et ne payer que lorsque vous automatisez l'appel.