BrowserTools
Accueil / Convertisseurs / Convertisseur JSON vers CSV, aplatir des tableaux JSON en feuilles de calcul

Convertisseur JSON vers CSV, aplatir des tableaux JSON en feuilles de calcul

Convertissez un tableau JSON d'objets en CSV dans votre navigateur. Aplatit objets et tableaux imbriqués, détecte les colonnes, prévisualise et télécharge.

Chargement de Convertisseur JSON vers CSV, aplatir des tableaux JSON en feuilles de calcul… Si rien ne se passe, activez JavaScript.

Collez un tableau JSON d'objets, ou déposez un fichier .json n'importe où sur l'outil, et obtenez instantanément un fichier CSV prêt à l'emploi. Le convertisseur détecte automatiquement les colonnes en prenant l'union de toutes les clés trouvées dans tous les objets, si bien que les enregistrements avec des champs différents ou manquants restent correctement alignés : les valeurs absentes deviennent simplement des cellules vides. Le tableau de prévisualisation montre les 20 premières lignes exactement telles qu'elles apparaîtront dans votre feuille de calcul, et un compteur de lignes et de colonnes confirme d'un coup d'œil la taille du résultat.

Questions fréquentes

Quelle structure JSON le convertisseur accepte-t-il ?
Un tableau d'objets au premier niveau, par exemple [{"name": "Alice", "age": 30}, {"name": "Bob"}]. Chaque élément devient une ligne du CSV. Si la valeur de premier niveau est un objet, une chaîne ou un nombre, ou si un élément du tableau n'est pas un objet, l'outil affiche une erreur claire expliquant exactement ce qu'il a trouvé à la place.
Comment les objets imbriqués sont-ils traités ?
Ils sont aplatis en notation pointée. Un objet comme {"address": {"city": "Lisbon", "zip": "1000"}} produit deux colonnes, address.city et address.zip. L'aplatissement fonctionne à n'importe quelle profondeur, les réponses d'API profondément imbriquées se convertissent donc sans prétraitement manuel.
Comment les tableaux à l'intérieur des objets sont-ils traités ?
Chaque élément reçoit sa propre colonne avec un indice entre crochets : {"tags": ["admin", "dev"]} devient les colonnes tags[0] et tags[1]. Les tableaux d'objets combinent les deux règles, si bien que items[0].price et items[1].price apparaissent comme des colonnes séparées. Les lignes avec des tableaux plus courts laissent les colonnes supplémentaires vides.
Que se passe-t-il quand les objets ont des clés différentes ?
L'ensemble des colonnes est l'union de toutes les clés trouvées dans tous les objets, dans l'ordre de première apparition. Un objet auquel il manque une clé reçoit simplement une cellule vide dans cette colonne, les données hétérogènes (courantes dans les exports NoSQL et les journaux d'API) se convertissent donc proprement sans perdre aucun champ.
Quand choisir le délimiteur point-virgule ?
Quand le fichier est destiné à Excel dans un paramètre régional européen (France, Portugal, Espagne, Allemagne et autres), où la virgule est le séparateur décimal et où Excel attend un CSV séparé par des points-virgules. Pour la plupart des autres outils, dont Google Sheets et les bibliothèques de programmation, la virgule standard est le choix sûr. La tabulation est utile pour coller directement dans un tableur.
À quoi sert l'option de guillemetage systématique ?
Par défaut, les champs ne sont entourés de guillemets doubles que lorsqu'ils contiennent le délimiteur, un guillemet ou un saut de ligne, ce qui est le style minimal du RFC 4180. Le guillemetage systématique entoure chaque champ de guillemets, ce qu'exigent certains importateurs stricts, systèmes anciens et pipelines de données. Les deux modes échappent les guillemets internes en les doublant.
Comment les caractères spéciaux comme les guillemets et les sauts de ligne sont-ils échappés ?
Selon la convention RFC 4180 : tout champ contenant le délimiteur, un guillemet double ou un saut de ligne est entouré de guillemets doubles, et chaque guillemet double à l'intérieur du champ est doublé. C'est l'échappement que comprennent Excel, Google Sheets, le module csv de Python et pratiquement tous les analyseurs CSV.
Mon JSON est-il téléversé vers un serveur ?
Non. L'analyse, l'aplatissement et la génération du CSV se déroulent entièrement dans votre navigateur en JavaScript. Rien de ce que vous collez ou déposez ne quitte votre machine, l'outil est donc sûr pour des exports confidentiels comme des listes de clients, des données financières ou des réponses d'API contenant des jetons.
Pourquoi les caractères accentués s'affichent-ils mal quand j'ouvre le CSV dans Excel ?
Excel suppose un encodage hérité sauf si le fichier commence par une marque d'ordre des octets UTF-8. Le bouton de téléchargement du CSV ajoute cette marque automatiquement, les accents, trémas et autres caractères non ASCII s'affichent donc correctement. Si vous utilisez le bouton copier et collez ailleurs, c'est l'application cible qui contrôle l'encodage.
Y a-t-il une limite de taille de fichier ?
La seule limite est la mémoire de votre navigateur. Des fichiers de dizaines de mégaoctets avec des centaines de milliers de lignes se convertissent sans problème sur une machine classique ; la prévisualisation ne rend toujours que les 20 premières lignes, l'interface reste donc réactive même avec de grandes entrées.

