ToolActToolAct

Convertisseur CSV vers JSON

Téléchargez un fichier CSV ou collez les données pour convertir au format JSON

Déposez le fichier CSV ici, ou cliquez pour sélectionner

Qu'est-ce que CSV vers JSON ?

CSV vers JSON est un outil en ligne de conversion de format de données qui convertit les données CSV (valeurs séparées par des virgules) en format JSON (notation objet JavaScript).

CSV est un format de données tabulaires courant, largement utilisé dans les feuilles de calcul et les exportations de bases de données. JSON est le format d'échange de données le plus populaire dans les applications web modernes, connu pour sa structure claire et son analyse facile.

Avec cet outil, vous pouvez convertir rapidement les données CSV en tableaux ou objets JSON pour une utilisation en programmation et en traitement de données.

Comment utiliser

Comment utiliser

  1. Collez ou saisissez les données CSV dans le panneau de saisie de gauche
  2. Sélectionnez le délimiteur approprié (la virgule est la valeur par défaut)
  3. Choisissez si la première ligne doit être utilisée comme noms de champs
  4. Le panneau de droite génère automatiquement le résultat JSON

Notes sur l'analyse CSV

  • Vérifiez le délimiteur, la gestion des guillemets et les paramètres de ligne d'en-tête avant de faire confiance à la sortie JSON.
  • Les fichiers CSV volumineux peuvent contenir des lignes vides, des virgules intégrées ou des sauts de ligne dans des cellules entre guillemets ; prévisualisez quelques lignes après la conversion.

Cas d’utilisation

Convertir des fichiers CSV ou TSV uploadés en tableaux JSONDéposez ou sélectionnez un fichier .csv, .tsv ou .txt, choisissez le délimiteur virgule, tabulation, point-virgule ou barre verticale, et décidez si la première ligne doit devenir les clés des objets ou si la sortie doit rester en tableaux. Le fichier est lu dans le navigateur avec FileReader, analysé localement par un tokenizer en flux et jamais uploadé ; les exports clients ou internes ne quittent donc jamais l’appareil.
Prévisualiser le nombre de lignes et de champs avant d’utiliser le JSONUtilisez le nom de fichier affiché, le nombre de lignes, de champs et la sortie JSON surlignée pour détecter les erreurs de délimiteur, les en-têtes manquants ou les lignes vides avant de copier dans des mocks ou des scripts. Cela fonctionne bien comme étape intermédiaire contrôlée : collez la sortie dans la destination réelle et vérifiez que le système récepteur l’interprète de la même manière.
Traiter du CSV entre guillemets simple sans quitter le navigateurL’analyseur prend en charge les champs entre guillemets, les guillemets doublés d’échappement et les quatre délimiteurs courants, ce qui le rend adapté aux petits exports et aux données de test. Les fichiers sont traités entièrement en mémoire du navigateur ; même des instantanés sensibles RH, financiers ou de préproduction peuvent être restructurés sans envoyer les données sur le réseau.
Préserver les informations de type lors de l’envoi à une API typéeAprès la conversion, balayez la sortie pour repérer les champs qui devraient être des nombres, booléens, dates ou nulls plutôt que des chaînes, puis post-traitez le tableau avant de l’envoyer aux endpoints REST ou GraphQL. Le CSV n’a pas de types natifs ; un rapide balaye visuel des premières lignes suffit généralement à repérer les IDs entre guillemets et les codes préfixés de zéros.
Détecter les lignes malformées avant injection dans les mocksUtilisez le nombre de lignes/champs et les erreurs d’analyse pour signaler les lignes qui ne correspondent pas au nombre de colonnes attendu, puis corrigez le CSV source plutôt que de laisser de mauvaises lignes se glisser dans le JSON de mock. Le panneau de prévisualisation s’arrête à la première ligne incohérente pour que vous puissiez corriger le délimiteur ou ajouter un guillemet manquant avant de relancer.

Principe technique

