Convertir XML en Markdown en ligne gratuitement

Convertir XML en Markdown : les balises dehors, la hiérarchie dedans

XML a une manie qu'aucun autre format ne partage : il écrit le nom de chaque élément deux fois. Une fois pour l'ouvrir, une fois pour le fermer. Ajoutez les préfixes d'espace de noms, ajoutez les attributs, ajoutez l'indentation qui le rend lisible, et vous obtenez couramment un fichier où les balises pèsent plus lourd que le contenu qu'elles emballent. Un catalogue produit de 200 articles peut s'étaler sur des milliers de lignes et ne contenir, en tout et pour tout, qu'une page et demie d'information.

Convertir XML en Markdown garde l'arbre et jette le protocole. L'imbrication des éléments devient des niveaux de titres, les fratries répétées deviennent des listes ou des tableaux, et les chevrons disparaissent. Déposez un fichier .xml ci-dessus et vous le récupérez en quelques secondes — gratuit, sans inscription, plafond de 50 Mo, rien n'est conservé.

Ce que devient l'arborescence des éléments

La conversion parcourt le document et traduit chaque construction :

• Les éléments conteneurs deviennent des titres. Un élément qui a des enfants mais pas de texte propre est une section. Sa profondeur dans l'arbre fixe le niveau de titre : un schéma d'entreprise imbriqué sur cinq niveaux vous arrive donc en document correctement structuré.
• Les éléments feuilles deviennent des valeurs étiquetées. <author>Ursula Le Guin</author> se lit author : Ursula Le Guin. Un nom au lieu de deux, et plus de chevrons.
• Les fratries répétées deviennent des listes ou des tableaux — traité plus bas, parce que c'est là que se trouve l'essentiel du gain.
• Le contenu mixte reste en ligne. C'est le cas où du texte et des éléments enfants s'entremêlent, comme dans <para>Voir l'<ref>annexe</ref> pour le détail</para>. Les convertisseurs naïfs découpent ça en fragments et la phrase est perdue. Elle doit ressortir en une seule ligne lisible, avec la référence intacte.
• Commentaires, instructions de traitement et déclaration XML sautent. Rien de tout cela n'est du contenu.

Les attributs : ce qu'on perd sans s'en apercevoir

XML range ses données à deux endroits : entre les balises, et à l'intérieur de celles-ci. Le texte des éléments saute aux yeux. Les attributs, eux, s'oublient facilement, et beaucoup d'extractions naïves les laissent tomber sans prévenir. Sans conséquence quand il s'agit de métadonnées du genre id="4471". Catastrophique quand ils sont la charge utile.

Et ça arrive souvent. <price currency="GBP">49.99</price> ne veut rien dire sans la devise. Les formats de configuration sont pires : Maven, Ant, Spring, les manifestes Android et les fichiers app.config .NET mettent souvent la quasi-totalité de l'information dans les attributs, si bien qu'une extraction limitée au texte des éléments rend un document structurellement correct et presque entièrement vide. Si vous convertissez un fichier de configuration et que la sortie vous paraît suspicieusement courte, c'est ça.

Dans une sortie Markdown, les attributs doivent se poser à côté de l'élément auquel ils appartiennent plutôt que s'évaporer — rendus comme un court qualificatif accolé à la valeur, ou comme des colonnes supplémentaires quand l'élément fait partie d'un ensemble répété. Comparez le premier écran de sortie à la source avant de lui confier quoi que ce soit d'important. Dix secondes de survol valent mieux qu'une conversation confuse avec un modèle une heure plus tard.

Les fratries répétées deviennent des tableaux

La forme la plus favorable pour XML, c'est un parent qui contient de nombreux enfants identiques : des éléments <item> dans un flux RSS, des éléments <row> dans un export de base de données, des enregistrements <employee> dans un dump RH. Chaque enfant porte les mêmes sous-éléments, dans le même ordre.