À propos de Convertisseur JSON vers CSV, aplatir des tableaux JSON en feuilles de calcul

Le JSON du monde réel est rarement plat, l'outil aplatit donc la structure automatiquement. Les objets imbriqués sont développés en notation pointée : {"address": {"city": "Lisbon"}} devient une colonne nommée address.city. Les tableaux sont développés avec des indices entre crochets : {"tags": ["admin", "dev"]} devient tags[0] et tags[1]. Les deux règles se combinent à n'importe quelle profondeur, si bien qu'une réponse d'API profondément imbriquée comme orders[0].items[2].price se transforme en un nom de colonne propre et prévisible sans aucun travail manuel.

Les options de sortie couvrent les particularités de chaque tableur. Choisissez la virgule, le point-virgule ou la tabulation comme délimiteur ; le point-virgule est ce qu'Excel attend dans la plupart des paramètres régionaux européens, où la virgule sert de séparateur décimal. Désactivez la ligne d'en-tête quand vous complétez une feuille existante, et activez le guillemetage systématique quand un importateur strict exige que chaque champ soit entouré de guillemets doubles. L'échappement suit la convention RFC 4180 : les champs contenant le délimiteur, des guillemets ou des sauts de ligne sont entourés de guillemets doubles, et les guillemets internes sont doublés. Le fichier téléchargé inclut une marque d'ordre des octets UTF-8 pour qu'Excel affiche correctement les caractères accentués.

Tout s'exécute côté client, dans votre navigateur : le JSON que vous collez ou déposez n'est jamais téléversé, journalisé ni stocké, ce qui rend l'outil sûr pour des exports contenant des données clients, des identifiants ou des dossiers internes. Les messages d'erreur sont précis plutôt que cryptiques : on vous dit si le JSON n'a pas pu être analysé (avec le message de l'analyseur lui-même), si la valeur de premier niveau n'est pas un tableau, ou quel élément précis n'est pas un objet. Les usages typiques incluent la transformation de réponses d'API REST en feuilles de calcul, la préparation de données pour Excel ou Google Sheets et l'alimentation d'outils qui n'acceptent que le CSV.

Des cartes perforées aux API REST : le drôle de couple des formats de données

Le CSV est bien plus ancien qu'on ne le croit. Des listes de valeurs séparées par des virgules apparaissent dès la toute première version du compilateur FORTRAN d'IBM en 1972, et l'idée générale de champs séparés par des délimiteurs remonte à la tabulation sur cartes perforées. Pourtant, pendant ses trois premières décennies, le CSV n'a eu aucune spécification : chaque programme inventait ses propres règles pour les guillemets, les fins de ligne et les virgules incluses, et c'est pourquoi analyser les fichiers CSV des autres est devenu un rite de passage pour les programmeurs. Le format n'a été couché par écrit qu'en 2005, quand le RFC 4180 a documenté les conventions de fait : champs séparés par des virgules, guillemets doublés pour l'échappement, enregistrements terminés par CRLF. Même alors, le RFC se décrit simplement comme la documentation d'une pratique existante, pas comme la définition d'une norme.

Le JSON est la moitié beaucoup plus jeune du couple, et il a été découvert plutôt qu'inventé. Douglas Crockford l'a nommé et spécifié en 2001, mais, comme il aime le rappeler, la syntaxe des littéraux d'objet de JavaScript existait déjà : il en a simplement extrait un sous-ensemble indépendant du langage, mis en ligne le site d'une seule page json.org et rédigé une spécification assez courte pour tenir sur une carte de visite. L'essor du JSON a suivi celui des API web : il a supplanté le XML dans les années 2000, surtout parce qu'il était plus léger à transmettre et correspondait directement aux structures de données de tous les langages majeurs, devenant une norme ECMA en 2013 et un RFC (8259) en 2017.

Les deux formats perdurent parce qu'ils se situent aux deux extrémités d'un compromis. Le JSON exprime la hiérarchie, l'imbrication, les types et les tableaux, ce qui le rend idéal pour les machines qui parlent aux machines. Le CSV exprime une grille plate, ce qui le rend idéal pour les humains qui regardent des données dans un tableur, encore aujourd'hui l'outil analytique le plus utilisé au monde. Presque tous les pipelines de données doivent tôt ou tard franchir cette frontière, en aplatissant des structures imbriquées en lignes et en colonnes, ce qui est précisément la transformation en notation pointée et indices entre crochets qu'effectue ce convertisseur. Un demi-siècle après les virgules de FORTRAN et un quart de siècle après json.org, traduire entre les deux reste l'une des tâches les plus courantes du travail sur les données.

Soutenir