Point-virgule, tabulation, barre verticale : choisir un délimiteur qui survit au trajet

Un caractère ne peut pas faire deux métiers

Tout le sujet se ramène à une collision. Un fichier CSV a besoin d'un caractère pour marquer la frontière entre les champs. Un nombre écrit a besoin d'un caractère pour marquer la frontière entre la partie entière et la fraction. Dans les conventions anglophones, ce sont la virgule et le point, et il n'y a pas de conflit. Dans les conventions française, allemande, espagnole, italienne et portugaise, la marque décimale est la virgule, et le conflit est total : le caractère qui sépare douze de cinquante dans un prix est le même que celui qui séparerait le prix de la colonne suivante.

Il n'y a que deux issues à une telle collision, et l'industrie a choisi la seconde. La première consiste à garder la virgule comme séparateur de champs et à citer toute valeur qui en contient une, ce qui est licite et que le format prévoit explicitement. La seconde consiste à changer de séparateur. Les systèmes d'exploitation de ces régions portent un réglage de séparateur de liste à côté du séparateur décimal, et il vaut le point-virgule précisément pour que les deux ne se rencontrent jamais ; les tableurs le lisent quand ils enregistrent et ouvrent un CSV. Résultat : un fichier exporté par un collègue à Lyon et un fichier exporté par un collègue à Chicago sont deux formats différents portant la même extension, et chacun s'ouvre en une colonne de texte sur la machine de l'autre.

Le même export, cinq écritures, compté

Voici un petit export français, quatre colonnes : Produit, Prix, Remise, Ville. Deux lignes : Café à 12,50 avec 5,0% de remise à Lyon, Rhône, et Thé à 8,90 avec 0,0% à Paris. Il contient tout ce qui rend cette question réelle — des virgules décimales, un pourcentage écrit avec une virgule, et un nom de ville qui contient légitimement une virgule et une espace.

Passe-le cinq fois dans le convertisseur de délimiteur et compte les cellules qui ressortent entre guillemets. Avec des points-virgules, des tabulations ou des barres verticales : zéro. Pas une cellule du fichier n'a besoin d'être protégée, car aucune valeur ne contient l'un de ces trois caractères. Avec des virgules : cinq. Le prix du Café, sa remise, sa ville, le prix du Thé et sa remise doivent tous être cités, et le fichier passe de net à encombré. Avec des espaces : une cellule citée, la ville, et le reste du fichier devient un piège pour tout ce qui traite une suite de blancs comme une seule frontière.

Observe ce que le convertisseur fait aux guillemets, car c'est là que les scripts maison se trompent. En passant des points-virgules aux virgules, il ajoute des guillemets autour de 12,50 et de 5,0% — des valeurs parfaitement sûres avant, qui ne le sont plus. En passant des virgules aux points-virgules, il retire les guillemets autour de Lyon, Rhône, car une virgule dans un champ n'est plus une frontière et la protection devient du bruit. Un script qui échange les caractères par un chercher-remplacer ne fait ni l'un ni l'autre : il réécrit la virgule de Lyon, Rhône en point-virgule, coupant la ville en deux, et laisse 12,50 sans guillemets, si bien que le lecteur suivant trouve une colonne de trop. Analyser puis réémettre est la seule implémentation correcte, et le signe visible qu'un outil le fait, c'est que les guillemets changent quand le délimiteur change.

La tabulation : la plus sûre sur le papier, fragile en transit

L'argument en faveur de la tabulation est qu'aucun format de nombre n'en contient, quelle que soit la locale. Aucune adresse postale, aucun nom de produit ni de personne d'usage courant non plus : un fichier à tabulations de vraies données métier ne demande généralement aucun guillemet — ce que le décompte en cinq écritures ci-dessus a précisément montré. C'est aussi le format qu'un tableur dépose lui-même dans le presse-papiers : copie un bloc de cellules et ce qui atterrit là en texte brut est séparé par des tabulations, raison pour laquelle coller une sélection dans un éditeur de texte te donne un TSV tout fait. Les outils en ligne de commande penchent du même côté, cut au premier chef — il découpe sur la tabulation sauf indication contraire. Sur les mérites du caractère, elle l'emporte.

Elle perd sur le transport. Une tabulation est un caractère de contrôle qui a un rôle dans chaque interface de saisie qu'elle traverse, et ce rôle n'est pas d'être une donnée. Frappée dans un champ de navigateur, elle déplace le focus vers le contrôle suivant. Collée dans un message de messagerie ou un suivi de tickets, elle est souvent rendue en suite d'espaces et parfois convertie en espaces. Beaucoup d'éditeurs sont réglés pour transformer une tabulation frappée en espaces : quelqu'un qui ouvre le fichier pour corriger une cellule peut détruire la structure de chaque ligne qu'il touche sans rien voir changer à l'écran. Et comme une tabulation ressemble à une plage vide, une tabulation devenue des espaces reste invisible jusqu'à ce qu'un analyseur t'annonce que la ligne n'a qu'un champ.

