Convertir NDJSON en INI

L’inadéquation est totale et mérite d’être nommée avant tout. Un fichier INI est un ensemble de sections nommées, chacune contenant des lignes plates clé-valeur — la description d’une chose, en général la configuration d’une application. Un fichier JSON délimité par des sauts de ligne est une suite d’enregistrements sans nom, sans ordre qui signifie quoi que ce soit et sans longueur fixée.

Aucune représentation ne satisfait les deux. Ce que fait la conversion, c’est utiliser le seul nom qu’un enregistrement dans une liste a, à savoir son index : la première ligne devient [0], la deuxième [1], et ainsi de suite. C’est fidèle, cela ne perd rien, et cela produit un fichier dont les noms de section ne portent aucun sens.

Si les enregistrements sont vraiment plusieurs configurations — une par hôte, une par environnement, une par client — alors renommer [0] et [1] avec les noms réels que ces choses ont transforme la sortie en fichier utilisable, et c’est tout le travail. Les clés en dessous sont déjà correctes.

Si les enregistrements sont des données plutôt que de la configuration, aucun renommage n’y fait rien, et les sections numérotées sont la conversion qui vous le dit. Cent sections nommées d’après des positions ne sont pas un fichier de configuration ; c’est une table écrite dans la mauvaise notation. CSV, JSON ou une base de données est ce qu’il faut, et chacun est à une conversion du même fichier.

Cela prend les gens au dépourvu, et cela mérite d’être dit. Un fichier contenant exactement une ligne est encore une liste d’un, et la sortie est une section [0] contenant tous les champs de cet enregistrement. Ce n’est pas l’INI propre que vous auriez eu du même objet tout seul.

La correction consiste à changer le format source plutôt qu’à modifier la sortie. Enregistrez cette unique ligne avec une extension .json et convertissez plutôt JSON en INI : là les clés de premier niveau de l’enregistrement deviennent les en-têtes de section, les valeurs simples sont écrites au-dessus, et le fichier ressemble à quelque chose qu’une personne a tapé. Ce sont les mêmes données par une autre porte, et cela prend dix secondes.

INI accepte des sections et rien à l’intérieur des sections. Sur cette paire ce niveau unique est pris par l’index d’enregistrement, donc chaque champ d’un enregistrement — y compris toute imbrication qu’il avait — doit vivre dans le nom de la clé.

Un enregistrement avec un objet serveur contenant un port produit une ligne `server.port` à l’intérieur de la section numérotée. Rien n’est écarté et le chemin est préservé, mais deux enregistrements avec la même structure imbriquée ne partagent maintenant rien structurellement : ce sont deux sections dont les clés se trouvent être orthographiées de la même manière. Tout analyseur qui reconstruit l’imbrication à partir de clés pointées la reconstruit par section, ce qui est généralement ce que vous voulez et jamais quelque chose à tenir pour acquis.

Un enregistrement portant une liste d’hôtes autorisés produit des clés nommées 0, 1 et 2 sous le chemin de ce champ. Combiné avec les sections numérotées, une sortie peut finir avec une ligne lisant `hosts.0` dans une section appelée [2], ce qui est lisible et peu élégant.

Les analyseurs INI qui acceptent des listes attendent en général une seule ligne avec des valeurs séparées par des virgules, et quelques-uns attendent la même clé répétée. Ni l’un ni l’autre n’est ce que cela produit. Si l’application a une convention, joindre le tableau en une seule chaîne dans la source avant la conversion produit une ligne que l’analyseur lit nativement, et le faire après signifie éditer chaque groupe à la main.

Un JSON `true` s’écrit `true`, un nombre comme ses chiffres, un `null` comme la clé sans rien après le signe égal, et une chaîne exactement comme elle était. Les guillemets n’apparaissent que là où la valeur ne pourrait pas être relue comme elle est entrée : autour d’une valeur avec une espace à un bout, d’une qui commence et finit déjà par un guillemet, et d’une contenant un saut de ligne. Cela garde au fichier l’apparence d’un fichier qu’une personne a tapé, ce qu’attend quiconque l’édite ensuite.

Le saut de ligne dans une valeur est le cas qui mérite d’être nommé, parce qu’une entrée INI est une ligne. Il s’écrit barre oblique et n à l’intérieur des guillemets plutôt que comme un vrai saut, ce qui empêche le texte qui suit de devenir des lignes isolées — ou, quand l’une d’elles ressemble à un en-tête entre crochets, une section qui n’était dans aucun enregistrement. Certificats, clés et scripts embarqués en sont les porteurs habituels, et même s’ils survivent désormais à un aller-retour ici, une valeur de cette taille a sa place dans son propre fichier, l’INI pointant sur le chemin, ce que la plupart des applications qui lisent de l’INI attendent de toute façon.

INI accepte les commentaires — une ligne commençant par un point-virgule ou un dièse — et le lecteur de ce site honore les deux dans l’autre sens. JSON n’en a pas, donc le fichier converti arrive sans aucun.

Puisque la raison de produire un INI est presque toujours qu’une personne va le lire ou l’éditer, écrire ces lignes est la première édition utile. Quelles sections sont spécifiques à un environnement, quelle valeur doit correspondre à quelque chose ailleurs, et laquelle l’application ignore complètement : rien de tout cela ne pouvait être porté par la source et tout cela est à quoi le format de destination sert.

Toute valeur d’un fichier INI est du texte. Savoir si 8080 est un nombre, si `true` est un booléen et si 007 garde ses zéros est décidé par ce qui lit le fichier — le `configparser` de Python rend la chose explicite avec `getint` et `getboolean`, et accepte aussi `yes`, `on` et `1` pour `true`.

C’est une perte par rapport à la source, où les types étaient écrits. Ce n’est généralement pas un problème, parce qu’une application qui lit de l’INI sait déjà ce qu’elle attend pour chaque réglage. Là où cela compte, ce sont les identifiants avec des zéros initiaux, et la correction se trouve dans le code de lecture plutôt que dans le fichier.

La règle d’arrêt honnête pour cette paire : si la sortie a plus d’une poignée de sections numérotées et que vous ne pouvez pas donner à chacune un vrai nom, la conversion a répondu à une question différente de celle que vous posiez. INI décrit une seule chose ; une liste d’enregistrements n’est pas une seule chose.

Les alternatives depuis le même fichier sont à un clic et toutes meilleures pour ce cas. CSV ou un classeur si c’est une personne qui regardera les enregistrements, SQL ou Parquet si c’est un programme qui les interrogera, TOML si ce que vous vouliez vraiment était une liste d’enregistrements dans un fichier de configuration, puisqu’il a un construct « tableau de tables » dont INI est tout simplement dépourvu.

La conversion est du JavaScript ordinaire dans cet onglet de navigateur. Rien n’est téléversé, il n’y a ni compte ni file d’attente, et le niveau gratuit accepte jusqu’à 100 Mo — une limite qu’aucun fichier de configuration n’a jamais atteinte.

Cela compte plus que la taille du fichier ne le suggère. Les exports de configuration contiennent des chaînes de connexion, des points d’accès d’API, des noms d’hôtes internes et, plus souvent que quiconque ne l’admet, un identifiant qui aurait dû être une variable d’environnement. Envoyer un tel fichier à un convertisseur sur l’infrastructure de quelqu’un d’autre pour qu’il retire ses accolades serait une mauvaise affaire à n’importe quel prix.