Convertisseur XML vers YAML

YAML 1.2 a été conçu comme un surensemble de JSON : il n’y a donc pas d’arbre distinct ici. Le XML est converti vers la même structure que produit la page XML vers JSON, et un sérialiseur différent l’écrit. Chaque décision de projection de cette page s’applique sans changement : les attributs deviennent des clés préfixées, le texte qui partage un élément avec des attributs ou des enfants passe sous une clé de texte, un élément apparaissant deux fois devient une séquence, et les commentaires sont perdus.

Une chose empire. En JSON, un consommateur voit au moins des crochets ; en YAML, la différence entre un élément et deux est un scalaire indenté contre une liste de tirets, et personne ne repère cela dans un diff. Utilisez le champ « toujours un tableau » pour tout ce qui est conceptuellement une liste, afin qu’un document à un élément et un document à cinquante produisent la même forme.

<order id="00042">
  <total currency="GBP">19.90</total>
  <line sku="0071">Widget</line>
  <line sku="0072">Gasket</line>
  <country>NO</country>
</order>

order:
  attr_id: '00042'
  total:
    attr_currency: GBP
    text: '19.90'
  line:
    - attr_sku: '0071'
      text: Widget
    - attr_sku: '0072'
      text: Gasket
  country: 'NO'

YAML 1.1 définit son type booléen par énumération, et l’énumération est plus large que quiconque ne l’imagine. La page de types publiée liste, mot pour mot : y, Y, yes, Yes, YES, n, N, no, No, NO, true, True, TRUE, false, False, FALSE, on, On, ON, off, Off, OFF. Chacune d’elles, non citée, se charge comme un booléen.

La conséquence porte un nom. Un jeu de codes pays ISO reçoit NO pour la Norvège et l’analyseur remet false à l’application. La même liste avale une colonne Oui/Non exportée d’un tableur et tout interrupteur écrit on ou off qui se voulait du texte. YAML 1.2 a réduit le schéma central à true et false seulement, mais PyYAML, le Psych de Ruby, Ansible et une bonne part de l’outillage Kubernetes résolvent encore l’ensemble 1.1 : considérez donc qu’il est tout entier actif.

L’émetteur met entre apostrophes tout scalaire correspondant exactement à cette liste, formes à une seule lettre comprises, plus null, Null, NULL et le tilde. Notez la sensibilité à la casse : yES et nO ne sont pas dans la liste 1.1 et ne sont pas cités, car aucun analyseur conforme ne les lit comme des booléens non plus.

L’ensemble booléen est le cas célèbre, pas le cas courant. La plupart des valeurs qui cassent sont des nombres qui n’en ont jamais été, car YAML déduit un type de l’orthographe d’un scalaire nu exactement comme JSON ne le fait pas. Un scalaire est mis entre apostrophes quand il correspond à l’ensemble booléen ou nul, quand il correspond à une grammaire de nombre JSON (ce qui couvre 42, 19.90 et 1.10), quand il a un zéro de tête suivi d’autres chiffres, quand il est vide, quand il commence par un caractère indicateur de YAML comme un trait d’union ou un dièse, ou quand il a une espace à l’une de ses extrémités.

Le texte multiligne n’est pas cité. Il devient un scalaire de bloc littéral introduit par une barre verticale avec indicateur de suppression. Le littéral est choisi au lieu du plié à dessein : un bloc plié reflue les sauts de ligne simples en espaces, détruisant le code et les adresses incorporés. L’indicateur de suppression retire le saut de ligne final qu’un bloc ajouterait sinon.

Certaines valeurs quittent tout de même l’émetteur sans citation et peuvent changer de type en aval. Elles sont listées plutôt qu’escamotées, car aucun émetteur utilisant des scalaires nus n’a résolu l’inférence de types de YAML :

• Les nombres sexagésimaux. YAML 1.1 lit 22:22 comme un entier en base 60, donc une durée devient 1342 dans PyYAML. Un analyseur 1.2 comme js-yaml renvoie la chaîne : cela dépend donc du côté qui lit le fichier.
• Les écritures hexadécimales. 0x1F se charge comme 31 en YAML 1.1 comme dans le schéma central 1.2, donc un code couleur hexadécimal a besoin de citation.
• Les dates. 2024-01-05 correspond au type timestamp de YAML, donc js-yaml et PyYAML vous remettent tous deux un objet date plutôt qu’une chaîne.
• Les scalaires de bloc dont la première ligne est indentée plus loin que les suivantes, ce qui arrive quand une section CDATA préserve les espaces de tête. Le correctif de YAML est un indicateur d’indentation explicite après la barre verticale, que cet émetteur n’écrit pas.

C’est la seule préparation qui vaille la peine. Les valeurs par défaut ont été choisies pour JSON, où elles sont sûres, et YAML a une grammaire plus stricte pour les clés que pour les valeurs.

Le préfixe d’attributs par défaut est @_ et la clé de texte par défaut est #text. En YAML, @ est un indicateur réservé par lequel un scalaire nu ne peut pas commencer, donc une clé @_id rend le document non analysable : js-yaml signale « bad indentation of a mapping entry » et PyYAML signale un caractère qui ne peut commencer aucun jeton. Un # de tête est pire, car il n’échoue pas. Une ligne portant #text: 19.90 est un commentaire : le fichier se charge et la valeur n’y est tout simplement pas.

Les deux champs se trouvent dans la rangée de réglages au-dessus de l’éditeur. Mettez le préfixe à quelque chose de simple comme attr_ et la clé de texte à text, et chaque clé de la sortie est un nom YAML ordinaire. Les clés qui ont besoin de citation pour d’autres raisons, comme soap:Body, sont citées automatiquement, car les deux-points ne sont pas licites dans une clé nue.

Deux étapes : analyser le XML en sécurité, puis sérialiser avec un dumper auquel vous avez dit de citer correctement. La moitié XML a besoin des drapeaux d’entités habituels, car les réglages par défaut en Java et en .NET résolvent un DOCTYPE. La moitié YAML demande de l’attention, car les dumpers diffèrent sur l’agressivité de leur citation.