Convertir NDJSON en CSV

L’arithmétique ici est plus simple que pour toute autre source du site. NDJSON garantit un enregistrement complet par ligne, donc le nombre de lignes que vous obtiendrez est le nombre de lignes du fichier — `wc -l` en ligne de commande, ou le compte de lignes de tout éditeur capable d’ouvrir le fichier. Rien dans les données ne peut produire de saut de ligne, parce qu’un saut de ligne à l’intérieur d’une valeur est échappé dans le JSON.

Cela rend la conversion prévisible d’une manière dont un tableau JSON ne l’est pas. Si le fichier a 412 000 lignes, vous obtenez 412 000 lignes plus l’en-tête, et si la sortie en a moins, c’est l’entrée qui est en cause et non la conversion. Les lignes vides sont ignorées, y compris le saut de ligne final que presque tous les écrivains laissent à la fin.

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 flux de journal 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, ce qui est tout à fait raisonnable en flux et maladroit en table.

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 votre sortie, le bon mouvement est de filtrer le fichier à un seul type d’événement avant de convertir plutôt que d’élargir le tableur — `jq` avec un `select` sur le type d’événement prend quelques secondes et produit une table qu’on peut réellement lire.

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é plutôt que fragile, et c’est le comportement souhaitable.

Une ligne cassée dans un journal ne signifie presque jamais un caractère égaré. Cela signifie une écriture tronquée — un processus tué en plein vidage, un fichier rotaté coupé à la limite, un téléversement partiel — et tout ce qui suit est suspect. 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 vous savez exactement ce que vous avez perdu.

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 réponse honnête est que 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 vous voulez. Si le tableau est secondaire, le joindre en une seule chaîne avant la conversion produit une colonne lisible. Si le tableau est ce que vous analysez — 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`.

Les types sont la principale perte, et cela mérite d’être clair qu’ils sont perdus à destination plutôt qu’en transit. Les valeurs sont écrites fidèlement — un nombre en chiffres, un booléen en `true` ou `false`, un `null` en cellule vide — mais le CSV n’a pas de système de types, donc ce qui ouvre le fichier décide ce qu’est chaque colonne.

Excel décide mal et de manière prévisible : les zéros initiaux disparaissent des identifiants, tout ce qui ressemble à une date devient une date, et les longs identifiants numériques perdent leurs derniers chiffres. Le remède est d’importer plutôt que d’ouvrir — Données, puis À partir d’un texte/CSV, avec les colonnes d’identifiant en Texte — ou de convertir plutôt en XLSX, où les types sont déclarés dans le fichier et rien n’est deviné.

Les valeurs contenant une virgule, un guillemet ou un saut de ligne sont entourées de guillemets doubles avec leurs guillemets internes doublés, ce qui est la convention de la RFC 4180 et que tout importeur qui mérite de l’être lit correctement. Tout le reste est écrit tel quel, et le fichier reste lisible.

Les données de journal s’appuient sur ce mécanisme plus que la plupart. Agents utilisateurs, chemins de requête avec chaînes de recherche, messages d’erreur et traces de pile sont tous pleins de virgules et de guillemets. Si la destination est une pipeline shell plutôt qu’un tableur — `awk`, `cut`, une coupe naïve sur les virgules — les guillemets sont précisément ce que ces outils ne gèrent pas, et convertir plutôt en valeurs séparées par des tabulations évite toute la discussion.

L’analyse est rapide et le plafond est la mémoire, parce que le fichier entier est lu en enregistrements et que l’ensemble complet des colonnes est déterminé avant que la première ligne puisse être écrite. Le niveau gratuit accepte jusqu’à 100 Mo ; quelques dizaines de mégaoctets se convertissent sans drame et quelques centaines de mégaoctets sont le point où un onglet de navigateur commence à peiner.

Au-delà, le format source est de votre côté. NDJSON se scinde sans risque à toute limite de ligne — `split -l 500000` produit des fichiers valides — donc convertir un très grand journal en morceaux est légitime plutôt qu’un contournement, et les morceaux ont des en-têtes identiques si les formes d’événements le sont. Pour un fichier qui se compte en gigaoctets, un outil en flux est le bon instrument et cette page ne l’est pas.

Le CSV est une vue, pas un remplacement. Il a perdu les types, aplati la structure et rapproché des enregistrements qui n’avaient jamais été obligés de s’accorder, et rien de cela n’est récupérable depuis la table.

Le fichier d’origine est aussi meilleur pour ce que vous voudrez ensuite. Il s’allonge sans réécriture, il se filtre avec `jq` sans être chargé en entier, et il peut être converti à nouveau avec un sous-arbre différent extrait quand la question change. Traitez le CSV comme la réponse à la question d’aujourd’hui et le NDJSON comme la donnée.

La conversion est du JavaScript ordinaire qui s’exécute dans cet onglet de navigateur. Aucune requête ne transporte le fichier, il n’y a ni compte ni quota journalier, et vous pouvez tout confirmer en ouvrant l’onglet réseau et en convertissant quelque chose.

Ce n’est pas un détail pour cette paire. Un journal de production contient des adresses IP, des identifiants de session, des chemins de requête, des agents utilisateurs, et assez souvent une chaîne de requête avec un jeton dedans — exactement la catégorie que personne ne devrait coller dans un service web. Ici il n’y a rien à téléverser.