Convertir JSON en XLSX

C’est toute la différence avec la conversion vers CSV, et cela décide de tout le reste. Un programme veut du CSV : ça se lit en flux, chaque routine d’import le lit, et ça n’embarque aucune mise en forme qui se mettrait en travers. Une personne veut un classeur qui s’ouvre avec les colonnes à la bonne largeur, les en-têtes déjà reconnus comme en-têtes, et les types déjà corrects.

Si les données partent dans une base, un script ou un pipeline d’analyse, le CSV est la meilleure réponse et cette page-ci n’est pas la bonne. Si elles partent chez un collègue qui va les regarder, les trier et ajouter une colonne, c’est ici.

Un CSV n’a aucun type. Excel en ouvre un en devinant un type pour chaque colonne, et c’est dans cette devinette qu’arrivent les dégâts habituels : les zéros initiaux disparaissent des codes postaux et des références produits, tout ce qui ressemble à une date devient une date, et les identifiants au-delà de quinze chiffres perdent leurs derniers chiffres en flottant.

Un XLSX déclare ce qu’est chaque cellule, si bien que rien n’est inféré et rien n’est réécrit à l’ouverture. Cette seule différence supprime toute une catégorie de demandes de support, et c’est la raison de faire l’étape supplémentaire plutôt que d’envoyer un CSV et une explication.

Chaque enregistrement devient une ligne et chaque clé devient une colonne, la ligne d’en-têtes étant tirée des clés elles-mêmes. Les enregistrements qui ne partagent pas tous les mêmes clés sont réconciliés en construisant l’ensemble complet des colonnes à travers le fichier et en laissant vides les cellules où un enregistrement n’a rien à mettre.

Cette réconciliation mérite d’être connue parce qu’elle explique une surprise fréquente. Convertir dix enregistrements pour un test peut produire une feuille plus étroite que la conversion de l’export entier, simplement parce que l’échantillon n’a pas contenu par hasard les champs plus rares.

Le JSON décrit un arbre et un tableur est une grille, si bien qu’un objet imbriqué est aplati en joignant les noms de clés dans l’en-tête de colonne. Un niveau donne une feuille lisible par n’importe qui ; deux niveaux restent en général acceptables.

Au-delà, cela se dégrade d’une manière évidente dès qu’on regarde : les en-têtes deviennent longs, la feuille devient très large, et la plupart des cellules de la plupart des lignes sont vides parce que les enregistrements s’imbriquent différemment. Si une conversion produit soixante colonnes à partir de ce qui ressemblait à un export simple, c’est la forme des données et non un défaut — et un signal que le JSON devrait probablement rester JSON.

Une commande avec cinq lignes, un article avec une liste d’étiquettes, une personne avec plusieurs adresses antérieures — aucun de ces cas n’a de représentation correcte sur une seule ligne. Les trois réponses disponibles sont une colonne par position, une colonne avec les valeurs jointes, ou une ligne par élément, et chacune casse quelque chose.

Quand les tableaux portent le sens, faites ce que ferait une base de données : produisez une feuille pour les enregistrements parents et une pour les enfants, jointes par un identifiant. C’est plus de travail qu’une seule conversion, et c’est la seule version qu’un utilisateur de tableur peut réellement manipuler.

L’archive que ChatGPT, Claude ou un tableau de bord d’API vous remet est en JSON parce que c’est ce que lit une machine, et la plupart des gens qui en reçoivent une n’ont aucun outil qui l’ouvre utilement. Un tableur est la réponse réaliste : le XLSX déclare ses types, si bien que les horodatages restent des horodatages et que les identifiants numériques longs ne sont pas silencieusement réécrits en notation scientifique comme le ferait un CSV ouvert dans Excel.

Cela fonctionne bien sur les parties plates — journaux d’utilisation, lignes de facturation, listes de messages avec une entrée par ligne. Cela fonctionne mal sur l’archive de conversation elle-même, qui est un arbre de nœuds de messages plutôt qu’une table, et l’aplatir produit des colonnes nommées d’après des chemins que personne ne veut lire. Convertissez la partie dont vous avez réellement besoin plutôt que l’export entier.

Jetez un coup d’œil à la feuille, brièvement. Deux choses méritent d’être vérifiées à chaque fois : que les colonnes d’identifiants se lisent comme du texte plutôt que comme des nombres mis en forme, et que les colonnes de dates ressemblent à des dates plutôt qu’à des nombres à cinq chiffres.

Et regardez ce qu’elle contient vraiment. Un export JSON d’une API contient tous les champs que l’API renvoie, identifiants internes, drapeaux et parfois des champs dont personne n’a réalisé l’existence. Un tableur rend tout cela visible d’une manière qu’un fichier JSON ne fait pas, ce qui est une bonne chose à découvrir avant que le fichier ne quitte votre organisation plutôt qu’après.

La conversion tourne dans l’onglet du navigateur sur votre propre processeur. Le fichier n’est jamais envoyé nulle part, il n’y a pas de compte ni de quota journalier, et la limite est de 100 Mo par fichier.

Cela importe ici plus que sur la plupart des conversions. Un export JSON est presque toujours la sortie brute d’un système — fiches clients, commandes, soumissions de formulaires, comptes utilisateurs — et le confier à un convertisseur tiers revient à confier exactement les données dont une organisation est responsable. Ne les envoyer nulle part est la forme la plus simple de n’avoir à faire confiance à personne pour elles.