Pourquoi les exports CSV de tableurs se cassent lors de la conversion

Un fichier CSV a l'air aussi simple qu'un format de données puisse l'être — découper chaque ligne aux virgules, traiter la première ligne comme des en-têtes de colonne, et voilà — et cette simplicité apparente est exactement ce qui rend le format si facile à mal gérer dès que des données réelles y apparaissent. L'approche naïve du découpage par virgule fonctionne parfaitement sur un exemple jouet et se casse dès la première ligne où une vraie valeur de donnée contient sa propre virgule, ce qui est un cas courant plutôt qu'un cas limite : une adresse comme « 12 rue de la Paix, 4e étage », un nom d'entreprise comme « Dupont, Martin & Associés », ou une description de produit qui contient une énumération sont toutes des valeurs parfaitement ordinaires qui contiennent légitimement le caractère exact qu'un analyseur naïf utilise comme séparateur de champs.

La spécification CSV résout le problème de la virgule intégrée en permettant qu'un champ soit encadré de guillemets doubles, à l'intérieur desquels les virgules, et même les sauts de ligne, sont de simples données littérales plutôt que de la structure — un champ correctement mis entre guillemets comme `"Dupont, Martin & Associés"` est compris comme une seule valeur contenant une virgule, et non comme deux valeurs séparées à cette virgule. Un analyseur qui découpe naïvement à chaque virgule sans suivre s'il se trouve actuellement à l'intérieur d'un champ entre guillemets n'a aucun moyen de faire cette distinction, et scinde silencieusement ce seul nom d'entreprise en deux colonnes parasites — généralement sans lever la moindre erreur, ce qui est justement ce qui rend cette catégorie de bug dangereuse : la conversion semble réussie, et la corruption n'est découverte que plus tard, souvent bien après que ces données mal formées ont déjà servi à quelque chose.

Une cellule de tableur contenant une note ou une adresse sur plusieurs lignes est parfaitement normale, et lorsque cette cellule est exportée en CSV, la spécification la traite de la même façon qu'une virgule intégrée : tout le champ est encadré de guillemets, et le saut de ligne qu'il contient fait réellement partie des données du champ, et non le signal du début d'une nouvelle ligne. Un analyseur qui suppose que chaque saut de ligne du fichier marque le début d'un nouvel enregistrement, sans suivre s'il se trouve actuellement à l'intérieur d'un champ entre guillemets encore ouvert, scinde cette unique cellule multiligne en ce qui ressemble à plusieurs lignes distinctes — corrompant silencieusement la structure en lignes de tout ce qui suit dans le fichier, puisque chaque ligne suivante se retrouve désormais décalée du nombre de lignes parasites introduites par la cellule cassée.

Chaque valeur d'un fichier CSV brut est stockée sous forme de texte simple, sans aucun moyen intégré d'indiquer si une valeur donnée est « vraiment » un nombre, un booléen, ou simplement une chaîne qui ressemble à un nombre — ce qui devient un vrai problème dès qu'un convertisseur essaie de rendre service en déduisant automatiquement les types. Un code postal comme « 007 » ou un identifiant comme « 042 » a un zéro non significatif qui a un sens précis — c'est un identifiant à largeur fixe, et « 7 » et « 007 » sont des identifiants différents bien qu'ils représentent le même nombre — mais un convertisseur qui analyse avec empressement les chaînes d'apparence numérique en véritables nombres supprime silencieusement ce zéro non significatif, puisque le nombre 7 n'a aucune notion du nombre de zéros qui le précédaient auparavant. Un numéro de téléphone comme « 01 55 55 01 00 » a l'air partiellement numérique mais ne constitue absolument pas une donnée arithmétique, et le convertir en nombre produit quelque chose de réellement absurde. Le choix sûr et correct par défaut est de laisser les valeurs ambiguës en texte, sauf si une valeur est sans équivoque et incontestablement numérique, car se tromper ici corrompt les données silencieusement plutôt que de déclencher une erreur visible et détectable.

Au-delà des véritables cas limites propres au format CSV lui-même, Microsoft Excel introduit une friction supplémentaire qui n'a rien à voir avec la spécification CSV : de nombreuses configurations régionales d'Excel, en France et ailleurs en Europe, utilisent par défaut le point-virgule plutôt que la virgule comme séparateur de champs, puisque la virgule sert déjà de séparateur décimal dans ces paramètres régionaux, ce qui signifie qu'un fichier CSV exporté depuis l'une de ces configurations Excel ne s'analysera pas correctement avec un analyseur fondé sur la virgule. Excel a également l'habitude bien connue de reformater automatiquement les valeurs qu'il croit reconnaître à l'ouverture d'un fichier CSV pour affichage — transformant par exemple un long identifiant numérique en notation scientifique — ce qui relève d'une mauvaise interprétation par Excel au moment de l'affichage plutôt que d'un défaut du fichier CSV sous-jacent, mais qui est régulièrement confondu avec une véritable corruption de données lors de l'export lui-même.