Un détail sur la façon dont ce convertisseur écrit une sortie à tabulations mérite d'être connu, car il surprend qui attend un TSV brut. Il applique les règles de guillemets du CSV au format à tabulations : une cellule contenant une tabulation, un saut de ligne ou un guillemet double est enveloppée de guillemets et ses guillemets internes sont doublés. Ainsi une cellule portant say "hi" ressort en "say ""hi""" alors qu'elle ne contient aucune tabulation. Les tableurs lisent cela correctement. Les outils qui découpent chaque ligne sur la tabulation et prennent les morceaux au pied de la lettre, non — ils voient les guillemets comme faisant partie de la valeur. Si ton consommateur est un simple découpeur de champs et non un lecteur CSV, vérifie ce qu'il fait d'une cellule citée avant de te fier au fichier.

La ligne sep=, et ce que ce convertisseur réussit par accident

Excel accepte une première ligne de la forme sep=; et la lit comme une instruction : le caractère après le signe égal est le séparateur de champs de ce fichier, quoi que dise le réglage de séparateur de liste de la machine. C'est le seul mécanisme d'usage courant qui permette à un fichier CSV de déclarer son propre délimiteur, et il ne fait partie ni de la RFC 4180 ni de l'enregistrement du type de média text/csv : c'est une convention d'éditeur qui s'est répandue parce qu'elle règle un vrai problème pour le prix d'une ligne.

C'est là que le bât blesse. Rien qui n'ait appris la convention ne la reconnaîtra, et le fichier n'a aucun moyen de signaler que cette ligne est une métadonnée et non une donnée. Un lecteur CSV générique la traite comme le premier enregistrement, et si ce lecteur utilise aussi la première ligne comme en-tête, tes noms de colonnes deviennent sep= et une série de repères positionnels, tandis que ta vraie ligne d'en-tête glisse dans les données. C'est exactement ce qui arrive si tu donnes un tel fichier à un convertisseur CSV vers JSON sans supprimer la ligne d'abord.

Le convertisseur de délimiteur s'en sort correctement, et la raison mérite d'être racontée car personne ne l'a conçue. L'outil ignore tout de la convention : il analyse sep=; comme un enregistrement ordinaire, ce qui, avec le point-virgule pour délimiteur, donne deux cellules — sep= et une vide — puis réécrit cet enregistrement avec le nouveau délimiteur. Convertir en virgules produit sep=, convertir en tabulations produit sep= suivi d'une tabulation, et convertir en barres produit sep=|. Dans tous les sens, l'indication reste vraie pour le fichier qu'elle étiquette. Le même accident aide la détection : la ligne d'indication contient exactement une occurrence du caractère qu'elle nomme et aucune des trois autres candidates, et seuls les caractères vus sur le premier enregistrement entrent en ligne de compte — un fichier portant l'indication n'offre donc qu'un seul candidat, celui-là même que la ligne nomme.

La détection automatique pèse cinq enregistrements, et la régularité l'emporte sur la fréquence

La détection compte ici la virgule, le point-virgule, la tabulation et la barre verticale, en ignorant ce qui est entre guillemets, et elle le fait enregistrement par enregistrement — cinq au plus, jamais le fichier entier. Un candidat dont le compte se répète à l'identique sur chaque enregistrement lu reçoit un gros bonus : la régularité pèse donc plus lourd que la simple fréquence sur la ligne d'en-tête. Donne-lui un en-tête a,b,c|d au-dessus des lignes 1|2 et 3|4 et la réponse est la barre verticale, alors même que cet en-tête porte deux virgules contre une seule barre : le compte des barres se répète sur chaque enregistrement, tandis que celui des virgules retombe à zéro dès le deuxième. La régularité est le meilleur signal, car une vraie frontière de colonne apparaît le même nombre de fois dans chaque ligne d'un fichier bien formé, tandis qu'un caractère qui se trouve simplement dans un titre apparaît là où il se trouve.

Deux limites survivent à cette règle, et toutes deux méritent d'être connues avant de laisser le réglage sur automatique. La première : seuls les caractères présents sur le premier enregistrement sont candidats. Un en-tête a,b au-dessus d'une ligne 1;2;3;4 renvoie toujours la virgule, car le point-virgule n'apparaît jamais sur la ligne qui dresse la liste — les lignes du dessous ne peuvent pas promouvoir un caractère que l'en-tête n'a pas montré. La seconde : cinq enregistrements font une fenêtre, pas une preuve. Donne-lui un en-tête a,b,c|d au-dessus de quatre lignes de la forme 1|2 et il répond barre verticale ; ajoute un sixième enregistrement 9|10|11, qui casse le motif, et la réponse reste la barre, car cet enregistrement n'est jamais lu. Remonte cette même ligne en cinquième position et la réponse bascule sur la virgule. Le symptôme d'une mauvaise devinette est le même dans les deux cas : les lignes reviennent en une seule cellule large, le vrai séparateur encore dedans. Le remède tient en un clic : fixe explicitement le délimiteur d'origine au lieu de le laisser en automatique. Un fichier sans aucun délimiteur retombe sur la virgule, ce qui ne change rien et constitue le bon défaut.

