JSON vers CSV

Le JSON est construit pour représenter des données arbitrairement imbriquées en forme d'arbre — objets dans des objets, tableaux dans des objets, valeurs de types réellement différents côte à côte — tandis que le CSV ne peut représenter qu'une table plate et uniforme : lignes et colonnes, chaque ligne avec le même ensemble de colonnes, chaque cellule une seule valeur plate. Convertir de la première forme à la seconde signifie nécessairement prendre des décisions sur comment aplatir quelque chose qui ne rentre pas naturellement en lignes et colonnes, ce qui est là où réside l'essentiel de la vraie complexité de ce type de conversion — pas dans la lecture de la syntaxe JSON elle-même, qui est directe, mais dans la décision de ce qu'une ligne de tableur devrait même signifier pour des données qui n'ont jamais été tabulaires au départ.

Un objet imbriqué comme `{"user": {"name": "Ada", "id": 42}}` n'a aucune colonne unique évidente en laquelle devenir dans une table plate, donc il est aplati en deux colonnes séparées — `user.name` et `user.id` — avec la notation par points préservant exactement d'où vient chaque valeur dans la structure d'origine. C'est une convention largement reconnue précisément car elle est réversible : une colonne nommée `user.name` décrit sans ambiguïté un chemin de retour vers une structure imbriquée, ce qui compte si le CSV doit un jour être reconverti en JSON ou importé dans un système comprenant les chemins à points comme champs imbriqués.

Les tableaux imbriqués sont gérés différemment, et délibérément ainsi : plutôt que de faire exploser un tableau en lignes supplémentaires — ce qui changerait le nombre de lignes de la table selon combien d'éléments imbriqués se trouvent dans un enregistrement, un effet secondaire réellement surprenant et souvent non désiré — une valeur de tableau est sérialisée en texte JSON dans une seule cellule. Le nombre de lignes reste prévisible et correspond exactement au nombre d'enregistrements d'entrée, ce qui est presque toujours ce que veut réellement quelqu'un convertissant vers un tableur, au prix que cette cellule nécessite une analyse supplémentaire si son contenu est nécessaire individuellement.

Les vraies réponses d'API et le JSON assemblé à la main contiennent fréquemment des enregistrements où tous les objets n'ont pas des clés identiques — un champ optionnel présent dans certains enregistrements et absent d'autres, ou un schéma qui a évolué dans le temps donc les enregistrements plus anciens et plus récents diffèrent légèrement. Le CSV ne peut pas représenter cette variation directement, chaque ligne devant s'aligner sur le même ensemble fixe de colonnes ; un programme lisant un fichier CSV n'a aucun moyen de savoir qu'il « manque » une colonne à une ligne sauf si chaque ligne a explicitement une cellule pour elle. La solution est de calculer l'union de chaque clé vue dans chaque enregistrement, dans l'ordre où chaque clé a été rencontrée en premier, et de remplir une cellule vide pour tout enregistrement auquel manque un champ donné — ainsi la forme reste cohérente dans tout le fichier sans sacrifier silencieusement les colonnes d'aucun enregistrement ni désaligner des valeurs dans la mauvaise colonne.