Convertir NDJSON en JSON

Un NDJSON est un fichier d’une ligne par enregistrement, et un JSON est un fichier d’un seul arbre. La conversion lit chaque ligne comme un objet et pose tous ces objets dans un tableau, et c’est tout. Le nombre d’enregistrements du fichier source est le nombre d’éléments du tableau, et la conversion n’invente rien entre les deux.

Cela paraît trivial, et c’est l’intérêt. Beaucoup d’outils qui lisent du NDJSON lisent aussi du JSON, et la conversion est utile quand un outil n’accepte qu’un seul fichier. La fusion vers un tableau est la forme la plus naturelle d’un journal agrégé, et elle est immédiatement consommable par n’importe quel parseur JSON standard.

Les lignes du NDJSON sont lues dans l’ordre où elles se présentent et posées dans le tableau dans le même ordre. L’ordre d’un journal n’est pas un détail : c’est ce qui rend lisible une trace de requêtes, un dump d’événements, un export d’observabilité. Le respecter est la seule chose non négociable de cette conversion.

Quand un outil externe doit re-trier, c’est lui qui décide du critère, et c’est lui qui applique le tri. La conversion n’échange pas l’ordre et ne le déduplique pas, ce qui serait deux modifications silencieuses du contenu. Si deux lignes du NDJSON sont identiques, elles produisent deux éléments identiques du tableau, parce que c’est ce que le fichier dit.

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 pour un fichier d’archive.

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 un tableau auquel 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.

Les lignes vides — un fichier qui se termine par un saut de ligne final, ou des enregistrements supprimés à la main — sont ignorées. La conversion compte les lignes non vides, et c’est ce nombre qui devient la longueur du tableau. Le saut de ligne final, qui est la convention Unix, ne produit pas un élément `null` à la fin du tableau.

Pour un journal propre, cela ne change rien. Pour un fichier nettoyé à la main, cela évite d’introduire des valeurs parasites qu’il faudrait filtrer ensuite. Le comportement est documenté et visible : un fichier de 412 003 lignes avec un saut de ligne final donne un tableau de 412 002 éléments, et un `wc -l` sur le fichier d’origine donne le même nombre une fois le saut de ligne retranché.

Un nombre en NDJSON arrive en nombre dans le tableau, un booléen en booléen, une chaîne en chaîne, un objet imbriqué en objet imbriqué, un `null` en `null`. La conversion ne touche pas aux types, parce qu’elle ne les voit pas comme une chose à normaliser : elle prend la valeur JSON, elle la pose dans le tableau, et c’est fini.

Le détail a son importance pour la suite. Un script qui consomme le tableau peut tester `typeof entry.id === "number"` et avoir une réponse correcte, ce qui n’est pas le cas après un passage par CSV. C’est aussi la raison pour laquelle un aller-retour NDJSON → JSON → NDJSON redonne exactement le fichier d’origine, tant qu’aucun outil entre les deux n’a réécrit les nombres en chaînes.

Un fichier qui se nomme `.ndjson` mais qui contient un tableau JSON unique, ou un objet JSON unique, n’est pas du NDJSON. La première ligne est valide, la deuxième n’existe pas, et la conversion déclare qu’il n’y a aucune ligne après la première. C’est cohérent avec ce que dit le format, et c’est utile parce que ces fichiers existent et sont produits par des outils qui confondent NDJSON et JSON.

Pour convertir un tableau JSON en NDJSON, c’est l’autre sens qui convient. Et pour un fichier qui n’est ni l’un ni l’autre — un CSV, un log Apache, un YAML — l’erreur le dit explicitement et la conversion s’arrête. Mieux vaut une erreur lisible qu’une tentative de devinette qui produit un tableau d’un élément avec un contenu qui n’a rien à voir.

La sortie est un JSON compact par défaut, sans indentation ni espace, ce qui est la forme la plus petite du fichier. Pour un fichier destiné à un humain — une revue, un diff, un débogage — une variante indentée est souvent préférable, et certains outils la produisent à partir du même JSON en reformatant. La conversion produit la forme la plus petite, parce que c’est ce que veut le consommateur typique.

Le format compact est aussi le plus rapide à parser pour la plupart des bibliothèques, parce qu’il n’y a pas d’espace à ignorer entre les tokens. Pour un fichier de cent mille lignes, la différence est mesurable, et c’est la raison pour laquelle la sortie n’est pas indentée par défaut.

La conversion lit le fichier dans l’onglet et l’écrit dans l’onglet. Aucune requête ne porte le fichier, et l’onglet réseau est vide pendant l’opération. Pour un journal applicatif qui contient des chemins, des identifiants d’utilisateur, des fragments de charge utile — un export de production, une trace d’incident — c’est la forme de conversion qui ne crée pas de copie sur l’infrastructure d’un tiers.

La taille maximale acceptée par la version gratuite est 100 Mo par fichier. Un journal d’activité d’une journée de production peut peser plusieurs gigaoctets, et le découpage se fait avant la conversion, soit par date soit par service, avec un outil local qui produit un NDJSON de moins de 100 Mo. La conversion ne le fait pas, parce qu’elle n’a pas le contexte pour décider ce qu’il faut garder et ce qu’il faut jeter.

Un journal de production d’une journée peut peser plusieurs gigaoctets en NDJSON, et un JSON agrégé pèserait à peine moins. La conversion charge le fichier en mémoire, parce qu’elle construit le tableau, et un fichier de plusieurs gigaoctets ne tient pas dans la mémoire d’un onglet. La taille maximale acceptée par la version gratuite est 100 Mo par fichier, ce qui est en deçà de ces volumes mais couvre largement les journaux d’une équipe, les exports de test, et les exports d’incident.

Pour un volume plus important, le découpage se fait avant la conversion, soit par date, soit par service, soit par fenêtre temporelle, avec un outil local qui produit des NDJSON de moins de 100 Mo. Chacun devient un JSON séparé, et l’assemblage final en un seul tableau se fait avec un script de quelques lignes. La conversion ne fait pas ce travail, parce qu’elle n’a pas le contexte pour décider ce qu’il faut garder et ce qu’il faut jeter.