L'analyse CSV suit la grammaire IETF RFC 4180 : chaque enregistrement se termine par CRLF (certains dialectes acceptent LF ou CR), chaque enregistrement contient des champs séparés par un délimiteur (virgule dans la RFC, mais TSV, point-virgule et pipe sont des variantes largement répandues), et tout champ contenant le délimiteur, un CR, un LF ou un guillemet double DOIT être entouré de guillemets doubles avec les guillemets internes échappés par doublage (Hello "world" devient "Hello ""world"""). L'analyseur de cette page est un automate à quatre états — field_start, in_unquoted, in_quoted, after_quote — et traite l'entrée en un seul passage O(n) sur le flux de caractères, de sorte qu'un CSV de 10 Mo avec 100 000 lignes se termine en bien moins d'une seconde sur un ordinateur portable standard sans jamais allouer de tableau de tokens intermédiaire par ligne. L'encodage nécessite un traitement explicite : un BOM UTF-8 (EF BB BF) en début de fichier est supprimé avant l'analyse, sinon le premier nom d'en-tête commencerait silencieusement par le point de code invisible U+FEFF et les vérifications d'égalité JSON.parse en aval échoueraient. Les exports Excel sur Windows émettent encore du CRLF et souvent de l'UTF-8 avec BOM, tandis que macOS Numbers et la plupart des outils Unix utilisent par défaut du LF sans BOM. Les feuilles de calcul européennes exportent couramment des fichiers délimités par des points-virgules car la virgule est un séparateur décimal dans de nombreuses locales (49,90 EUR plutôt que 49.90), ce qui explique pourquoi le sélecteur de délimiteur est par défaut sur virgule mais expose tabulation, point-virgule et pipe comme choix de premier plan. Le basculement première-ligne-comme-en-tête change la forme de sortie d'un tableau d'objets (clés d'en-tête -> valeurs chaîne) à un tableau de tableaux, correspondant aux deux modèles d'ingestion courants pour le code en aval. Les valeurs de champs sont émises sous forme de chaînes, et non comme types inférés — le CSV n'a pas de schéma, donc 01234 (un ID à zéro non significatif), 1e10 (une chaîne ressemblant à un numéro de téléphone que JSON.parse convertirait en nombre) et 2024-13-45 (une date malformée) restent tels quels. C'est intentionnel : une API typée en aval peut appliquer zod, Joi ou une couche de conversion artisanale avec des règles explicites, mais elle ne peut pas récupérer un zéro initial que le convertisseur aurait déjà supprimé. La sortie est générée via JSON.stringify(rows, null, 2) et rendue via un colorisateur syntaxique ; le CSV source est lu avec FileReader.readAsText() sur un Blob, jamais envoyé vers un backend, de sorte que les exports RH, les livres comptables et les listes clients peuvent être restructurés sans quitter la session du navigateur.

  • Grammaire RFC 4180 : les champs contenant un délimiteur/CR/LF/" doivent être mis entre guillemets ; les guillemets internes sont doublés en "".
  • Automate à passage unique O(n) avec les états : field_start, in_unquoted, in_quoted, after_quote.
  • Le BOM UTF-8 (EF BB BF / U+FEFF) est supprimé en début de fichier pour garder les clés d'en-tête propres.
  • Les feuilles de calcul européennes utilisent souvent ; comme délimiteur car , est la décimale dans les paramètres de locale.
  • Le basculement première-ligne-comme-en-tête alterne la sortie entre Array<Record<string,string>> et Array<Array<string>>.
  • Toutes les valeurs de champs restent des chaînes ; les IDs à zéro non significatif comme 01234 survivent uniquement car aucune inférence de type n'est exécutée.
  • FileReader.readAsText() traite le Blob localement ; rien n'est envoyé — sûr pour les exports RH/comptabilité/préproduction.

Exemples

CSV de base avec ligne d'en-tête -> tableau JSON d'objets

Entrée CSV :
name,age,city
Alice,28,New York
Bob,35,London
Carol,42,Tokyo

Sortie JSON :
[
  { "name": "Alice", "age": "28", "city": "New York" },
  { "name": "Bob",   "age": "35", "city": "London"   },
  { "name": "Carol", "age": "42", "city": "Tokyo"    }
]

Champs entre guillemets contenant des virgules

Entrée CSV :
id,product,description
1,"Notebook, A5","Hard cover, 200 pages"
2,Pen,"Black ink, 0.5mm"

Sortie JSON :
[
  { "id": "1", "product": "Notebook, A5", "description": "Hard cover, 200 pages" },
  { "id": "2", "product": "Pen",          "description": "Black ink, 0.5mm" }
]

TSV (séparé par tabulations) sans en-tête

Entrée TSV (séparateur = Tab, en-tête désactivé) :
101	Alice	98.5
102	Bob	87.0
103	Carol	92.3

Sortie JSON :
[
  ["101", "Alice", "98.5"],
  ["102", "Bob",   "87.0"],
  ["103", "Carol", "92.3"]
]

Séparateur point-virgule (exports tableurs européens)

Entrée CSV (séparateur = ;) :
product;price_eur;stock
Keyboard;49,90;120
Mouse;19,90;345

Sortie JSON :
[
  { "product": "Keyboard", "price_eur": "49,90", "stock": "120" },
  { "product": "Mouse",    "price_eur": "19,90", "stock": "345" }
]
Note : les nombres restent en chaînes - convertissez dans votre code en aval.

FAQ

Quelles variantes de CSV sont prises en charge ?

Le CSV standard RFC 4180 : séparateur virgule, champs entre guillemets doubles, doublement des guillemets pour l'échappement. Le tabulé (TSV) et le CSV à séparateur point-virgule fonctionnent en changeant le séparateur. Les différentes fins de ligne (LF/CRLF/CR) sont gérées automatiquement.

Comment les en-têtes sont-ils gérés ?

Si vous activez « la première ligne est l'en-tête », le parser utilise chaque cellule d'en-tête comme clé JSON pour cette colonne, produisant un tableau d'objets. Sans en-têtes, le parser produit un tableau de tableaux. Les cellules d'en-tête vides reçoivent une clé numérique de remplacement.

Comment les types sont-ils inférés ?

Par défaut tout est une chaîne de caractères. Activez « typage automatique » pour tenter le parsing de nombres, booléens (true/false) et null. Les nombres avec des zéros en tête (00123, 0042) deviennent des chaînes pour ne pas perdre le préfixe : utile pour les ID et les codes postaux.

Que se passe-t-il si un champ contient une virgule ou un saut de ligne ?

Encadrez le champ par des guillemets doubles : "Smith, John" ou "ligne un\nligne deux". Les guillemets doubles intégrés sont doublés : "Il a dit ""salut""". Le parser gère tout cela ; si une ligne est cassée, la cause est généralement un déséquilibre des guillemets.

Comment la conversion est-elle effectuée : localement ou sur un serveur ?

Localement. Le parsing s'exécute dans votre navigateur en JavaScript. Le CSV collé ne quitte pas la page. Les fichiers volumineux peuvent ralentir le navigateur ; si un collage dépasse plusieurs dizaines de Mo, divisez-le avant traitement.

L'ordre des colonnes est-il préservé ?

Oui : chaque ligne devient un objet JSON dont l'ordre des clés correspond à l'ordre des en-têtes du CSV, et JSON.stringify dans les moteurs modernes préserve l'ordre d'insertion. Si votre outil en aval lit le JSON sans préserver l'ordre d'insertion, c'est sa propre limitation.

Comment gérer les dates ?

Les dates restent des chaînes. Le typage automatique n'analyse pas les formats de date arbitraires car il n'existe pas de standard non ambigu (1/2/2024 désigne le 2 janvier aux États-Unis et le 1er février en Europe). Convertissez les dates en ISO 8601 (AAAA-MM-JJ) avant l'import si vous voulez des objets Date natifs en aval.