Lettre d’amour au format CSV

• Des formats « supérieurs » censés remplacer le CSV sont souvent présentés, mais la plupart reposent sur des comparaisons biaisées qui passent à côté des véritables atouts du CSV
• Le but de cet article n’est pas de dire que le CSV est parfait, mais de mettre en lumière ses avantages sous-estimés
• À contre-courant de l’air du temps qui consiste à détester le CSV pour paraître plus malin, il rappelle sa vraie valeur

1. Le CSV est extrêmement simple

• La définition du CSV est littéralement dans son nom : des « valeurs séparées par des virgules »
• Les lignes sont séparées par des sauts de ligne, les colonnes par des virgules
• Si une valeur contient une virgule ou un saut de ligne, elle est entourée de guillemets, et les guillemets eux-mêmes sont représentés par des doubles guillemets
• Pas besoin de spécification complexe : n’importe qui peut le comprendre et l’utiliser intuitivement
• Cela dit, pour un parsing correct, il reste préférable d’utiliser un parseur CSV dédié

2. Le CSV est une idée collective

• Il n’a pas de propriétaire, il n’est pas privatisé
• La RFC 4180 existe, mais la plupart la considèrent surtout comme une référence
• C’est un format libre fondé sur des règles communes partagées implicitement par les développeurs du monde entier

3. Le CSV est du texte

• Comme JSON, YAML ou XML, c’est un format texte brut lisible par les humains
• Il peut être ouvert avec n’importe quel éditeur de texte, et son contenu peut être consulté sans outil particulier
• Le choix de l’encodage est lui aussi libre

4. Le CSV est optimisé pour le streaming

• Comme il se lit ligne par ligne, sa consommation mémoire est très faible
• Avec un code simple, on peut traiter plusieurs gigaoctets de données avec seulement quelques Ko de mémoire
• Les formats orientés colonnes comme Parquet se prêtent mal au streaming et nécessitent un buffering complexe
• Son inconvénient est qu’il faut lire toute la ligne, même si l’on ne veut consulter qu’une colonne précise

5. Le CSV se prête facilement à l’ajout en fin de fichier

• Il est très simple d’ouvrir un fichier en mode append(a+) pour ajouter de nouvelles lignes à la fin
• À l’inverse, les formats orientés colonnes comme Parquet rendent l’ajout de lignes inefficace et complexe

6. Le CSV prend en charge le typage dynamique

• Comme il n’impose pas de types fixes, les données peuvent être interprétées avec souplesse
• Exemple : JavaScript ne sait pas représenter correctement les entiers 64 bits, alors que le CSV permet de les utiliser sans cette contrainte
• Cela apporte des avantages en matière de compatibilité entre langages et de flexibilité
• Mais une mauvaise interprétation peut provoquer des erreurs → prudence à l’usage
• Lorsqu’un haut niveau de performance est requis, il est aussi possible de traiter directement les données au niveau binaire sans décoder le texte

7. Le CSV est concis

• Comme l’en-tête n’apparaît qu’au début du fichier, il y a très peu de répétition structurelle
• JSON et XML ont un surcoût important à cause de la répétition des clés
• La représentation des chaînes est déjà concise, et le surcoût propre au format (virgules, guillemets, etc.) reste très faible

8. Un CSV renversé reste un CSV valide

• Même renversé octet par octet, un CSV reste un CSV valide
• Cela est rendu possible par le mécanisme d’échappement des doubles guillemets, qui est une forme d’échappement palindromique
• Cette propriété permet de lire très efficacement la fin d’un fichier CSV
• Exemple : pour reprendre un processus interrompu, on peut relire uniquement les dernières lignes du fichier pour redémarrer

9. Excel déteste le CSV

• Si Excel trouve ce format peu pratique, c’est peut-être au contraire le signe que vous êtes sur la bonne voie

[ng0301]

Le plus simple, c’est le mieux !

[ethanhur]

Le pire est mieux !

[GN⁺]

Avis Hacker News

• J’aime les fichiers CSV et INI parce qu’ils sont simples, basés sur du texte, sans types encodés dans le format, et constitués uniquement de chaînes de caractères

  • Ils ont l’inconvénient de ne pas avoir de standard officiel, mais ils remplissent bien leur rôle
  • J’ai mis de côté les critiques d’INI au sujet de TOML
  • Je pense que la première ligne de la critique de TOML s’applique aussi au CSV : c’est une fédération de plusieurs dialectes

