Convertisseur CSV vers JSON

À propos du convertisseur CSV vers JSON

CSV to JSON Converter est un outil gratuit qui transforme vos fichiers CSV en JSON (JavaScript Object Notation). Téléversez votre CSV ou collez vos données, choisissez le format de sortie et téléchargez le JSON obtenu, sans quitter votre navigateur.

Pourquoi toutes mes valeurs CSV apparaissent-elles comme des chaînes dans la sortie JSON ?

Parce que c'est exactement ce qu'elles sont dans le fichier source — CSV n'a pas de système de types, chaque cellule est du texte. Le convertisseur produit par défaut des chaînes pour un aller-retour sans perte, mais propose aussi une option « inférence de type » qui scanne chaque colonne et convertit les cellules en nombres, booléens ou null quand toute la colonne correspond à un motif. L'inférence de type est pratique mais risquée : une colonne de codes postaux où 90 % des lignes sont numériques ressemblera à des nombres mais perdra les zéros initiaux, et une colonne où la chaîne « NULL » ou « N/A » signifie manquant sera convertie de manière imprévisible. Pour les pipelines de production, préférez des types explicites par colonne : listez quelles colonnes doivent être number, boolean, date ou string et laissez le convertisseur n'appliquer que ces règles. La RFC 4180 ne décrit que les octets sur disque, jamais leur sens sémantique, donc les décisions de type vivent toujours au-dessus du format.

Comment le convertisseur gère-t-il la première ligne — est-elle toujours traitée comme en-tête ?

Par défaut, la première ligne est traitée comme en-tête et chaque cellule devient une clé JSON. Si votre fichier n'a pas de ligne d'en-tête, activez « La première ligne est une donnée » et le convertisseur utilisera des clés génériques comme column_1, column_2 — ou vous pouvez coller une liste d'en-têtes personnalisée. La RFC 4180 rend la ligne d'en-tête facultative mais la recommande, et la plupart des CSV du monde réel en incluent une. Attention aux en-têtes contenant espaces, points ou caractères spéciaux : les clés comme « Customer ID » ou « Order.Date » produisent du JSON valide mais sont pénibles d'accès programmatique. Le convertisseur propose une étape facultative « normaliser les en-têtes » qui met les clés en minuscules, remplace les espaces par des underscores et supprime les caractères non alphanumériques, produisant des identifiants snake_case propres comme customer_id et order_date amicaux à chaque langage en aval.

Puis-je produire du JSON imbriqué à partir d'un CSV plat avec des en-têtes en notation pointée ?

Oui. Si votre ligne d'en-tête CSV contient des chemins pointés tels que user.name, user.address.city et user.address.zip, activez l'option « Étendre les clés imbriquées » et le convertisseur construira un objet imbriqué par ligne : {"user":{"name":"Alice","address":{"city":"Paris","zip":"75001"}}}. Les segments numériques sont traités comme des indices de tableau, donc items.0.sku et items.1.sku deviennent {"items":[{"sku":"A"},{"sku":"B"}]}. C'est l'inverse de l'aplatissement par notation pointée utilisé par l'outil JSON-vers-CSV, donc les fichiers font l'aller-retour exactement quand vous utilisez les deux. Pour des formes complexes qui ne rentrent pas dans un schéma de chemin simple — unions hétérogènes, structures récursives — écrivez plutôt un script de mappage personnalisé en JavaScript ou Python ; le convertisseur gère les 80 % de cas courants, pas tout schéma imaginable.

Quelle forme de sortie JSON est-ce que j'obtiens — un tableau d'objets, un objet indexé par ID, ou autre chose ?

Le défaut est un tableau d'objets, un par ligne de données, qui est la forme la plus universellement consommée et le format que MongoDB, Pandas, BigQuery et la plupart des API REST attendent. Le convertisseur propose aussi deux alternatives. « Objet indexé par colonne » utilise la valeur d'une colonne choisie comme clé, produisant {"u_1":{...},"u_2":{...}} — utile quand vous avez besoin de sémantique de recherche par ID, mais requiert des valeurs uniques dans la colonne clé. « NDJSON » émet un objet JSON par ligne sans tableau englobant, ce qui est le bon format pour les pipelines de streaming (chargements BigQuery, Spark, ClickHouse) et évite le coût mémoire de bufferiser le tableau complet de chaque côté. Choisissez la forme tableau pour la lecture humaine et l'échange ; choisissez NDJSON pour l'ETL à grande échelle.

