Convertir NDJSON en TSV

Le CSV sépare ses colonnes par des virgules, ce qui entre en conflit avec des données qui contiennent elles-mêmes des virgules — des phrases, des descriptions, des valeurs numériques au format anglais avec décimale. Le TSV sépare par une tabulation, qui est un caractère beaucoup plus rare dans les valeurs, et l’échappement est presque toujours inutile.

Pour un journal applicatif où chaque champ est une chaîne ou un nombre, le TSV est strictement plus simple que le CSV : pas de guillemet, pas de doublage, pas de règles d’échappement. Le tableur l’importe sans poser de question, et un `awk` ou un `cut` en ligne de commande le lit avec un seul caractère comme séparateur.

L’arithmétique est la même que pour toute autre source de cette catégorie. NDJSON garantit un enregistrement complet par ligne, donc le nombre de lignes du fichier est le nombre de lignes de la sortie plus l’en-tête. Si le fichier a 412 000 lignes, la table aura 412 001 lignes, et un écart avec ce compte signale un problème en amont plutôt qu’une perte de la conversion.

Les lignes vides sont ignorées, y compris le saut de ligne final que presque tous les écrivains laissent à la fin. Le compte exact est lisible à la première ouverture du fichier, parce que le tableur affiche le nombre de lignes en bas, et c’est un contrôle immédiat de l’exhaustivité de la sortie.

Chaque ligne d’un fichier NDJSON est indépendante, et rien n’oblige la deuxième à porter les mêmes clés que la première. Un journal applicatif qui émet plusieurs types d’événements — une requête, une erreur, une fin de tâche — les rassemble dans un seul fichier avec des champs différents à chaque ligne.

La conversion rassemble chaque clé vue n’importe où dans le fichier et en fait une colonne, laissant vides les cellules là où une ligne n’avait rien. Rien n’est perdu, et le résultat peut être très clairsemé : quarante colonnes dont chaque ligne en utilise huit. Si cela décrit la sortie, filtrer le fichier à un seul type d’événement avant de convertir produit une table plus lisible, et c’est une étape que des outils comme `jq` rendent triviale.

La journalisation structurée imbrique presque toujours : un objet `request` avec une méthode et un chemin, un objet `user` avec un identifiant, un bloc `context` avec un identifiant de trace. Ces objets s’aplatissent en colonnes nommées d’après le chemin — `request.method`, `user.id` — avec une colonne par valeur feuille.

Un ou deux niveaux produisent une table sur laquelle on peut travailler, ce qui couvre les défauts de la plupart des bibliothèques de journalisation. Des structures plus profondes s’élargissent vite, et une ligne de journal portant toute une charge utile sérialisée produira une colonne par champ à l’intérieur. Quand cela arrive, la partie intéressante du fichier est un sous-arbre, et l’extraire avant la conversion donne une bien meilleure table qu’aplatir tout et cacher des colonnes ensuite.

Un enregistrement portant une liste — des étiquettes, des frames d’erreur, un ensemble de règles appliquées — est aplati en colonnes numérotées : `tags.0`, `tags.1`, `tags.2`. Chaque valeur survit et la table obtient une colonne pour la plus longue liste du fichier, la plupart vides.

Pour l’analyse c’est rarement ce que veut la personne qui lira la table. Si le tableau est secondaire, le joindre en une seule chaîne avant la conversion produit une colonne lisible. Si le tableau est ce qui est analysé — compter des frames d’erreur, par exemple — la forme voulue est une ligne par élément, ce qui signifie déplier le fichier auparavant. Les deux tiennent en une seule expression `jq`, et les deux battent le tri d’un tableur par `tags.3`.

Si une ligne n’est pas un JSON valide, la conversion ne continue pas au-delà. Le message dit laquelle : « Ce fichier n’a pas pu être lu comme NDJSON — la ligne 3 n’est pas un JSON valide. » C’est délibéré, et c’est le comportement souhaitable pour un fichier d’archive qui doit son exhaustivité à son auteur.

Sauter la ligne en silence produirait une table à laquelle manquerait un nombre inconnu d’enregistrements sans rien pour l’indiquer. Le numéro de ligne en main, supprimer ou réparer la queue prend une seule commande, et la personne qui nettoie sait exactement ce qu’elle a perdu plutôt que de le découvrir en analysant des totaux qui ne tombent pas en face.

Les valeurs sont écrites fidèlement — un nombre en chiffres, un booléen en `true` ou `false`, un `null` en cellule vide — mais le TSV n’a pas de système de types, donc ce qui ouvre le fichier décide ce qu’est chaque colonne. Les zéros initiaux d’un identifiant numérique disparaissent, et une longue valeur numérique peut être interprétée en notation scientifique.

Pour un journal de logs, c’est en général sans conséquence : la colonne de code d’erreur est lue comme une chaîne, la colonne de durée comme un nombre, et le tableur devine avec une précision acceptable. Pour des identifiants qui doivent garder leurs zéros, importer en forçant le type Texte sur les colonnes sensibles plutôt que d’ouvrir en double-cliquant — c’est la parade standard, et elle s’applique aussi au CSV.

La tabulation est un caractère rare dans les valeurs, ce qui rend l’échappement presque toujours inutile. Quand un champ contient une tabulation — c’est rare, mais cela arrive dans un copié-collé depuis une console — la conversion l’échappe en le transformant en espace, et la valeur perd son tabulation sans casser la structure du fichier.

Pour un fichier destiné à un tableur, le TSV s’ouvre ou s’importe avec un seul clic et une seule option, et l’absence de guillemets autour des valeurs accélère l’affichage sur de gros fichiers. Pour un fichier destiné à un script, le TSV se lit avec `awk -F" "` et se manipule avec les outils Unix standard, sans bibliothèque spécialisée.

Pour un import dans une base qui attend un séparateur particulier — un point-virgule pour Excel français, une barre verticale pour un script shell, un deux-points pour un format historique — il est souvent plus simple de partir du TSV généré par cette conversion et de remplacer le séparateur par une commande `tr` ou `sed`. Le résultat est strictement équivalent, et le passage par un séparateur exotique directement depuis NDJSON demanderait un outil spécialisé.

Pour un import dans un entrepôt de données comme BigQuery, Snowflake ou Redshift, le TSV produit directement est presque toujours accepté avec une option de format, et la conversion ne sert que de première étape. Pour un import dans R ou pandas, le TSV se lit avec une seule ligne de code, et la conversion est transparente pour l’analyse en aval.