• Le CSV est élégant, mais il a un défaut fatal : les guillemets ont un effet « non local »

  • Par exemple, un seul guillemet à l’octet 1 peut changer le sens d’une virgule à l’octet 1000000
  • Cela entraîne deux conséquences gênantes
    • Il est difficile de paralléliser le traitement du CSV
    • La corruption des données a un fort impact sur la lisibilité du fichier (un guillemet manquant ou ajouté peut tout casser)
  • C’est pourquoi, de nos jours, pour la sérialisation simple de données tabulaires, je préfère un échappement simple au CSV

• Le meilleur aspect du CSV, c’est que n’importe qui peut écrire un parseur en 30 minutes

  • On peut facilement importer des données du début des années 1990 dans un service web moderne
  • Le pire aspect du CSV, c’est que n’importe qui peut écrire un parseur en 30 minutes
  • Cela favorise les implémentations incorrectes, les mauvaises données et des comportements indéfinis bizarres
  • JSON et YAML ont des problèmes similaires
  • XML est un peu disgracieux, mais semble être le plus robuste

• Quelqu’un qui aime le CSV n’a probablement jamais reçu la demande de gérer la prévention de l’injection CSV dans un environnement d’entreprise

  • Il existe peu de bonnes ressources sur le web
  • La meilleure ressource est <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">ici</a>

• J’aime le CSV pour plusieurs raisons

  • On peut écrire un programme en C et lui faire produire directement toutes sortes de choses en CSV
  • On peut écrire un middleware simple pour convertir facilement vers du CSV depuis presque n’importe quelle base de données ou « chose » courante
  • On peut mettre le CSV dans Excel et faire tout ce qu’on veut
  • J’aime aussi les fichiers ini. On peut les modifier directement dans le Bloc-notes
  • Cependant, j’aimerais qu’il existe un schéma/une structure générale

• Je développe actuellement une solution basée sur Raspberry Pi

  • La première implémentation utilisait une base de données SQLite, mais elle a été corrompue après quelques jours de cycles d’alimentation
  • J’ai regardé du côté des fichiers Parquet, mais ils ne sont pas adaptés aux opérations append-only
  • J’ai implémenté une méthode qui enregistre les événements dans un fichier IPC et les « flush » périodiquement dans un fichier Parquet
  • Cela fonctionne et c’est efficace, mais ce n’est pas facile à implémenter correctement
  • Pour le développeur moyen, le CSV (ou JSONL) reste ce qu’il y a de mieux

• Le côté peu amusant du CSV, c’est que les parseurs et sérialiseurs écrits à la va-vite répètent les erreurs classiques de mauvaise gestion des guillemets

  • Je me suis longtemps méfié du CSV, mais cela a changé quand j’ai appris Python et utilisé son excellent module standard csv

• Si c’était vraiment une lettre d’amour, elle aurait été écrite au format CSV

• Les arguments contre JSON ne sont pas très convaincants

  • Ajouter un nom à chaque champ n’est pas nécessairement un problème
  • Si l’on compare CSV et JSON, JSON est un peu plus volumineux, mais les accolades expriment la capacité d’être simple ou complexe
  • Le CSV est simple, donc on n’utilise souvent pas de bibliothèque de parsing/encodage
  • Un parseur JSON produit toujours les valeurs attendues, et le langage utilise probablement un parseur SIMD très efficace
  • Il y a aussi le problème de la standardisation. Est-ce que le fichier CSV utilise des virgules, des espaces, des points-virgules, des barres verticales, etc. ? Est-ce qu’il utilise CR, LF, CRLF ? Est-ce qu’on peut échapper les guillemets ?
  • JSON n’a pas ces problèmes
  • JSON est typé. Avoir 6 types vaut mieux que de ne pas en avoir
  • JSON n’est pas parfait, mais il est généralement meilleur que le CSV

• En tant qu’amateur de formats modernes, dans le doute j’utilise CSV ou JSONL

  • Comme ce sont principalement des fichiers en texte brut, on peut facilement les parcourir avec grep et les traiter en streaming
  • La plupart des fonctionnalités listées dans le document sont aussi partagées par JSONL
  • Ils se compressent bien avec gzip ou zstd
  • La compression retire une partie des avantages du texte brut, mais ripgrep peut aussi rechercher dans des fichiers compressés
  • Un autre avantage de JSONL est qu’il peut facilement être découpé en fichiers plus petits