Deux dernières remarques pratiques. L'option espace existe dans l'outil et ne devrait presque jamais être choisie : tout champ contenant une espace est cité, ce qui, sur de vraies données, en concerne la plupart, et aucun lecteur ne traite une suite d'espaces comme tu l'attends. Et la conversion est réversible dans les deux sens sur une entrée bien formée : prends un fichier à virgules dont la ville est citée Paris, France, convertis-le en points-virgules puis reviens, et tu retrouves le fichier d'origine caractère pour caractère, parce que les guillemets sont recalculés à chaque passage au lieu d'être transportés.

Questions fréquentes

Mon collègue ouvre mon CSV et tout est dans la colonne A. Que dois-je envoyer à la place ?

Sa machine attend un séparateur de champs différent du vôtre, et neuf fois sur dix cela veut dire que tu as envoyé des virgules à quelqu'un dont le séparateur de liste est le point-virgule. Convertis le fichier en points-virgules et renvoie-le. Si tu ignores ce qu'il lui faut, ou si le fichier part à plusieurs personnes en même temps, deux options robustes : ajouter une première ligne sep= suivie de ton délimiteur, ce qu'Excel honore et qui rend le fichier autodescriptif, ou envoyer un vrai fichier tableur plutôt qu'un CSV, puisque ce format consigne sa propre structure et n'a aucun séparateur à deviner. Attention : la ligne sep= n'aide qu'un lecteur qui connaît la convention — un script qui lit le fichier la prendra pour ta ligne d'en-tête.

Un fichier à virgules avec des nombres cités est-il quand même correct ?

Oui, totalement. Citer un champ qui contient le délimiteur est précisément la raison d'être du mécanisme, et un fichier correctement cité s'analyse correctement partout. Les objections sont pratiques et non formelles. Il est bien plus difficile à lire à l'œil : quelqu'un qui parcourt le fichier pour y trouver une erreur doit se frayer un chemin entre les guillemets. Il est plus volumineux, de deux caractères par valeur citée plus un guillemet doublé pour chaque guillemet interne. Et il est fragile entre les mains du prochain qui l'éditera : une personne qui ouvre le fichier dans un éditeur et retire ce qui lui semble un guillemet parasite autour d'un prix vient de corrompre toutes les lignes situées sous le décalage de colonnes. Choisir un délimiteur absent des données supprime tout besoin de guillemets, et un fichier qui n'a jamais besoin d'être cité ne peut pas être cassé par quelqu'un qui le range.

Faut-il choisir la tabulation ou la barre verticale quand on maîtrise les deux bouts ?

La tabulation si le fichier ne circule qu'entre programmes, la barre verticale si un humain doit le regarder ou le déplacer. Les deux sont également sûres vis-à-vis des données — ni l'une ni l'autre n'apparaît dans un nombre, une adresse ou un nom d'usage courant — la différence tient donc entièrement à la manipulation. La tabulation gagne sur l'outillage : les tableurs et les utilitaires en ligne de commande ouvrent un fichier à tabulations sans boîte de dialogue d'import. La barre gagne sur la visibilité et la survie : elle se voit dans un terminal, elle est sans ambiguïté sur une capture d'écran, et elle traverse sans dommage un message de messagerie, un champ de formulaire et un éditeur de texte, ce qui n'est vrai pour aucun de ces trois cas avec une tabulation. Si le fichier doit être collé quelque part à un moment de sa vie, prends la barre verticale.

Pourquoi le convertisseur ajoute-t-il des guillemets quand je passe des points-virgules aux virgules ?

Parce que ces cellules contiennent une virgule et que la virgule vient de devenir une frontière. Un prix écrit 12,50 était une valeur ordinaire dans un fichier à points-virgules et serait lu comme deux colonnes dans un fichier à virgules : il faut donc l'envelopper. Il en va de même d'un pourcentage écrit 5,0% et de toute adresse contenant une virgule. Ce n'est pas de la prudence de la part du convertisseur : c'est le minimum nécessaire pour que le fichier continue de signifier ce qu'il signifiait. L'opération inverse retire des guillemets pour la même raison : reconvertis en points-virgules et les guillemets autour d'une valeur dont le seul caractère spécial était une virgule disparaissent, ce caractère ne séparant plus rien. Si tu préfères ne pas traîner ces guillemets, c'est justement l'argument pour convertir en tabulations ou en barres verticales, où rien dans les données n'a besoin d'être protégé.

Le séparateur décimal lui-même est-il converti ?

Non, et il ne devrait pas l'être. Le convertisseur de délimiteur change la structure du fichier et jamais le contenu d'une cellule : un prix écrit 12,50 reste 12,50 quel que soit le délimiteur choisi, et un prix écrit 12.50 reste 12.50. Convertir aussi les nombres serait une opération différente et bien plus dangereuse, car il faudrait décider, cellule par cellule, si une virgule est une marque décimale ou un séparateur de milliers — et 1,500 vaut soit un et demi, soit mille cinq cents selon la réponse. Si tu dois reformater les nombres pour un lecteur d'une autre convention, fais-en une étape séparée et délibérée où tu vois quelles colonnes sont touchées, et vérifie une valeur dont tu connais la réponse avant d'accepter le résultat.