Extraire toutes les adresses e-mail ou URL d'un bloc de texte

À qui appartiennent ces données

Cet article s'adresse à qui traite un texte qu'il possède déjà — un export de contacts d'un système que tu administres, une liste de liens issue de ton propre document, un jeu d'adresses qu'un client t'a envoyé pour que tu le mettes au propre. Collecter des adresses sur les pages web d'autrui pour bâtir une liste de diffusion est une autre activité, avec son propre risque juridique : sous le règlement général sur la protection des données, une adresse e-mail qui identifie une personne est une donnée à caractère personnel quelle que soit la page où elle a été publiée, et les règles anti-spam qui encadrent le courrier commercial non sollicité s'y ajoutent. C'est tout ce qui en sera dit ici.

La raison pratique de le dire est que les deux outils s'exécutent entièrement dans la page, sur ta machine, sans rien envoyer. C'est une vraie propriété de confidentialité quand le texte est une liste de clients, et cela vaut la peine d'être su. Ce n'est pas une autorisation juridique, et les deux choses sont assez souvent confondues pour mériter d'être séparées en une phrase avant de passer à ce que font vraiment les outils.

La fin d'une URL est une devinette, et celle-ci se joue sur cinq caractères

La norme URL du WHATWG définit ce qu'est une URL et comment analyser celle que l'on a déjà isolée. Elle ne définit pas comment en trouver une au milieu d'un paragraphe, parce que la question n'a pas de réponse correcte : un point après une URL est une ponctuation pour un lecteur et un caractère de chemin légitime pour un analyseur, et rien dans les octets ne les distingue. Chaque extracteur choisit donc un ensemble de caractères où s'arrêter. Celui-ci s'arrête aux espaces, au guillemet droit, à l'apostrophe, aux deux chevrons et à la parenthèse fermante, et il a été confronté à quinze contextes pour voir où cela mène.

Exclure la parenthèse fermante achète deux cas importants. Un lien entre parenthèses ressort propre, et un lien Markdown écrit en texte entre crochets suivi de l'adresse entre parenthèses aussi. Cela coûte un cas, et le coût est pire que le gain n'est bon : une adresse qui contient légitimement des parenthèses dans son chemin — la convention d'homonymie de Wikipédia en est l'exemple quotidien — est coupée à la partenaire de la parenthèse ouvrante et rendue tronquée. Une URL tronquée ressemble encore à une URL. Elle part dans un tableur, on clique dessus, et elle produit une page introuvable des semaines plus tard, sans rien pour remonter à la cause.

Les caractères qu'il n'exclut pas sont ceux qui ponctuent l'écriture ordinaire. Une URL en fin de phrase est revenue avec le point collé. De même pour une URL suivie d'une virgule, d'un point-virgule, d'un point d'exclamation, une URL entre crochets, une URL entre guillemets courbes typographiques, une URL entourée de tirets bas Markdown et une entre accents graves. Les guillemets français survivent, mais seulement parce qu'ils s'écrivent par convention avec une espace de chaque côté, et c'est l'espace qui arrête la correspondance. Aucun de ces cas ne produit d'erreur ; ils produisent une chaîne légèrement fausse qu'il faut nettoyer à la main.

Le lien en capitales qu'on ne trouve jamais

Le motif est écrit en minuscules et ne porte aucun indicateur d'insensibilité à la casse. Un texte contenant HTTPS://EXAMPLE.COM/A n'a rien rendu du tout. Idem pour Https://example.com/a avec une seule majuscule, ce que produisent certains traitements de texte quand un lien commence une phrase et que la majuscule automatique est active. Ce n'est pas un cas limite ; c'est une catégorie entière de documents — communiqués, mentions légales, tout ce qui est composé dans une charte qui crie — dont cet outil n'extraira aucun lien sans signaler le moindre problème. La norme URL indique explicitement que le schéma est comparé après mise en minuscules : un schéma en capitales est une URL normale et valide, pas une URL malformée.

Trois autres absences relèvent de la conception et non de l'accident, et il est utile de savoir laquelle est laquelle. Une adresse nue du type www suivi d'un domaine n'a pas de schéma : elle ne correspond donc pas, et ne le pourrait pas sans que l'outil devine que tout mot contenant des points est un hôte. Un lien ftp ne correspond pas. Un lien mailto ne correspond pas, même si extract-emails, lui, en tirera volontiers l'adresse. Si ta source est une page de coordonnées écrite par un humain plutôt que par une machine, attends-toi à ce que les adresses nues soient majoritaires, et prévois une seconde passe avec extract-domain, qui les cherche.

