Convertir NDJSON en XML

Les deux formats se tiennent aux extrémités opposées de la même question. NDJSON est conçu pour qu’aucune ligne ne dépende d’une autre : on peut le scinder n’importe où, le reprendre après une panne, et le traiter sans le tenir. Un document XML est l’autre extrême — il n’est pas valide tant que la balise racine fermante n’arrive pas, donc tout l’ensemble est une unité du premier au dernier octet.

C’est la propriété autour de laquelle il faut planifier plutôt que les noms d’éléments. Une conversion d’un grand export produit un document unique qui doit être transmis, analysé et accepté comme un tout, et une défaillance n’importe où dedans fait échouer le tout. Là où le système récepteur a une limite de taille de message ou une politique de reprise, scinder la source en lots avant la conversion est la différence entre une livraison qui reprend et une qui recommence.

La forme est fixée parce que la forme de l’entrée est fixée. Un fichier délimité par des sauts de ligne est toujours une liste, et une liste n’a pas de nom propre, donc le document est un élément racine contenant un élément item par enregistrement. Chaque champ devient un élément enfant nommé d’après sa clé, et un objet imbriqué devient des éléments imbriqués en dessous.

Il n’y a pas d’option pour changer ces deux noms pendant la conversion, et il n’y a pas de manière sensée pour le convertisseur de les deviner — rien dans un fichier NDJSON ne dit si les enregistrements sont des commandes, des réclamations ou des mesures. La sortie est délibérément le document correct le plus simple, ce qui fait du renommage qui suit une recherche-remplacement prévisible plutôt qu’un démêlage.

Quasiment toute réception XML nomme son élément d’enregistrement dans un schéma : un document Orders contenant des éléments Order, un Batch contenant des Transactions. Donc les deux noms génériques sont des placeholders, et les remplacer est un travail de deux lignes dans n’importe quel éditeur — une occurrence de `root` à chaque bout, et `item` à chaque limite d’enregistrement.

Le faire avant la première livraison plutôt qu’après un rejet vaut les deux minutes. Une réception qui valide contre un schéma rejettera tout le document sur le nom de l’élément et le dira en général d’une manière qui ne le dit pas évidemment. Si les livraisons doivent être régulières, le renommage appartient au script qui déplace le fichier, pas à la mémoire d’une personne.

Une liste en XML a toujours été la même balise écrite plusieurs fois, donc un enregistrement avec trois étiquettes produit trois éléments `tags` côte à côte. Pas de numérotation, pas de jonction, pas de décision prise à votre place — la structure arrive intacte.

C’est l’argument le plus fort en faveur de XML sur les destinations tabulaires pour le même fichier. Convertir ces enregistrements en CSV force un choix entre colonnes numérotées, chaîne jointe et lignes supplémentaires, et chacun de ces choix perd quelque chose. Une commande avec cinq lignes ou un événement avec une liste de règles appliquées se convertit en XML sans aucun compromis, ce qui est souvent la raison pour laquelle le système récepteur a choisi XML en premier lieu.

Les clés JSON peuvent être n’importe quoi : espaces, barres obliques, chiffre initial, symbole monétaire. Les noms d’éléments XML ne le peuvent pas. L’écrivain réécrit plutôt qu’échouer — les caractères interdits par XML deviennent des soulignés et un nom commençant par un chiffre en gagne un devant lui — donc un champ appelé « 2024 total » devient un élément `__2024_total` avec un souligné devant.

Les exports générés par machine tombent dessus plus souvent que les faits à la main. Tout ce qui est indexé par une date, un nom de métrique, un en-tête HTTP ou une référence client produira des noms réécrits, et la réécriture est silencieuse. Si la réception a un schéma, ces éléments échoueront à la validation avec un nom que vous ne reconnaissez pas, donc il vaut la peine de chercher les soulignés dans la sortie avant la première livraison.

La réconciliation que les conversions tabulaires effectuent ne se produit pas ici, et n’a pas besoin de se produire. Chaque élément item porte exactement les champs que sa ligne avait, donc un fichier d’événements mêlés produit des éléments item de plusieurs formes à l’intérieur d’un document — ce qui est du XML valide et en général non valide contre un schéma.

Un schéma qui déclare une séquence fixée d’éléments enfants rejettera le premier enregistrement qui en omet un. Là où c’est le cas, filtrez la source à un seul type d’enregistrement avant de convertir, ou ajoutez les éléments manquants comme vides — et notez qu’un élément vide et un élément déclaré `nillable` sont des choses différentes pour un validateur strict. Lequel des deux la réception veut est une question pour leur documentation, et y répondre une fois économise un cycle de rejets.

Les esperluettes, crochets angulaires et guillemets doubles dans une valeur sont échappés, ce qui empêche une description de produit ou un message de journal contenant du balisage de mettre fin au document prématurément. Tout le reste, y compris le texte accentué et non latin, est écrit tel quel en UTF-8.

Un null JSON devient un élément vide : la balise est présente sans rien entre ses moitiés. Certains schémas veulent `xsi:nil` à la place, et certains veulent l’élément entièrement absent. Si la réception les distingue, c’est une édition scriptée sur la sortie plutôt que quelque chose que la conversion peut décider, parce que la source n’a qu’une seule manière de dire rien.

Chaque nom de champ apparaît deux fois par enregistrement — une fois dans la balise ouvrante et une fois dans la balise fermante — là où NDJSON l’écrit une fois. Ajoutez l’indentation et un document de petites valeurs avec de longs noms de champ arrive à deux à trois fois la taille du fichier dont il vient.

Sur un dépôt SFTP ou un transfert de fichier c’est sans importance. Sur une file de messages avec une limite de taille cela décide combien d’enregistrements tiennent dans un lot. La réponse est presque toujours la compression plutôt que la restructuration : un XML de ce genre est extrêmement répétitif et se gzip très bien, et la plupart des réceptions qui limitent la taille de message acceptent une charge utile compressée.

Bonne formation d’abord — n’importe quel éditeur XML ou analyseur en ligne de commande confirme en une seconde que le document s’analyse, et il le devrait. Validation de schéma ensuite, et attendez-vous à ce que la première tentative échoue sur les noms d’éléments, une déclaration d’espace de noms manquante sur la racine, ou l’ordre des éléments, puisque les séquences XSD sont ordonnées et les clés JSON ne le sont pas.

Une fois qu’un document passe, la forme du travail est réglée : scindez la source en lots de la taille que la réception accepte, convertissez chacun, appliquez les mêmes renommages et les mêmes attributs de racine. Faire le premier à la main et lire soigneusement la sortie du validateur est ce qui rend tous les autres mécaniques.

La conversion tourne dans cet onglet de navigateur : le fichier est analysé ligne par ligne et le document est écrit par un petit écrivain dans la page. Rien n’est téléversé, il n’y a ni compte ni file d’attente, et le niveau gratuit accepte jusqu’à 100 Mo, avec la mémoire comme plafond pratique parce que le document est assemblé entier.

Les données qui finissent sur ce parcours sont rarement triviales. Les livraisons à des régulateurs, des banques, des assureurs et des systèmes partenaires sont exactement les fichiers avec une clause de confidentialité attachée, et faire passer la conversion par un service web inconnu serait une deuxième divulgation à laquelle personne n’a consenti. Il n’y a rien à divulguer ici — ouvrez l’onglet réseau pendant une conversion et regardez.