Tout cela s'effondre en un seul tableau Markdown à barres verticales. Les noms des sous-éléments deviennent les en-têtes de colonnes, chaque enregistrement devient une ligne, et la répétition des balises — qui, dans le fichier brut, obligeait à écrire deux fois le nom de chaque champ pour chaque enregistrement — n'a plus lieu qu'une fois, dans l'en-tête. C'est la plus grosse réduction que vous verrez sur une conversion XML, et c'est la raison de préférer Markdown au texte plat dès que les données ont une forme d'enregistrements.

Ça se dégrade quand les enregistrements sont irréguliers — des éléments optionnels présents chez certains enfants et pas chez d'autres, ou un enfant qui contient un bloc imbriqué que les autres n'ont pas. Vous récupérez des trous, ou la partie imbriquée repoussée sous le tableau. Si vos données sont vraiment rectangulaires, exporter en CSV puis passer par le convertisseur CSV vers Markdown donne des tableaux plus propres. Et si la source ressemble plus à du JSON qu'à des balises, le convertisseur JSON vers Markdown attaque le même problème par l'autre bout.

Espaces de noms, enveloppes et bruit d'entreprise

Le XML du monde réel est rarement propre. Trois choses le gonflent bien au-delà de ce qu'il porte d'information :

• Les espaces de noms. Les déclarations xmlns et les préfixes comme soap:, xsi:, atom: ou dc: existent pour éviter les collisions de noms entre vocabulaires. Ils ne disent rien à un lecteur. Les préfixes sont retirés à la conversion, si bien que <dc:creator> se lit creator. Le seul cas où il faut y regarder, c'est quand deux espaces de noms emploient réellement le même nom local pour deux choses différentes — rare, mais à vérifier si vous fusionnez des vocabulaires.
• Les enveloppes SOAP. Une réponse de service web emballe la partie qui vous intéresse dans Envelope et Body, souvent flanqués d'en-têtes bourrés de tokens de sécurité et de données de routage. La conversion vous rend un document où la charge utile est enfin visible, au lieu d'être enterrée quatre niveaux plus bas sous du boilerplate qu'il faut sauter mentalement.
• Les références de schéma. xsi:schemaLocation, les déclarations DTD et les attributs de validation décrivent comment le fichier doit être contrôlé, pas ce qu'il raconte. Du bruit pour tous les usages qui nous occupent ici.

Les flux RSS et Atom sont, dans cette famille, du côté aimable. Uniformes, peu profonds, ils se convertissent en une liste propre d'entrées datées — une manière raisonnable de donner à un modèle un mois de publications d'un blog. Notez que les descriptions de flux contiennent en général du HTML échappé à l'intérieur du XML, qui ressortira donc sous forme de balisage dans votre sortie ; repassez-la dans le convertisseur HTML vers Markdown si vous la voulez propre, ou utilisez Web2Txt pour aller chercher les pages elles-mêmes.

Quand il vaut mieux ne pas convertir un XML en Markdown

Réponse franche, puisque quantité de pages qui vendent des convertisseurs se gardent bien d'en donner une : les modèles lisent très bien le XML. C'est verbeux, mais non ambigu, et extrêmement bien représenté dans les données d'entraînement. Convertir est un choix, pas une obligation.

Gardez le brut quand vous demandez des expressions XPath, une feuille XSLT, un parseur ou un schéma — tout ce où le modèle doit reproduire des noms d'éléments exacts, des préfixes d'espace de noms et la distinction attribut/élément. Markdown gomme délibérément exactement ces détails-là. Collez plutôt un fragment représentatif du vrai fichier.

Convertissez quand un humain doit le lire, quand vous cherchez à comprendre vite un schéma inconnu, ou quand le fichier brut est surtout fait de balises et que votre contexte est compté. Ce sont de vrais gains. Le reste relève de la préférence.

Le XML dont vous ignoriez que c'était du XML

