Convertir XML en JSON

Le XML porte l’information à trois endroits — noms d’éléments, attributs et texte — et le JSON n’a que des clés et des valeurs, donc la projection a besoin d’une convention. Celle-ci est la courante : chaque élément devient une clé dont la valeur est un objet de ses enfants, chaque attribut devient une clé de ce même objet préfixée par @, et le texte propre d’un élément, quand il a des enfants ou des attributs à côté, est stocké sous la clé #text.

Un élément qui ne contient que du texte est plus simple : il devient une valeur chaîne simple, sans objet enveloppant. Cette incohérence est inévitable, et il vaut mieux l’adopter tôt, parce qu’elle signifie que la valeur à un chemin donné est tantôt une chaîne tantôt un objet selon que l’élément source portait ou non un attribut.

C’est la chose la plus coûteuse quand on consomme du XML converti. 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 JSON dépend de la quantité de données dans le fichier.

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, parce que la correction suppose de connaître le schéma. Écrivez le consommateur pour accepter les deux : forcez toute collection en tableau dès la première opération, avant toute autre logique.

Une enveloppe SOAP arrive avec ses préfixes intacts : soap:Envelope devient une clé littéralement nommée « soap:Envelope », et les déclarations d’espaces de noms passent comme des attributs de la forme @xmlns:soap. Rien n’est résolu, rien n’est élagué.

C’est fidèle et c’est fragile, parce qu’un préfixe est arbitraire. Un service qui émet soapenv:Envelope une semaine et soap:Envelope la suivante a produit deux documents équivalents et deux structures JSON incompatibles. Si vous contrôlez le consommateur, faites correspondre sur le nom local après le deux-points plutôt que sur la clé complète, et ne codez jamais en dur un préfixe que vous n’avez pas défini vous-même.

Un document qui s’ouvre par une déclaration de version et d’encodage produit une clé de premier niveau nommée « ?xml » contenant ses attributs, à côté de la clé de l’élément racine. Ce n’est pas du contenu de document, et elle est dans votre JSON.

Gérez-la en l’ignorant ou en la supprimant, mais ne supposez pas que l’élément racine est la seule clé de premier niveau. Le code qui lit la première clé de l’objet pour trouver la racine tombera sur la déclaration à la place sur tout document qui en a une, ce qui est la plupart d’entre eux.

Les valeurs qui ont l’air numériques deviennent des nombres JSON, dans les attributs comme dans le texte des éléments. Un attribut version écrit 1.0 devient 1. Un identifiant écrit 007 devient 7. Une valeur d’élément avec des zéros initiaux écrite 0755 devient 755.

C’est commode pour un compte et destructeur pour tout ce que vous traitiez comme un identifiant opaque. Les numéros de commande, les codes produit, les codes postaux, les versions de protocole et les modes de fichier échouent tous de la même manière, et aucun ne déclenche d’erreur. L’habitude à prendre est de regarder chaque attribut de la sortie que vous comptez comparer comme une chaîne, une fois, avant que le code qui le lise existe — c’est bien moins cher que de découvrir par un ticket d’assistance que la commande 007 et la commande 7 sont la même commande.

Les commentaires disparaissent sans trace, ce qui sur un contenu est en général anodin et sur un fichier de configuration est une perte réelle. Le CDATA est déballé : tout ce qui était à l’intérieur devient une chaîne ordinaire, donc un fragment HTML enveloppé dans un CDATA — la manière normale dont un flux RSS porte le corps d’un billet — arrive comme du texte contenant des chevrons, et une conversion de retour vers XML l’échapperait au lieu de rétablir la section CDATA.

Le contenu mixte est le cas sans bonne réponse. Un élément 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, tout ce qui est narratif — perd son ordre ici, et le JSON 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 de distinction entre eux, donc rien n’a été perdu, mais le JSON a null à disposition et ne s’en sert pas — un élément vide est « » et non null.

La distinction qui disparaît, c’est entre un élément qui était absent et un qui était présent et vide, une fois que votre code applique une valeur par défaut. Les deux finissent falsy. Là où la différence compte — un champ facultatif explicitement vidé versus jamais positionné — vérifiez la présence de la clé plutôt que la valeur.

Une fois assemblé, une réponse SOAP se lit comme un emboîtement de clés : la clé de l’enveloppe, à l’intérieur la clé du corps, puis la réponse de l’opération, puis le contenu. Chaque niveau garde son préfixe et l’ensemble a trois ou quatre objets de profondeur avant qu’une de vos données apparaisse, ce qui est exactement aussi verbeux que le XML et plus facile à parcourir depuis du code.

Un défaut est le premier cas à tester. Les défauts SOAP utilisent une structure d’éléments différente d’une réponse réussie, donc le JSON d’une erreur ne ressemble pas du tout au JSON d’un résultat, et un client qui n’a connu que le chemin heureux lira undefined sur un chemin qui n’existe plus. Convertissez ici une vraie réponse d’erreur et écrivez la branche d’erreur contre elle avant d’en avoir besoin.

La sortie est indentée de deux espaces, donc elle se lit bien en revue et se colle directement dans un fichier de test. Les fichiers de test sont le bon usage : convertir une vraie réponse et la commiter dans le dépôt donne au consommateur quelque chose d’honnête à tester, y compris tout ce qu’il y a d’embarrassant ci-dessus.

Trois habitudes défensives couvrent presque tous les problèmes de cette page. Normalisez en tableau tout ce qui peut se répéter. Comparez les identifiants comme des chaînes, et reconvertissez-les en chaînes à 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 en place, la conversion est fiable, et tout ce qu’elle fait d’autre est prévisible.