Convertir XML en Texte en ligne gratuitement

Convertir un XML en texte : récupérer le contenu coincé entre les chevrons

Il y a un type de fichier qui finit toujours par vous tomber dessus quand vous constituez un corpus de textes : un export XML de quelque chose de réellement intéressant — des résumés d'articles scientifiques, des comptes rendus d'audience, une archive numérisée, dix ans de billets de blog — où la prose que vous cherchez est enfouie sous un schéma dessiné par quelqu'un en 2006. Les mots sont bien là. Ils sont simplement emballés dans trois couches de balises, avec des préfixes d'espace de noms par-dessus.

Cette page va chercher ce contenu et ne vous rend que le texte. Aucun titre, aucun tableau, aucun balisage d'aucune sorte. C'est ce qu'il vous faut quand la destination est un modèle d'embeddings, un index de recherche, un script de TAL, ou n'importe quelle chaîne de traitement qui considère la ponctuation comme du bruit. Déposez un fichier .xml ci-dessus — gratuit, sans inscription, 50 Mo maximum, rien n'est conservé.

Ce qui ressort de l'autre côté

Extraire, ce n'est pas seulement effacer tout ce qui se trouve entre < et >. Plusieurs points doivent être traités correctement, sans quoi la sortie est fausse de façon discrète :

• Les références d'entités sont décodées. XML ne peut pas contenir d'esperluette nue : les vrais documents sont donc truffés de &, <, " et de formes numériques comme ’ pour une apostrophe typographique. Laissées non décodées, elles faussent les comptages de mots et font échouer les recherches. Elles reviennent sous la forme des caractères qu'elles représentent.
• Les sections CDATA sont déballées. <![CDATA[ ... ]]>, c'est la façon dont XML fait passer en fraude du contenu qui contient du balisage — du HTML dans une description RSS, un extrait SQL, un bloc JavaScript. L'enveloppe saute, le contenu reste.
• Les nœuds de texte purement blancs sautent. Un XML indenté pour être lisible place, entre chaque paire de balises, un nœud de texte qui ne contient qu'un saut de ligne et quelques espaces. Gardez-les et votre sortie est faite à 60 % de lignes vides.
• Les noms d'éléments disparaissent purement et simplement. Contrairement à la version Markdown, les noms de balises ne sont pas conservés ici comme étiquettes. Vous obtenez les valeurs, pas le schéma.
• Commentaires, déclaration XML, DTD et instructions de traitement partent aussi. Rien de tout cela n'est du contenu.

Le bug des mots collés, et pourquoi il compte

Voici le mode de défaillance qui piège la plupart des suppressions de balises naïves, y compris quantité de solutions à base de regex récupérées sur un forum. Prenez du contenu mixte — du texte et des éléments enfants entremêlés dans le même parent :

<p>Voir l'<ref>annexe</ref> pour le détail</p>

Retirez les balises sans précaution et vous obtenez « Voir l'annexepour le détail », parce que la balise que vous venez d'enlever faisait office de frontière de mot. Faites l'inverse, insérez un saut de ligne à chaque balise, et la phrase se retrouve hachée en trois fragments sur trois lignes. Aucune des deux sorties n'est exploitable : la première casse la tokenisation, la seconde casse la segmentation en phrases, et toutes deux corrompent silencieusement ce qui, en aval, croit lire de la prose.

Un traitement correct laisse les éléments en ligne dans le fil du texte et ne coupe qu'aux vraies frontières de bloc. Si vous passez par un autre outil pour extraire le texte d'un fichier XML, c'est la première chose à tester : trouvez un paragraphe avec une balise en plein milieu et vérifiez que la phrase a survécu.

Le cas des fichiers de configuration

Vient maintenant la réserve honnête, celle qui vous évitera cinq minutes de perplexité. XML range ses données à deux endroits : entre les balises, et dans les attributs à l'intérieur de celles-ci. L'extraction de texte, par définition, ne récupère que la première catégorie. Or certains XML très courants n'en contiennent presque rien.

Les manifestes Android, les app.config .NET, les fichiers de build Ant, les définitions de beans Spring, beaucoup de SVG — tous mettent la quasi-totalité de l'information dans les attributs. Passez-en un dans un extracteur de texte et il vous revient trois mots égarés, ou un fichier vide, et on croirait à un échec de l'outil. Il n'a pas échoué : il n'y avait pas de texte d'élément à trouver.

Pour ces fichiers-là, prenez plutôt le convertisseur XML vers Markdown, qui garde les attributs rattachés aux éléments qu'ils qualifient. Le sélecteur de format en haut de cette page bascule de l'un à l'autre en emportant votre fichier : c'est un clic, pas un second envoi. Règle empirique : la prose vit dans les éléments, les réglages vivent dans les attributs. L'extraction de texte est faite pour la première espèce.

Quand extraire le texte d'un fichier XML est clairement le bon choix

XML est le format natif d'une quantité énorme de textes soigneusement édités, en grande partie parce que les institutions s'y sont standardisées avant même que JSON n'existe. C'est dans cet héritage que ce convertisseur trouve sa raison d'être :

