CSV vers JSON

Le CSV paraît trivial à analyser — diviser chaque ligne par des virgules, traiter la première ligne comme en-têtes — jusqu'à ce qu'une valeur dans les vraies données contienne sa propre virgule, ce qui arrive constamment avec de vrais exports de tableur : une adresse comme "123 Rue Principale, Apt 4", un nom d'entreprise comme "Dupont, Martin & Cie", ou une description de produit contenant une liste. La spécification CSV, formalisée en RFC 4180, gère cela en permettant à un champ d'être enveloppé dans des guillemets doubles, à l'intérieur desquels virgules, sauts de ligne et même caractères guillemet littéraux (échappés en les doublant) sont simplement des données plutôt que de la structure. Un analyseur qui divise naïvement par chaque virgule, ignorant complètement les guillemets, corrompt exactement ces lignes — divisant "Dupont, Martin & Cie" en deux colonnes séparées — et le fait généralement silencieusement, sans aucune erreur signalant que quelque chose s'est mal passé, ce qui rend cette erreur dangereuse plutôt que simplement gênante.

L'analyse correctement consciente des guillemets suit si le lecteur est actuellement à l'intérieur d'un champ entre guillemets et ignore les caractères délimiteurs et de saut de ligne jusqu'à atteindre le guillemet de fermeture, ce qui est le seul moyen de reconstruire correctement des champs contenant légitimement les caractères qui seraient sinon confondus avec de la structure.

Chaque valeur dans un fichier CSV brut est du texte, le CSV n'ayant aucune notion native de nombre, booléen ou nul — une cellule contenant `42` et une cellule contenant `bonjour` sont stockées de façon identique comme caractères. L'inférence de type est le processus de deviner quelles chaînes étaient « réellement » destinées à être des nombres, des valeurs vrai/faux ou des nuls, et de les convertir en conséquence pour que le JSON résultant ait de vraies valeurs typées plutôt que tout entre guillemets comme une chaîne.

Cependant, la déduction doit être prudente, car pas mal de valeurs qui paraissent numériques ne sont pas du tout destinées à être traitées comme des nombres. Un zéro initial — `007`, `042` — signale généralement un identifiant ou un code avec remplissage où le zéro de tête est significatif et serait silencieusement détruit en convertissant en nombre, `7` et `007` étant le même nombre mais des identifiants très différents. Un numéro de téléphone comme `+44 20 7946 0958` paraît partiellement numérique mais n'est pas une donnée arithmétique. Les valeurs au-delà de la plage entière sûre de JavaScript perdent en précision si converties en nombre. Cet outil laisse tout cela en chaînes spécifiquement car mal deviner ici signifie corrompre silencieusement des données d'une façon facile à manquer bien après coup.

Un objet JSON ne peut pas avoir deux clés du même nom — la seconde trouvée écrase simplement la première, sacrifiant silencieusement la valeur de toute une colonne sans aucune erreur levée nulle part. Les exports de tableur produisent des en-têtes en double plus souvent qu'il n'y paraît probable : un rapport avec deux colonnes « Total » à des portées différentes, ou un export fusionné de deux sources qui utilisent toutes deux « Nom ». Détecter les doublons et renommer la seconde occurrence en `name_2` préserve les données de chaque colonne plutôt que de perdre silencieusement l'une d'entre elles selon celle qui apparaît en premier dans l'objet de ligne. Les en-têtes vides reçoivent le même traitement pour la même raison, le JSON n'ayant aucun moyen de représenter une clé qui est simplement une chaîne vide comme un champ significatif et adressable.