Aller au contenu principal
ToolsByUs

YAML vers XML

Ce convertisseur rend des mappages et des séquences YAML en XML dans votre navigateur. Les mappages deviennent des éléments imbriqués, les séquences deviennent des éléments répétés, et les valeurs scalaires deviennent du contenu texte, avec des clés nettoyées pour former des noms de balises valides et du texte échappé selon XML 1.0. Une clé préfixée par @ devient un attribut. Aucun fichier n’est envoyé.

100 % local

YAML vers XML en clair

YAML et XML expriment tous les deux des arbres, donc la conversion se résume principalement au vocabulaire : un mappage devient un élément avec des enfants, une séquence devient un élément répété, et un scalaire devient du contenu texte. La seule chose que YAML ne sait pas dire est un nom d’élément racine — un document XML en a exactement un — donc le convertisseur fournit <root> comme élément de document et imbrique votre document à l’intérieur. Une liste de premier niveau devient <root> contenant un élément répété par article ; un mappage de premier niveau conserve ses clés comme noms d’éléments un niveau plus bas.

Le côté strict de l’accord est constitué par les règles de nommage XML, et le converticiel les applique plutôt que d’espérer le meilleur : chaque clé devient un nom de balise valide, avec les caractères en dehors du jeu autorisé remplacés par des underscores et un underscore ajouté en début de nom si un nom commencerait par un chiffre. Le texte est échappé selon XML 1.0 à la sortie — &, < et > dans le contenu, plus les guillemets doubles à l’intérieur des valeurs d’attribut — afin qu’un analyseur conforme aux normes puisse lire le résultat. Les valeurs sont transmises telles quelles ; il n’y a pas d’étape de conversion numérique qui devinerait un numéro de port ou une chaîne de version.

Tout s’exécute dans cet onglet de navigateur. Le YAML est analysé par un moteur intégré à la page et le XML est sérialisé à partir du document analysé ; rien ne touche au réseau — ouvrez DevTools, observez le panneau Network rester silencieux, et la revendication de confidentialité se vérifie d’elle-même.

Vérifier le voyage de retour prend un seul collage, car le Convertisseur XML vers YAML lit les conventions @ et #text dans l’autre sens.

Si le côté d’entrée est la partie incertaine — indentation, guillemets, inférence de type — le Guide des bases de YAML couvre les règles que cet analyseur attend.

Comment la conversion fonctionne réellement

Le document est analysé une seule fois en données brutes, et l’écriture XML ne voit que ces données — jamais le texte original. Cette séparation rend les règles ci-dessous prévisibles : l’écriture ne peut pas être surprise par la syntaxe YAML, et l’analyse ne peut pas être influencée par ce que l’XML ressemblera. Chaque étape a un seul travail et une seule sortie.

  • Analyser : le YAML est lu en mappages, séquences et scalaires — le cœur quotidien, avec les commentaires autorisés et les ancres ou aliases en dehors du jeu pris en charge.
  • Envelopper : le document est placé à l’intérieur d’un seul élément <root>, car XML exige exactement un élément racine et YAML n’a aucun nom à proposer pour celui-ci.
  • Rendre : les mappages s’imbriquent comme éléments enfants, les séquences deviennent des éléments répétés, et les valeurs scalaires deviennent le contenu texte de l’élément nommé par leur clé.
  • Échapper et indenter : le texte subit les trois échappements XML obligatoires, les attributs échappent en plus les guillemets, et le document est mis en forme avec deux espaces par niveau.

La politique de nommage des balises, précisément

Les noms XML 1.0 peuvent commencer par une lettre, un underscore ou deux-points et peuvent continuer par des chiffres, des traits d’union, des points et deux-points ; tout le reste est interdit. Les clés YAML sont plus libres que cela, donc chaque clé est vérifiée et corrigée : un espace devient un underscore, un chiffre au début gagne un underscore en début, et une clé déjà légale — comme kebab-case tel que content-type — passe sans modification. Notamment, un point est un caractère légal à l’intérieur d’un nom XML, donc une clé comme address.city devient un seul élément nommé address.city ici, et non une paire imbriquée ; l’imbrication est exprimée par la structure YAML elle-même, et non par la ponctuation dans la clé.

Clé YAMLÉlément émisPourquoi
role<role>déjà légal — passé tel quel
first name<first_name>espace remplacé par un underscore
2fa<_2fa>les noms ne peuvent pas commencer par un chiffre
content-type<content-type>les traits d’union sont légaux dans les noms XML

Attributs, texte et la convention @