• Constituer des corpus. Dumps de résumés académiques, textes littéraires encodés en TEI, comptes rendus parlementaires et décisions de justice, catalogues de musées et de bibliothèques. Beaucoup de prose de qualité, systématiquement enveloppée dans des schémas lourds. C'est la prose que vous voulez.
• Embeddings et recherche vectorielle. Vectorisez un morceau de XML brut et une part bien réelle du vecteur obtenu décrira le balisage plutôt que le sens — deux documents portant sur des sujets sans rapport peuvent atterrir côte à côte simplement parce qu'ils partagent un schéma. Retirer les balises vous donne des embeddings qui parlent du contenu.
• Le découpage en morceaux. Un découpeur à taille fixe tranche le XML brut en plein milieu d'un élément et produit des fragments à balises orphelines. Le texte plat se coupe aux frontières de phrase et de paragraphe, c'est-à-dire là où le découpeur sait travailler.
• Indexation et analyse de texte. Fréquences de termes, analyse de sentiment, modélisation thématique, extraction d'entités — tout cela est biaisé par des tokens structurels répétés sur chaque enregistrement.
• Économie de tokens. La verbosité de XML est frappante même parmi les formats structurés, puisque chaque nom d'élément s'écrit deux fois. Retirer les balises d'un export très imbriqué supprime une masse de tokens qui ne portaient aucune information. Le compteur sous la sortie vous dit exactement combien.

Quand aplatir est une mauvaise idée

Les modèles digèrent le XML brut sans difficulté : c'est verbeux, mais parfaitement non ambigu, et les données d'entraînement en regorgent. Convertir est une décision qu'on prend pour une raison précise, pas une règle.

• Écrire du code qui vise le document. Requêtes XPath, feuille XSLT, parseur SAX ou DOM, schéma. Tout cela réclame des noms d'éléments exacts, des préfixes d'espace de noms et la distinction attribut/élément intacte. L'extraction de texte enlève précisément ça. Collez plutôt un fragment du vrai fichier.
• La hiérarchie est la réponse. Si la question porte sur le parent sous lequel se trouve quelque chose — à quel environnement appartient un réglage, dans quelle section se situe une clause — l'aplatissement la détruit. C'est un travail pour Markdown.
• Les documents à forte densité d'attributs, comme ci-dessus.

Questions fréquentes

Comment convertir un fichier XML en texte ?

Déposez le .xml dans le convertisseur ci-dessus et le contenu situé entre les balises vous revient en prose brute — plus de chevrons, plus de préfixes d'espace de noms, plus d'attributs. Téléchargez en .txt. Gratuit, sans inscription, 50 Mo par fichier, rien n'est conservé.

Les entités comme & et < sont-elles décodées ?

Oui, et ça compte davantage qu'il n'y paraît. XML ne peut pas contenir d'esperluette nue : les documents réels sont donc denses en &, <, " et en références numériques de caractères. Une regex naïve de suppression de balises laisse tout cela littéralement dans la sortie. Un vrai parsing les résout vers les caractères qu'elles représentent.

Pourquoi ne pas simplement tout supprimer entre les chevrons avec une regex ?

Parce que les sections CDATA et les valeurs d'attributs contiennent toutes deux des caractères qui ressemblent à du balisage sans en être. Une regex avalera sans broncher le contenu d'un bloc <![CDATA[...]]> renfermant du HTML, et elle n'a aucun moyen de distinguer une vraie balise d'un < qui apparaît dans une valeur d'attribut entre guillemets. Le parsing traite ces cas correctement ; la correspondance de motifs se trompe, et en silence.

Les valeurs d'attributs sont-elles récupérées ?

Ce que vous obtenez, c'est le texte des éléments ; les attributs sont des métadonnées sur l'élément plutôt que son contenu. C'est en général le bon comportement — vous voulez le résumé, pas la version du schéma. Là où ça mord, c'est sur les formats qui stockent du vrai contenu dans les attributs : si votre sortie paraît maigre, ouvrez la source et vérifiez si les mots que vous cherchiez logent dans <tag attr="...">.

Est-ce que ça marche sur les flux RSS et les sitemaps ?

Oui — les deux sont du XML, les deux se convertissent. Un flux RSS vous rend titres, descriptions et dates en texte lisible, ce qui est une façon rapide de bâtir un corpus à partir des archives d'un blog. Un sitemap vous rend une liste d'URL, plus utile envoyée dans un autre outil que lue comme de la prose.

Outils voisins

Un mot sur le XML que vous croisez sans le savoir : les fichiers .docx et .epub sont, sous le capot, du XML zippé. Vous pouvez en dépaqueter un et donner le balisage interne à cette page, mais ne le faites pas — il est saturé de blocs de style et de métadonnées de révision qui noient le texte. Prenez Word vers texte ou EPUB vers texte, qui savent quelles parties sont du contenu. Pour du balisage HTML plutôt que XML, il y a HTML vers texte, et pour l'autre grand format de données structurées, JSON vers texte. File2Txt accepte tout ce qui est pris en charge si vous préférez ne pas choisir de page.

Et quand le XML dort au fond d'un dépôt — un fichier POM, un descripteur de build, des fixtures de test — le convertir tout seul le prive de son contexte. Le convertisseur GitHub vers texte, le convertisseur GitLab et le convertisseur de dossier local vous permettent de rassembler le XML et le code qui le lit dans une seule sortie, ce qui est presque toujours plus utile. Le guide de préparation des fichiers pour les LLM traite du cas général.

Repo2Txt est conçu et maintenu par v12hero, un développeur indépendant qui crée des applications natives et web respectueuses de la vie privée.