Aller au contenu principal
ToolsByUs

XML vers YAML

Ce convertit transforme un document XML en YAML lisible dans votre navigateur. Les attributs deviennent des clés préfixées par @, le texte d’un élément devient #text lorsqu’il partage l’élément avec des attributs ou des enfants, et les éléments frères répétés deviennent des séquences YAML. Les valeurs restent des chaînes de caractères, donc un code postal reste intact, et rien n’est envoyé.

100 % local

XML vers YAML en clair

XML transporte les valeurs en trois endroits — les attributs, le contenu texte et les éléments enfants — et YAML a de la place pour les trois dans un seul mappage, à condition que chacun ait un nom qui ne puisse pas entrer en collision avec les autres. C’est toute la convention que ce convertisseur applique : id="bk101" devient la clé "@id", le texte à l’intérieur d’un élément devient "#text" quand il a besoin d’un propre espace, et les éléments enfants deviennent des clés dont les valeurs sont des mappages ou des listes. Les préfixes semblent du bruit jusqu’à ce qu’un élément ait à la fois un attribut, un enfant et du texte — alors ils sont la seule raison pour laquelle l’aller-retour peut être sans perte.

Le style YAML est le style maison du site : une indentation de deux espaces, les tirets de séquence alignés avec leur clé parente plutôt qu’en retrait, et des guillemets uniquement là où la forme brute serait mal interprétée. Cette dernière règle fait un vrai travail ici. Le texte XML est non typé, donc 44.95 est une chaîne, et l’émetteur l’écrit comme "44.95" précisément pour qu’un analyseur YAML ne ré-infère pas un nombre à partir de celui-ci. Le résultat est un document qui fait un aller-retour : XML vers YAML et retour arrive avec les mêmes valeurs, les mêmes attributs et la même structure qu’il avait au départ.

Tout s’exécute dans cet onglet de navigateur. Le XML est analysé par un moteur en page et le YAML est généré à partir de l’arbre analysé ; aucun des deux ne touche au réseau — ouvrez DevTools, regardez le panneau Réseau rester silencieux, et la promesse se vérifie d’elle-même.

Pour renvoyer le résultat dans l’autre sens, le Convertisseur YAML vers XML respecte les mêmes conventions @ et #text, donc rien n’a besoin d’être renommé à la main.

Vous débutez avec la sortie YAML ? Le Guide des bases de YAML explique l’indentation, le guillemetage et les règles scalaires que suit l’émetteur.

Comment la conversion fonctionne réellement

Le document est transformé une seule fois en un arbre d’éléments, d’attributs et de texte, et l’émetteur YAML ne voit que cet arbre — donc les particularités de formatage de la source (indentation irrégulière, attributs répartis sur plusieurs lignes) ne peuvent pas s’infiltrer dans la sortie. L’arbre correspond soit à un document avec une seule racine, soit il ne correspond pas, et le convertisseur indique lequel.

  • Analyse : un analyseur à passage unique lit les éléments, les attributs, le texte, les commentaires et les CDATA ; les balises non appariées ou non fermées sont rejetées avec un numéro de ligne.
  • Conversion : chaque élément devient un mappage — les attributs comme entrées "@clé", le texte comme "#text", les éléments enfants comme clés imbriquées.
  • Collecte : les éléments frères répétés sont rassemblés en une seule liste, donc <book> apparaissant dix fois devient une séquence de dix éléments.
  • Émission : l’arbre est sérialisé en YAML avec une indentation de deux espaces, avec des guillemets uniquement là où une valeur serait autrement mal interprétée.

Comment les fonctionnalités XML se retrouvent dans YAML

Chaque fonctionnalité du document source a une place réservée dans la sortie, et les places sont choisies pour que deux fonctionnalités ne puissent jamais se disputer une même clé. Le tableau montre le mappage sur les formes qui apparaissent réellement dans des documents réels — un élément avec un attribut, un élément avec des enfants, un élément qui se répète.

Construction XMLYAML produit
<book id="bk101">un mappage book avec "@id": bk101
<price>44.95</price>price avec "#text": "44.95"
dix éléments <book> frèresune clé book dont la valeur est une liste de dix éléments
<debug/> (vide)debug: {} — présent, explicitement vide

Pourquoi #text existe, et quand il apparaît

Un élément dont le contenu est uniquement du texte — <price>44.95</price> — pourrait devenir le mappage simple price: 44.95, et pour les éléments sans attributs ni enfants, c’est effectivement ce que vous obtenez à lire. Mais dès qu’un élément porte aussi un attribut ou un enfant, son texte a besoin d’une clé qu’aucun nom d’attribut et aucun nom d’élément enfant ne pourra jamais occuper. #text est cette clé. Il n’apparaît que quand le texte doit partager son élément avec autre chose, ce qui garde la sortie ordinaire propre tout en rendant la sortie compliquée non ambigüe.

  • Les éléments texte uniquement conservent leur contenu lisible sur une ligne.
  • Les éléments mixtes — attributs plus texte, ou enfants plus texte — déplacent le texte sous "#text".
  • Les entités dans le texte source sont transmises telles quelles ; l’analyseur n’est pas un validateur et ne les réécrit pas.