Un bon nombre de formats que vous croyez binaires sont en réalité du XML zippé. Renommez un .docx en .zip, dépaquetez-le, et vous y trouverez document.xml plus une pile de fichiers de relations. EPUB, même histoire : des documents de contenu XHTML et un manifeste de paquet en XML dans un zip. Idem pour .pptx, idem pour .xlsx.

Vous pourriez en dézipper un et convertir le XML à la main. Ne le faites pas : le balisage interne déborde de blocs de style, de suivi des révisions et d'instructions de mise en page qui submergent le texte. Prenez Word vers Markdown ou EPUB vers Markdown, qui savent quelles parties de ce XML sont du contenu et lesquelles sont des consignes de mise en forme. Cette page-ci est faite pour le XML qu'on vous a remis en tant que XML : flux, exports, réponses d'API, configuration, échange de données.

Questions fréquentes

Comment convertir un XML en Markdown ?

Envoyez le .xml ci-dessus et la structure du document se projette sur du Markdown — la hiérarchie des éléments devient des niveaux de titres, les éléments frères répétés deviennent des listes ou des tableaux. Gratuit, 50 Mo par fichier, sans inscription. La forme du document est conservée, et c'est toute la différence avec son aplatissement en texte.

La hiérarchie des éléments devient-elle des niveaux de titres ?

Oui, c'est bien la correspondance retenue : un élément imbriqué devient un titre plus profond. Ça marche bien sur du XML de forme documentaire — DocBook, TEI, un export d'article — où l'imbrication reflète vraiment des sections dans des sections. Ça marche mal sur du XML de forme données, où l'imbrication reflète un schéma de base : vous récupérez douze niveaux de titres pour décrire un enregistrement.

Que deviennent les préfixes d'espace de noms ?

Ils sont retirés de la sortie. Un titre affichant dc:title ou tei:head n'apprend rien à un humain et moins encore à un modèle : le préfixe saute et le nom local de l'élément est conservé. Si deux espaces de noms du même document définissent le même nom local, ils se confondront — c'est rare, mais ça mérite un coup d'œil si certains titres semblent dupliqués.

Est-ce utile pour convertir du DocBook ou du DITA ?

Pour une première passe, oui. La prose, les sections, les listes et l'emphase en ligne passent bien, parce que ces formats les balisent explicitement. Le profilage conditionnel, les références de contenu, les inclusions d'entités et la résolution des renvois ne survivent pas — or c'est précisément ce qui justifiait l'usage de ces formats, et aucun convertisseur générique ne sait les résoudre.

Que choisir pour un gros corpus XML ?

Le texte, dans la plupart des cas. Si vous construisez des embeddings sur des milliers d'enregistrements, la syntaxe des titres n'est qu'une surcharge répétée sur chaque morceau, sans le moindre bénéfice à la recherche. Markdown mérite sa place quand un humain ou un modèle va lire un document entier et a besoin de savoir où sont les sections.

Plutôt du texte brut, et le reste de la panoplie

Si vous ne voulez aucune structure — du texte pour des embeddings, un index de recherche, ou le décompte de tokens le plus bas possible — prenez XML vers texte brut, qui va chercher le contenu entre les balises et ne laisse rien d'autre derrière. Le sélecteur de format en haut de cette page passe de l'un à l'autre en gardant votre fichier chargé : comparer les deux sorties tient en un clic. Le compteur de tokens sous la sortie vous dit ce que chacune coûte.

Si le XML n'est qu'un fichier parmi d'autres dans un projet — une configuration, un descripteur de build, une fixture — le convertir isolément donne au modèle la donnée sans le code qui l'entoure. Le convertisseur de dépôt GitHub vers texte et le convertisseur de dossier local vous laissent prendre le XML et le code qui le consomme ensemble, ce qui est en général l'unité la plus utile. File2Txt gère tous les formats pris en charge au même endroit, et le guide de préparation des fichiers pour les LLM pose les principes généraux.

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.