YAML a des mappages là où XML a des attributs, et le pont est la même convention que le convertisseur XML vers YAML du site utilise en sens inverse : une clé commençant par @ devient un attribut de son élément, et la clé spéciale #text porte le texte propre de l’élément quand celui-ci a aussi des attributs ou des enfants. Un enregistrement écrit comme {"@id": bk101, "#text": A guide} devient <book id="bk101">A guide</book> lorsqu’il est placé sous une clé book. La convention est optionnelle — les clés et valeurs ordinaires n’en ont pas besoin — mais elle signifie que toute la surface d’XML est accessible depuis des données YAML ordinaires sans une seconde syntaxe.

  • @sku: A-1 devient l’attribut sku="A-1" sur l’élément englobant.
  • #text contient le propre texte d’un élément, donc les attributs et le contenu peuvent coexister sans entrer en collision.
  • Une valeur null est entièrement omise ; une chaîne vide devient un élément auto-fermant, car les deux sont différents en YAML et la sortie respecte cela.
  • Les nombres et les booléens sont convertis en chaînes de caractères — 8080 arrive comme le texte 8080, true comme le texte true.

Les cas limites que le convertisseur ne pas masquer

Trois entrées obtiennent des erreurs nommées ou un comportement explicite et documenté au lieu d’un haussement d’épaules. Les fonctionnalités YAML que cet analyseur de convertisseur ne prend pas intentionnellement en charge — ancres et aliases, clés de fusion, directives — sont rejetées avec une erreur plutôt qu’à moitié implémentées, car un convertisseur qui devine l’expansion d’ancres invente du contenu. Un flux multi-documents est converti en utilisant son document final, documenté ici plutôt que laissé à la découverte. Et un document qui n’est qu’un scalaire est quand même converti : il devient le texte à l’intérieur de <root>.

  • Ancres, aliases et clés de fusion : rejetés avec une erreur nommée, pas étendus par devinette.
  • Flux multi-documents : le dernier document l’emporte, et le comportement est documenté ici plutôt que découvert par accident.
  • Tabulations utilisées pour l’indentation : rejetées au moment de l’analyse, selon les propres règles de YAML.

Questions fréquentes

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

Non. L’analyse et la génération XML s’exécutent toutes deux à l’intérieur de cet onglet de navigateur avec du JavaScript chargé une seule fois lorsque la page s’est ouverte. Il n’y a pas de route API pour envoyer des données, et la Content-Security-Policy de la page définit connect-src 'self', donc le navigateur lui-même refuserait toute requête sortante. Vous pouvez vérifier les deux affirmations dans DevTools : le panneau Network ne montre aucune requête lorsque vous convertissez.

Pourquoi mon XML est-il enveloppé dans un élément <root> ?

XML exige exactement un élément racine, et YAML n’offre aucun nom pour celui-ci — un fichier YAML est juste des données. Le convertisseur fournit donc <root> comme élément de document : une séquence de premier niveau devient <root> avec un élément répété par article, et un mappage de premier niveau conserve ses clés comme éléments enfants un niveau plus bas. Si vous avez besoin d’un nom de racine différent, placez vos données sous cette clé dans le YAML et elle devient l’élément que vous avez nommé.

Les clés YAML sont-elles transformées en noms de balises XML valides ?

Chaque clé est vérifiée par rapport aux règles de nom XML 1.0 et nettoyée uniquement là où elle échoue : les caractères en dehors des lettres, chiffres, underscore, trait d’union, point et deux-points deviennent des underscores, et un nom commençant par un chiffre reçoit un underscore en début. Les clés déjà légales passent sans modification. Un point est légal à l’intérieur d’un nom XML, donc address.city devient un seul élément de ce nom — l’imbrication vient de la structure YAML, pas des points dans les clés.

Le YAML peut-il produire des attributs XML et un contenu texte ?

Oui, via la convention @ : une clé commençant par @ devient un attribut de son élément, et la clé réservée #text porte le texte propre de l’élément. Écrire "@id": bk101 sous une clé book produit <book id="bk101">, et ajouter "#text": A guide met du texte à l’intérieur. C’est la même convention que le convertisseur XML vers YAML du site émet, donc un document peut traverser les formats dans les deux sens sans renommer quoi que ce manuellement.

Que fait le convertisseur avec les nombres, les booléens et les valeurs vides ?

Les scalaires sont convertis en chaînes de caractères, car le texte XML n’a pas de types : 8080 devient le texte 8080 et true devient le texte true, sans aucun changement de formatage. Une valeur null ne produit aucun élément, tandis qu’une chaîne vide produit un élément auto-fermant — la distinction que fait YAML est préservée dans la sortie. Le texte est échappé à la sortie (&amp;, &lt;, &gt;, et &quot; à l’intérieur des attributs), donc les analyseurs relisent exactement les caractères que vous avez écrits.

Quelles fonctionnalités YAML l’analyseur prend-il en charge ?

Le cœur quotidien : mappages, séquences, scalaires simples et entre guillemets, commentaires, et les types scalaires habituels. Ancres et aliases, clés de fusion et directives sont en dehors du jeu pris en charge et sont rejetés avec une erreur nommée plutôt que devinés — l’expansion silencieuse d’ancres inventerait du contenu qui n’était jamais dans votre fichier. Pour un flux multi-documents, le document final est celui qui est converti, ce que la page documente plutôt que laissant à la découverte.

Équipe ToolsByUs · Comment nous vérifions nos outils