Valeurs, types et la garantie de l’aller-retour

Le texte XML est des chaînes de caractères, et l’émetteur le traite ainsi : rien n’est forcé en nombre ou en booléen en cours de route. La conséquence visible est le guillemetage — 44.95 est écrit comme "44.95" car un 44.95 non guillemet serait relu comme un nombre en YAML, et un code postal comme 02134 perdrait son zéro initial de la même manière. Les valeurs qui ne peuvent pas être confondues avec autre chose, comme bk101, sont émises sans guillemets. Convertissez le résultat en arrière avec le convertisseur YAML vers XML du site et le document que vous obtenez est le document avec lequel vous avez commencé, octet pour octet là où cela compte : noms, attributs, texte et structure.

  • Pas d’inférence de type : le texte traverse comme texte, donc la précision et les zéros initiaux sont conservés.
  • Les chaînes qui ressemblent à des nombres sont mises entre guillemets en sortie, ce qui rend l’aller-retour sans perte.
  • Les espaces blancs à l’intérieur d’un nœud texte sont préservés ; les espaces blancs entre les éléments ne deviennent jamais des données.

Questions fréquentes

La conversion de XML en YAML envoie-elle mon document quelque part ?

Non. L’analyse et la génération YAML s’exécutent toutes les deux dans cet onglet de navigateur avec du code chargé une seule fois à l’ouverture de la page. Il n’y a pas de point d’envoi, et la page est servie avec une Content-Security-Policy dont connect-src est 'self', donc le navigateur refuserait toute demande sortante quel que soit le code. Regardez le panneau Réseau dans DevTools pendant que vous convertissez — il reste silencieux, et c’est la version vérifiable de cette promesse.

Que signifient les préfixes @ et #text dans la sortie ?

Ils enregistrent d’où vient chaque valeur dans le XML. Une clé comme "@id" contient un attribut — id="bk101" dans la source — et "#text" contient le propre texte d’un élément lorsque cet élément a aussi des attributs ou des enfants. Les préfixes garantissent aucune collision : un attribut nommé price et un élément enfant nommé price ne peuvent pas mapper tous les deux vers la même clé, et le lecteur YAML peut toujours dire quel type de valeur il regarde.

Les éléments répétés sont-ils gérés comme ?

Les éléments frères qui partagent un nom sont collectés en une seule séquence YAML : dix enfants <book> deviennent une seule clé book dont la valeur est une liste de dix éléments, dans l’ordre du document. Les éléments qui apparaissent une fois restent des mappages simples. C’est la convention XML-donnée standard, et c’est ce qui rend la sortie naturelle à parcourir en code — chaque élément de liste est un enregistrement, avec des attributs et des enfants imbriqués dedans.

Pourquoi 44.95 est-il écrit avec des guillemets dans la sortie YAML ?

Parce que le texte XML est non typé, la valeur est la chaîne 44.95 — et un 44.95 non guillemeté en YAML serait relu comme un nombre par chaque analyseur en aval. Mettre en guillemets les chaînes qui ressemblent à des nombres est la manière de l’émetteur de préserver ce que la source a réellement dit, et c’est la même règle qui empêche un code postal comme 02134 de perdre son zéro initial. Les valeurs qui ne peuvent pas être mal interprétées, comme bk101, sont émises sans guillemets.

Quelles parties du document XML sont ignorées ?

Les commentaires, la déclaration DOCTYPE et les instructions de traitement sont ignorés, car aucun ne transporte de données d’élément. Tout ce qui est structurel est conservé : éléments, attributs, texte et sections CDATA. Le convertisseur exige un seul élément racine — un collage avec deux éléments de niveau supérieur est rejeté avec le nom du deuxième élément et son numéro de ligne, car deux racines sont deux documents et les fusionner silencieusement créerait une structure qui n’a jamais existé.

Que devient les éléments vides comme <debug/> ?

Un élément vide devient un mappage vide explicite — debug: {} — plutôt que de disparaître, donc la clé survit et un consommateur peut toujours dire que le champ était dans le document. Un élément écrit avec des balises d’ouverture et de fermeture séparées mais sans contenu, <note></note>, atterrit au même endroit : la structure dit que l’élément existait, et seul le contenu était vide. Rien n’est inventé pour le remplir.

Équipe ToolsByUs · Comment nous vérifions nos outils