Mon CSV utilise des points-virgules comme séparateurs et des virgules comme marques décimales — le convertisseur gère-t-il cela ?

Oui — et vous ne devriez pas le laisser auto-détecter dans ce cas. Les CSV exportés par les tableurs dans les régions qui utilisent la virgule comme marque décimale (la majeure partie de l'Europe, Amérique latine, Vietnam) utilisent généralement le point-virgule comme séparateur de champ pour éviter l'ambiguïté. L'auto-détection du convertisseur tente de choisir le séparateur qui donne le nombre de colonnes le plus cohérent, ce qui capte généralement les points-virgules correctement, mais vous devriez toujours vérifier en regardant l'aperçu. Si vos cellules numériques utilisent la virgule comme séparateur décimal (1,5 pour un et demi), activez l'inférence de type et sélectionnez l'option « Format de nombre européen », sinon 1,5 sera parsé comme la chaîne « 1,5 » plutôt que le nombre 1.5. Différentes locales sont aussi en désaccord sur le séparateur de milliers — rendez ces règles explicites.

Comment le convertisseur gère-t-il les cellules vides, les valeurs manquantes et le texte littéral « null » ?

Par défaut, une cellule vide devient la valeur JSON null, le texte littéral « null » reste une chaîne, et une cellule contenant uniquement des espaces est aussi traitée comme vide. Vous pouvez changer les trois comportements. « Cellules vides comme chaîne vide » produit "" au lieu de null — mieux quand les consommateurs vérifient strictement les types et rejettent null. « Traiter NA, N/A, NULL comme null » parse ces chaînes sentinelles courantes comme JSON null, utile quand votre source utilise l'une de ces conventions. Pour les colonnes numériques, une cellule vide avec inférence de type activée devient null plutôt que 0, ce qui prévient l'erreur courante de sommer les valeurs manquantes comme zéro. La RFC 4180 ne définit pas la sémantique des champs vides, donc vous devez choisir une convention et la maintenir tout au long de votre pipeline.

Quel est le plus grand CSV que je peux convertir dans le navigateur sans planter ?

Les limites pratiques sont d'environ 50 Mo ou 500 000 lignes sur un navigateur desktop moderne ; le parser utilise une approche streaming en interne, mais le JSON résultant doit être matérialisé en mémoire avant de pouvoir être affiché ou téléchargé. Pour les fichiers dans la plage du gigaoctet, basculez vers un convertisseur streaming en ligne de commande : mlr --icsv --ojsonl cat input.csv > output.ndjson de Miller émet du NDJSON ligne par ligne et utilise une mémoire constante quelle que soit la taille du fichier, COPY (SELECT * FROM read_csv_auto('input.csv')) TO 'out.ndjson' (FORMAT JSON, ARRAY false) de DuckDB est aussi efficace et ajoute l'inférence de type, et les modules csv + json de Python combinés dans un pipeline de générateurs traiteront des tailles arbitraires. Pour les fichiers très larges (des milliers de colonnes), préférez Parquet à JSON — le stockage orienté colonne compresse bien mieux et interroge sélectivement sans lire le document entier.

Comment échapper les caractères spéciaux ou convertir correctement les dates et timestamps ISO ?

La mise entre guillemets et l'échappement au niveau CSV suivent la RFC 4180 : les champs contenant le séparateur, les guillemets doubles ou les sauts de ligne doivent être entourés de guillemets doubles avec les guillemets internes doublés, et le convertisseur gère cela automatiquement en entrée. Côté sortie JSON, les échappements JSON standards s'appliquent : \" pour guillemet double, \\ pour barre oblique inverse, \n \r \t pour caractères de contrôle et \uXXXX pour tout point de code Unicode au-dessus de la plage ASCII imprimable. Les dates ne sont pas un type JSON natif, donc le convertisseur les émet comme chaînes ISO 8601 (2026-05-17T00:00:00Z) quand l'inférence de type date est activée — c'est le seul format de date universellement interopérable, accepté par le constructeur Date de JavaScript, fromisoformat de Python, Instant.parse de Java et tous les principaux moteurs SQL. Évitez les formats spécifiques à la locale comme 17/05/2026 dans votre sortie.