Convertir CSV en TSV

Une bonne part des fichiers qui arrivent avec une extension .csv sont séparés par des points-virgules. Excel les écrit ainsi dans toutes les locales où la virgule est le séparateur décimal, ce qui est la majeure partie de l’Europe continentale et une bonne part de l’Amérique du Sud, parce qu’un fichier utilisant la virgule pour les deux usages serait illisible. Des exports délimités par pipe existent aussi, principalement issus de systèmes bancaires ou télécoms plus anciens.

Le parseur ici détermine de quel caractère il s’agit en regardant le fichier plutôt que son nom, donc un export à point-virgule se convertit sans qu’on lui dise rien. Là où cela échoue, c’est un fichier à une seule colonne : sans séparateur présent nulle part, chaque candidat est également absent et la détection n’a rien sur quoi s’appuyer. C’est à cela que sert le contrôle de séparateur sur cette page, et c’est la seule situation où vous en avez besoin.

Une virgule est un mauvais délimiteur pour la raison précise qu’elle apparaît constamment dans les données réelles. Les adresses ont des virgules. Les descriptions produit ont des virgules. Les noms de société finissant par «, Inc. » ont des virgules. Chacun de ces champs doit être entouré de guillemets, et chaque consommateur du fichier doit implémenter correctement la convention de guillemetage — y compris les guillemets doublés à l’intérieur d’un champ entre guillemets, et les sauts de ligne à l’intérieur d’un champ — avant de pouvoir retrouver les frontières de colonnes.

Les tabulations sont presque absentes du type de données que les gens mettent dans des tables, donc le délimiteur et le contenu cessent d’être en compétition. Après cette conversion, le champ « Berlin, Germany » apparaît dans le fichier exactement comme cela, sans aucun guillemet sur la ligne, et tout ce qui découpe sur tabulation le récupère. C’est l’argument entier, et c’est un argument de fiabilité plutôt que de taille ou de vitesse.

Le contrôle propose détection automatique, virgule, point-virgule, tabulation et pipe. L’automatique convient presque toujours, parce qu’un fichier à plusieurs colonnes donne au détecteur beaucoup d’indices et il est bon pour les lire.

Nommez le séparateur explicitement dans deux cas. Le premier est un fichier à une seule colonne, où il n’y a rien à détecter. Le second est un fichier où un champ est bourré du mauvais caractère — une colonne de notes pleine de points-virgules dans un export délimité par virgules — ce qui peut faire choisir au détecteur le caractère qui apparaît le plus souvent plutôt que celui qui signifie quelque chose. Si l’aperçu du résultat a une colonne là où vous en attendiez six, ou six là où vous en attendiez une, c’est le réglage à changer en premier.

Des tabulations apparaissent dans des champs CSV, d’ordinaire parce que quelqu’un a collé depuis une page web ou un autre tableur dans une cellule. Dans le fichier source, c’est sans conséquence : le délimiteur est une virgule, donc la tabulation est un caractère ordinaire. Dans la sortie, ce n’est pas le cas, et le convertisseur gère cela en entourant le champ de guillemets doubles.

Le résultat est correct et un parseur complet le prend en charge. Le problème, c’est que le TSV est choisi précisément par des gens qui n’utiliseront pas un parseur complet — `cut -f` compte les caractères tabulation et n’a jamais entendu parler d’un guillemet, donc à partir de cette ligne il voit un champ de trop et chaque colonne après est décalée d’un cran. Si un pipeline produit une sortie désalignée sur quelques lignes sur des milliers, c’est presque toujours la cause. Retirez les tabulations de la source avant de convertir plutôt que de les patcher en aval.

Un export européen à point-virgules écrit d’ordinaire 1234,56 là où un fichier en locale anglaise écrit 1234.56. La conversion ne traduit pas cela, et ne devrait pas : elle n’a aucun moyen de savoir si 1.234 signifie un-et-quelque ou mille-deux-cent-trente-quatre, et deviner corromprait chaque prix du fichier.

Ce qui se passe à la place, c’est que la valeur reste exactement comme écrite, et parce qu’elle ne ressemble pas à un nombre pour le parseur, elle reste du texte. Donc une colonne de prix européenne arrive dans le TSV intacte et sans dommage, et ce qui lit le fichier ensuite doit être mis au courant de la convention décimale. En R c’est `dec = ","` à la lecture ; en pandas c’est `decimal=","`. Le régler là est plus sûr qu’un chercher-remplacer sur le fichier, qui réécrirait aussi les séparateurs de milliers et les virgules laissées dans les colonnes de texte.