L'adresse accentuée qui revient fausse

extract-emails cherche une suite de lettres, chiffres, points, tirets bas, signes pour cent, signes plus et traits d'union, puis une arobase, puis un hôte, puis un point et au moins deux lettres. Une étiquette après un plus survit, ce qui compte car c'est ainsi que beaucoup de gens étiquettent leurs abonnements. Un point final est correctement laissé de côté, parce que le motif doit finir sur des lettres — la même phrase qui colle un point non voulu à une URL donne à une adresse une fin propre, belle illustration de tout ce que décide la forme du motif.

La partie locale est purement ASCII, et c'est là qu'on passe d'incomplet à faux. Comme une expression régulière cherche une correspondance n'importe où dans la ligne au lieu d'exiger le jeton entier, une adresse dont la première lettre est accentuée n'échoue pas à correspondre : elle correspond à partir de juste après la lettre accentuée. Un prénom allemand avec tréma a produit une adresse composée des deux dernières lettres du prénom, de l'arobase et de l'hôte. Un prénom français avec cédille a perdu ses trois premières lettres. Un prénom portugais avec tilde n'a gardé que sa dernière lettre. Et un nom de famille avec apostrophe n'a rendu que la partie située après l'apostrophe. Chacune de ces adresses est syntaxiquement valide et appartient à quelqu'un d'autre, ou à personne, et rien dans la sortie ne le signale.

La moitié « domaine » a le problème inverse et échoue plus proprement. Un hôte écrit avec des lettres accentuées dans son propre alphabet — les noms de domaine internationalisés que définit la RFC 5890 et qu'autorise la RFC 6532 dans les en-têtes de courrier — ne correspond pas du tout : l'adresse est ignorée plutôt que déformée. Écrit dans sa forme punycode, commençant par le préfixe x-n, le même hôte correspond sans problème, puisque le punycode est de l'ASCII par construction. Deux notes plus petites issues des essais : une partie locale entre guillemets, que la RFC 5322 autorise, n'est pas reconnue ; et une adresse en casse mixte et son jumeau en minuscules survivent tous deux à la déduplication, parce que la comparaison est exacte alors que la moitié « domaine » est insensible à la casse par spécification — ces deux-là sont une seule boîte listée deux fois.

Domaines et numéros de téléphone, en bref

extract-domain comble le manque laissé par l'extracteur d'URL : il lit les hôtes des liens à schéma, des adresses e-mail et — avec une bascule active par défaut — des domaines nus écrits sans aucun schéma. Il retire l'utilisateur et le mot de passe placés devant un hôte, le port placé derrière, le point racine final et, en option, un www de tête. Tout cela a été confirmé sur une ligne contenant une adresse d'intranet avec identifiants. Il refuse aussi une liste d'extensions de fichiers pour qu'une image ou un fichier de page ne passe pas pour un domaine, et celles qui figurent sur la liste sont bien ignorées.

Deux défauts méritent d'être signalés. D'abord, un domaine nu en fin de phrase est totalement manqué : le motif qui trouve les domaines nus refuse de s'arrêter devant un point, si bien qu'une phrase se terminant par un domaine suivi d'un point n'a rien rendu, alors que le même domaine au milieu d'une phrase, ou devant une virgule, ou devant un point d'exclamation, a été trouvé. C'est pourtant la façon la plus courante dont un domaine apparaît dans un texte, et c'est le seul cas qu'il ne traite pas. Ensuite, la liste d'extensions est une liste figée et non une règle : les extensions qui n'y figurent pas sont lues comme des domaines — un fichier d'archive et un fichier vidéo sont revenus comme s'ils étaient des hôtes. Aucun des deux problèmes ne produit de message d'erreur.

