Convertir XML en YAML

Le XML porte l’information à trois endroits — noms d’éléments, attributs et texte — et YAML n’a que des clés et des valeurs. La projection a besoin d’une convention, et celle que ce convertisseur applique est la convention Badgerfish : chaque élément devient une clé dont la valeur est un objet de ses enfants, chaque attribut est ajouté à ce même objet avec un @ en préfixe, et le texte propre d’un élément, quand il a des voisins, est stocké sous la clé #text.

Un élément qui ne contient que du texte est plus simple : il devient une valeur chaîne nue, sans objet enveloppant. Cette alternance est inévitable, parce qu’elle est la traduction directe de ce que XML distingue déjà. Elle mérite d’être sue, parce qu’elle signifie qu’à un chemin donné, la valeur est tantôt une chaîne tantôt un objet selon que l’élément source portait ou non un attribut.

Un attribut ou un texte de plusieurs lignes dans un XML tient dans une seule ligne, parce que la RFC 7159 de JSON et le sous-ensemble de YAML 1.2 défini comme JSON ne permettent pas de saut de ligne littéral. La conversion vers YAML émet ces valeurs sous forme de scalaire bloc : un caractère pipe, puis le texte sur ses propres lignes indentées avec les sauts de ligne là où ils se trouvent.

Un manifeste, un script shell embarqué, un certificat en PEM ou une clause WHERE qui s’étendait sur huit lignes arrive sur huit lignes, et le fichier se relit. Pour quiconque dont la raison de convertir est qu’une personne va parcourir le résultat, c’est la plus grosse amélioration visible, et elle reste invisible tant que la source n’a pas de chaîne longue.

Un attribut est ajouté au parent de l’élément sous une clé @nom. Donc <a b="1">2</a> devient un bloc a avec b: "1" et #text: "2". Le registre marque cette conversion comme approximative, et c’est l’étiquette exacte : la décision « cet attribut va avec cet élément, ce texte va avec ce parent » est une convention que le convertisseur adopte à votre place, parce que le XML n’expose pas de règle générale qui dirait laquelle employer.

Là où le XML distingue l’attribut du texte, le YAML ne le peut plus après la conversion. Si une étape en aval a besoin de cette distinction, il faut la reconstruire à partir des noms — par exemple en marquant les attributs avec un préfixe @ que le code consommateur connaît déjà, et en traitant toute clé #text séparément. Ce n’est pas une perte, c’est une mise en conserve d’une décision dans la convention appliquée.

Une enveloppe SOAP arrive avec ses préfixes intacts : soap:Envelope devient une clé littéralement nommée « soap:Envelope », et la déclaration d’espace de noms est une clé @xmlns:soap du même objet. Rien n’est résolu, rien n’est élagué, et un consommateur peut faire correspondre sur la partie après les deux points pour retrouver la structure sémantique.

La fragilité est la même qu’en JSON : un préfixe est arbitraire, et un service qui émet soapenv:Envelope une semaine et soap:Envelope la suivante a produit deux documents équivalents et deux YAMLs incompatibles. Si vous contrôlez le code qui lira le YAML, faites la correspondance sur le nom local, et ne codez jamais en dur un préfixe que vous n’avez pas défini vous-même.

Les commentaires XML sont supprimés sans trace. Le CDATA est déballé : tout ce qui était à l’intérieur devient une chaîne YAML ordinaire, et un fragment HTML qui vivait dans une section CDATA, comme c’est fréquent dans des flux RSS, arrive comme du texte contenant des chevrons qu’une re-conversion en XML échapera au lieu de rétablir la section.

Le contenu mixte est le cas sans bonne réponse. Un paragraphe qui contient du texte, puis un élément enfant, puis davantage de texte, garde l’enfant sous sa propre clé et concatène les deux passages de texte en une seule valeur #text, sans marqueur de l’endroit où l’enfant s’insérait. Tout document où prose et balisage s’entrelacent — XHTML, DocBook, un document narratif structuré — perd son ordre, et le YAML est tout bonnement la mauvaise destination pour cela.