La conversion n’est pas une substitution octet par octet d’un séparateur par un autre. Le fichier est parsé en lignes et réécrit, et sur le chemin les valeurs qui ont l’air numériques sont lues comme des nombres. `1e5` devient 100000. `true` et `false` deviennent des booléens et sont réécrits comme les mots en minuscules. Un champ vide devient un null et est réécrit comme un champ vide, ce qui est le seul cas où rien de visible ne change.

Le dommage collatéral, c’est le zéro de tête. Une colonne de codes postaux valant 01234 arrive dans le TSV comme 1234, et une référence de pièce zéro-remplie perd son remplissage silencieusement. Le test pour savoir si une colonne est à risque est de se demander si additionner deux de ses valeurs aurait un sens — codes postaux, numéros de téléphone, références de compte et références de pièces échouent tous. Si votre fichier a une telle colonne, regardez-la en sortie avant de charger le résultat quelque part.

Les champs ne sont entre guillemets dans le TSV que lorsqu’ils doivent l’être : quand ils contiennent une tabulation, un guillemet double ou un saut de ligne. Tout le reste est écrit nu. Un CSV qui est arrivé avec des guillemets autour de chaque champ — certains exportateurs le font sans condition — ressort avec presque aucun, ce qui est une réduction de taille substantielle sur un fichier large et un gain de lisibilité important quand on l’ouvre.

Un guillemet double dans un champ qui a besoin d’être entre guillemets est doublé, la même convention que le CSV utilise. Cela mérite d’être su si le fichier va quelque part qui découpe naïvement, parce qu’une colonne de texte libre contenant des guillemets est l’autre chose qui produit un champ entre guillemets dans un format où personne ne s’y attend.

Les lignes sont séparées par un seul saut de ligne plutôt qu’une paire retour chariot et saut de ligne, et le texte est en UTF-8 sans marque d’ordre d’octet. C’est ce qu’attendent un pipeline Unix, un diff Git, R et pandas, et c’est ce que la plupart des outils Windows acceptent désormais aussi.

L’absence de marque d’ordre d’octet mérite d’être nommée parce qu’elle a une conséquence : double-cliquer sur le fichier pour l’ouvrir dans Excel sous Windows affichera les caractères accentués comme du mojibake, parce qu’Excel retombe sur la page de code système quand il n’y a pas de marque pour lui dire autre chose. Ouvrir le fichier via Données, Obtenir des données, À partir d’un fichier texte/CSV et choisir UTF-8 l’évite. Si la destination est Excel plutôt qu’un script, convertir en XLSX à la place supprime complètement la question.

Les deux formats sont du texte brut et les deux lecteurs sont du JavaScript brut, donc la conversion tourne entièrement sur cette page. Aucune requête ne transporte le fichier, il n’y a pas de file et il n’y a pas de niveau d’offre — ce qui compte parce qu’un CSV est très souvent une liste de clients, un export de commandes ou un vidage système qu’il serait malaisant d’expliquer avoir téléversé.

La limite est la mémoire plutôt que la politique. Le fichier est lu en lignes et la table entière existe d’un coup avant que quoi que ce soit soit écrit, donc des dizaines de mégaoctets est routinier et des centaines le point où un onglet de navigateur commence à peiner. Au-delà, un parseur en flux dans un script est le bon instrument, et le dire est mieux que d’échouer à mi-chemin d’un très gros export.

Si la destination est un écran d’import qui dit CSV, laissez-le en CSV. Un nombre surprenant d’entre eux prennent le mot à la lettre et rejetteront un fichier délimité par tabulations quel que soit le bon sens du choix, et discuter avec un formulaire de téléversement n’est pas une lutte qui vaut la peine.

La sortie tabulée gagne sa place quand quelque chose va découper le fichier sur un caractère plutôt que le parser : un pipeline shell, un script R, un collage dans un programme avec un import délimité par tabulations, un coup d’œil rapide avec `cut`. Si en revanche les valeurs doivent garder leurs types tout au long du voyage, aucun format délimité ne peut aider — un fichier texte ne peut pas distinguer le nombre 7 de la chaîne « 7 » — et JSON, NDJSON ou Parquet est la destination honnête.