extract-phone-numbers est le plus prudent des quatre. Il reconnaît quatre formes précises plutôt qu'une suite de chiffres quelconque, exige entre sept et quinze chiffres une fois la ponctuation retirée, et il a été vérifié qu'il laisse les dates tranquilles, tant en année-mois-jour qu'en jour/mois, et qu'il laisse tranquille un long numéro de référence. Ce qu'il ne peut pas faire, c'est distinguer un numéro de téléphone d'une chose dont la forme est exactement celle d'un numéro — une référence de commande en trois chiffres, trois chiffres et quatre chiffres est revenue comme un numéro nord-américain, et rien dans le texte ne dit le contraire. Lis sa sortie plutôt que de lui faire confiance, phrase à laquelle cet article revient sans cesse.

Questions fréquentes

Pourquoi mes liens extraits ressortent-ils avec un point ou une virgule à la fin ?

Parce que l'extracteur s'arrête aux espaces, aux guillemets, aux chevrons et à la parenthèse fermante, et à rien d'autre. La ponctuation de phrase est un caractère de chemin légitime du point de vue du motif : le point qui termine ta phrase devient donc le dernier caractère du lien. Aucun réglage ne le change. Le remède pratique est une passe de rechercher-remplacer sur la liste extraite, ou un rognage manuel si la liste est courte. Le problème n'affecte pas les adresses e-mail extraites, car leur motif doit finir sur des lettres : un point final ne peut pas faire partie d'une correspondance.

Certains liens de mon document n'ont pas été trouvés du tout. Qu'avaient-ils en commun ?

Regarde d'abord le schéma. Un lien dont le schéma comporte la moindre majuscule est invisible pour cet outil — une adresse tout en capitales n'a rien rendu lors du test, et une adresse avec une seule majuscule initiale non plus, ce que produit un traitement de texte quand un lien ouvre une phrase. Cherche ensuite les liens sans schéma : une adresse nue commençant par www n'est pas reconnue, car le motif exige le protocole. Et les liens ftp et mailto sont hors de son périmètre par conception. Mettre le document en minuscules avant l'extraction règle le premier problème ; extract-domain, qui cherche les hôtes nus, couvre l'essentiel du second.

Les adresses qu'il rend sont-elles utilisables telles quelles ?

Pas sans les regarder. L'extracteur garantit que chaque résultat correspond à son motif, pas que chaque résultat est une adresse appartenant à quelqu'un. Deux modes de défaillance ont été observés directement : une adresse dont la partie locale commence par une lettre accentuée est rendue tronquée, ce qui produit une adresse d'apparence valide qui n'est pas celle du texte ; et les identifiants d'une URL de la forme utilisateur, deux-points, mot de passe, arobase, hôte sont rendus comme s'ils étaient une adresse. Sur une liste courte, lis-la. Sur une liste longue, trie-la et regarde les extrémités — les adresses tronquées se regroupent en tête parce qu'elles sont courtes, et les fabriquées partagent souvent un hôte que tu reconnais comme un serveur et non comme un fournisseur de messagerie.

Décode-t-il l'entité esperluette dans une chaîne de requête ?

Non. Une URL copiée depuis du source HTML, où le séparateur entre deux paramètres est écrit sous forme d'entité esperluette plutôt que sous forme de caractère, revient avec l'entité intacte — cela a été testé, les cinq caractères sont préservés exactement. Le résultat est un lien qui sera demandé avec des noms de paramètres commençant par « amp point-virgule », ce qui signifie en général que le second paramètre est ignoré en silence par le serveur. Si ta source est du HTML plutôt que du texte rendu, décode d'abord les entités ; si c'est du texte copié depuis une page rendue, le navigateur les a déjà décodées et il n'y a rien à faire.

Puis-je utiliser ces outils sur des adresses collectées sur les sites d'autrui ?

Les outils traiteront ce que tu colles ; savoir si tu peux collecter et utiliser ces adresses est une question distincte, et pas une question technique. Dans l'Union européenne, une adresse e-mail qui identifie une personne est une donnée à caractère personnel au sens du règlement général sur la protection des données, quelle que soit la page où elle figurait, et les règles sur le courrier commercial non sollicité s'appliquent indépendamment. Aux États-Unis, les règles équivalentes sur le courrier commercial sont fédérales. Si la liste est la tienne — ton propre export, ton propre document, les données d'un client que tu as été mandaté pour nettoyer — rien de tout cela ne se pose, et c'est la situation pour laquelle cet article a été écrit. Sinon, la question à trancher est juridique, et le fait que la page était publique n'y répond pas.