Un élément auto-fermant et un élément au corps vide deviennent tous deux une chaîne vide. Le XML non plus ne fait pas la distinction entre eux, donc rien n’a été perdu, mais le YAML n’a pas null à disposition et ne s’en sert pas — un élément vide est la chaîne "". Là où la différence compte entre un champ explicitement vidé et un champ jamais positionné, vérifiez la présence de la clé plutôt que sa valeur.

Les valeurs d’attributs qui ont l’air numériques sont laissées comme chaînes par convention : le YAML les écrira en clair ou avec des guillemets, mais elles ne sont pas transformées en nombres. C’est volontaire, parce que la transformation silencieuse de « 007 » en 7 ou de « 1.0 » en 1 est exactement le piège que la page sur XML en JSON décrit, et la conversion n’a pas de raison de le reproduire en sortie.

Un document XML ne dit pas quels éléments se répètent — seul un schéma le dit, et l’analyseur n’en lit pas. Donc un canal qui contient un élément item produit un objet, et un canal qui en contient deux produit un tableau d’objets. La forme du YAML dépend de la quantité de données dans le fichier source.

Le code écrit pour un flux RSS complet casse donc le jour où le flux n’a qu’une seule entrée, et le code écrit pour une réponse SOAP à un enregistrement unique casse la première fois qu’il en revient deux. Aucune option ici ne corrige cela. Normalisez toute collection en tableau dès la première opération, avant toute autre logique, et la conversion devient fiable.

Le YAML a des ancres et des alias, qui permettent de définir un bloc une fois et de le référencer à trois endroits, et il a plusieurs documents dans un seul fichier séparés par trois tirets. Aucun des deux ne peut sortir d’une source XML, parce que le XML n’a aucun moyen d’exprimer l’un ou l’autre. La sortie est correcte et plate : ce qui est répété dans le XML est répété dans le YAML.

Les commentaires YAML n’existent pas non plus en sortie, parce que le XML ne les porte pas vers le convertisseur. C’est volontaire et c’est précisément la valeur de la cible : ajouter un commentaire explicatif au-dessus d’une clé est la première édition qui vaut la peine, et le YAML est le bon endroit pour la faire, parce que la convention a déjà un caractère pour commencer une ligne de remarque.

La vérification qui coûte le moins est le dry-run de l’outil qui le lira : kubectl apply avec --dry-run=client, docker compose config, le linter d’un workflow. Chacun analyse le document et rapporte la forme qu’il a trouvée, ce qui attrape une clé mal placée bien plus vite qu’une lecture du fichier.

Trois habitudes défensives couvrent presque tout ce que cette conversion peut produire de surprenant. Normalisez toute collection en tableau. Comparez les identifiants comme des chaînes, et reconvertissez-les à la frontière si l’analyseur en a fait des nombres. Faites correspondre les clés préfixées sur leur partie locale. Avec cela, la conversion est fiable, et tout ce qu’elle fait d’autre est prévisible.

C’est du JavaScript dans votre onglet. Le XML est analysé par un parseur chargé à la demande, le YAML est écrit par une bibliothèque qui tourne dans l’onglet, et aucune requête ne porte le document. Il n’y a pas d’inscription, pas de file d’attente, et le niveau gratuit accepte jusqu’à 100 Mo — bien plus que n’importe quel fichier de configuration raisonnable.

Pour ce lectorat, c’est une préoccupation pratique plutôt qu’abstraite. Un manifeste tiré d’un cluster en cours d’exécution contient des noms d’hôtes internes, des chemins de registres, des noms de comptes de service et la forme de l’infrastructure, et un certain nombre d’organisations traitent le fait de coller cela dans un convertisseur web public comme un incident. Ici il n’y a rien à coller et rien à envoyer.