table_view Convertisseur CSV ↔ JSON star

Comment fonctionne réellement la conversion

CSV et JSON modélisent les données différemment, et le sens dans lequel vous convertissez détermine la part de conjecture impliquée. CSV → JSON est presque mécanique : la ligne d'en-tête devient l'ensemble des clés, et chaque ligne suivante devient un objet portant ces clés — name,age au-dessus de Ada,36 devient [{"name":"Ada","age":"36"}]. Les champs entre guillemets contenant des virgules, les guillemets échappés ("") et les cellules multilignes sont analysés selon la RFC 4180, et le séparateur (virgule, point-virgule ou tabulation) est détecté automatiquement à partir de la première ligne.

JSON → CSV est là où réside la vraie difficulté. Le CSV est strictement plat — une ligne, un enregistrement, une valeur par cellule — alors que JSON prend naturellement en charge l'imbrication : un objet peut contenir un autre objet ou un tableau comme valeur d'un champ, et il n'existe aucune méthode universellement admise pour faire tenir cela dans une seule cellule CSV. Prenez {"name":"Ada","address":{"city":"London"}} — la colonne doit-elle s'appeler address.city (notation par points, aplatissant l'objet imbriqué en colonnes supplémentaires), ou la valeur address entière doit-elle être intégrée sous forme de chaîne JSON brute dans une cellule, comme {"city":"London"} ? Les deux approches sont utilisées dans la pratique et aucune n'est « le » standard ; cet outil adopte la notation par points pour un niveau d'imbrication et se rabat sur l'intégration de texte JSON pour les tableaux et les structures plus profondes, car cela garde les objets simples réellement adaptés au tableur sans perdre silencieusement des données sur les objets complexes.

Un point à intégrer : ce n'est pas une lacune de l'outil, c'est une lacune du modèle de données lui-même. Tout convertisseur CSV↔JSON que vous essayez — celui-ci compris — doit faire un choix éditorial sur l'aplatissement, car les deux formats n'ont jamais été conçus pour être parfaitement interchangeables. Le CSV a été conçu pour des registres tabulaires ; le JSON a été conçu pour des documents à la forme arbitraire. Le savoir à l'avance explique pourquoi faire l'aller-retour d'un fichier JSON complexe par le CSV reproduit rarement exactement la structure d'origine, et pourquoi conserver des données profondément imbriquées au format JSON est souvent simplement le bon choix plutôt qu'une limite à contourner.

Ce qu'il est utile de savoir

• Le CSV n'a pas de types de données. Chaque valeur fait l'aller-retour en tant que texte, sauf si vous activez la conversion des nombres, qui transforme les chaînes ayant l'apparence de nombres en véritables nombres JSON (tout en laissant les identifiants à zéros en tête comme « 007 » sous forme de chaînes, puisque les convertir les corromprait).
• Le séparateur est détecté automatiquement, pas supposé. Excel exporte avec des points-virgules dans de nombreux paramètres régionaux européens et turcs, car la virgule y est déjà le séparateur décimal — l'analyseur examine la ligne d'en-tête pour choisir le bon.
• JSON → CSV réunit toutes les clés entre les objets. Si certains enregistrements ont un champ que d'autres n'ont pas, l'en-tête inclut chaque clé vue n'importe où dans le tableau, et celles qui manquent sont laissées vides sur cette ligne.
• Rien ne quitte votre navigateur. L'analyse et la conversion se font toutes deux localement en JavaScript, donc coller un export sensible ne l'envoie nulle part.
• L'ordre des lignes est conservé dans les deux sens. La première ligne de données reste première après la conversion, quel que soit le sens, ce qui compte lorsqu'un tableur ou un script en aval s'appuie sur l'ordre positionnel plutôt que sur une clé de tri explicite.