CSV vers JSON
Dernière mise à jour : 1 octobre 2026
Relisez un tableau CSV comme un tableau d'objets JSON. La ligne d'en-tête donne les clés, les règles de guillemets de la RFC 4180 sont comprises à la lecture et la détection des types, vous décidez de l'activer. Tout se passe dans votre navigateur : le tableau ne quitte pas la machine.
Ce que fait la conversion
Le CSV porte les noms de colonnes sur la première ligne, donc la conversion est un mappage direct : les cellules de l'en-tête deviennent les noms de propriété et chaque ligne suivante devient un objet du tableau. Le tableau
id,name
1,Ada
2,Gracedevient [{"id":"1","name":"Ada"},{"id":"2","name":"Grace"}]. Notez que les valeurs sont des chaînes : c'est le comportement par défaut, et la raison est expliquée dans la section suivante.
La ligne d'en-tête est le schéma
La première ligne est traitée comme un en-tête, pas comme des données. Deux cas limites sont traités plutôt que laissés à la surprise :
- Noms en double : un en-tête répété devient unique, donc
a,adevientaeta_2. Sans cela, la deuxième colonne écraserait la première en silence. - Noms vides : une cellule d'en-tête vide est nommée par sa position,
column 1,column 2, et ainsi de suite, pour qu'aucune clé ne soit une chaîne vide.
La détection des types est désactivée par défaut, volontairement
Le CSV n'a pas de types. Chaque cellule est du texte, et le fichier ne peut pas distinguer un nombre d'un code qui se trouve être fait de chiffres. C'est pourquoi la détection est facultative : désactivée, toutes les valeurs restent des chaînes, ce qui est la lecture fidèle du fichier.
Activée, elle ne convertit que ce qui est sans ambiguïté. Une valeur est traitée comme un nombre quand elle pourrait s'écrire comme un nombre JSON — un signe moins facultatif, des chiffres, une partie décimale facultative et un exposant facultatif —, et true, false et null sont reconnus comme tels. Le point crucial est qu'une valeur à zéro de tête n'est pas convertie, car 007 et 02139 sont presque toujours des identifiants : codes postaux, téléphones, numéros de compte, références produit. Un « tout convertir en nombre » à l'aveugle transformerait 007 en 7 et corromprait les données ; cette règle ne le fait pas.
Champs entre guillemets, virgules internes et sauts de ligne
La lecture suit la RFC 4180, la même règle que celle avec laquelle écrit la page JSON vers CSV. Un champ entre guillemets doubles peut contenir le délimiteur, un saut de ligne ou une paire de guillemets doubles qui redevient un seul. Ainsi, "Ada, Countess" est une valeur unique contenant une virgule, et une valeur sur deux lignes physiques reste une seule cellule. Les fins de ligne CRLF et LF sont acceptées, et une marque d'ordre des octets UTF-8 initiale——l'invisible U+FEFF qu'ajoutent Excel et certains exportateurs——est retirée, pour que le premier nom de colonne ne ressorte pas comme id.
Lignes de longueur irrégulière
Les fichiers modifiés à la main sont rarement un rectangle bien net. Une ligne avec moins de champs que l'en-tête est complétée par des valeurs vides et une ligne avec plus est tronquée, de sorte que tous les objets finissent avec les mêmes clés. L'alternative — refuser tout le fichier — est moins utile que de renvoyer les lignes bien formées, mais elle implique que les valeurs manquantes sont réellement absentes.
Questions fréquentes
Comment le CSV se mappe-t-il sur des objets JSON ?
La première ligne est lue comme en-tête et ses cellules deviennent les noms de propriété ; chaque ligne suivante devient un objet du tableau, avec ces noms pour clés. Un CSV dont l'en-tête est id,name et qui contient une ligne 1,Ada produit [{ "id": "1", "name": "Ada" }].
Pourquoi mes nombres et booléens ressortent-ils en chaînes ?
La détection des types est désactivée par défaut, et c'est volontaire. Le CSV n'a pas de types, donc le convertisseur ne peut pas savoir si 007 est le nombre sept ou le code zéro-zéro-sept ; une mauvaise supposition corrompt silencieusement des identifiants comme les codes postaux, les numéros de téléphone et les numéros de compte. Activez-la quand vous savez qu'une colonne est numérique, et même alors une valeur à zéro de tête reste une chaîne.
Qu'est-ce qui compte exactement comme un nombre quand la détection est active ?
Seulement le texte qui pourrait s'écrire comme un nombre JSON : un signe moins facultatif, des chiffres sans zéro de tête sauf si la valeur est exactement 0, une partie décimale facultative et un exposant facultatif. true, false et null sont aussi reconnus. Tout le reste, y compris 007 et 1,234, reste une chaîne.
Comment sont lus les champs entre guillemets, les virgules internes et les sauts de ligne ?
L'analyse suit la RFC 4180 : un champ entre guillemets doubles peut contenir le délimiteur, un saut de ligne ou un guillemet double doublé, qui redevient un seul guillemet. Ainsi, une cellule contenant Ada, Countess s'écrit "Ada, Countess" et une valeur sur deux lignes reste un seul champ. Les fins de ligne CRLF et LF sont acceptées.
Mon fichier a un BOM UTF-8 ; le premier nom de colonne va-t-il casser ?
Non. La marque d'ordre des octets initiale——l'invisible U+FEFF que certains outils, Excel compris, placent au début d'un CSV——est retirée avant l'analyse, sinon le premier en-tête serait lu comme id. Ici, il est lu comme id.
Que deviennent les lignes qui ne correspondent pas à l'en-tête ?
Une ligne avec moins de champs que l'en-tête est complétée par des valeurs vides, et une ligne avec plus est tronquée, de sorte que tous les objets ont les mêmes clés. Les lignes irrégulières sont courantes dans les fichiers modifiés à la main et sont tolérées plutôt que refusées, mais les données manquantes sont réellement absentes de la sortie.
Vous voulez le sens inverse ? JSON vers CSV écrit un tableau d'objets sous forme de tableau. Une erreur ? Écrivez-nous.