Convertir INI en JSON

Le résultat est un seul objet JSON. Chaque en-tête de section devient une clé contenant un objet propre, et les paires clé-valeur sous cet en-tête deviennent les propriétés de cet objet. Les clés écrites avant tout en-tête de section — ce que beaucoup d’appels le bloc global — se trouvent au niveau supérieur à côté des objets de section plutôt que sous un wrapper dédié.

C’est toute la traduction structurelle, parce qu’il n’y a rien d’autre dans un fichier INI à traduire. Ce qui fait que cette paire mérite d’être lue, ce n’est pas la forme mais les valeurs, qui ne survivent pas au voyage aussi littéralement que la forme.

Un fichier INI n’a pas de types. Tout ce qui suit le signe égal est des caractères, et chaque programme qui en lit un décide pour lui-même ce que ces caractères signifient. Ce lecteur décide ainsi : les chaînes exactes true et false deviennent des booléens JSON, tout ce qui se parse comme un nombre fini devient un nombre JSON, et tout le reste reste une chaîne.

Pour la plupart des configurations, c’est le bon choix et vous épargne une passe de parseInt de l’autre côté. Un port sort comme 8080 plutôt que « 8080 », un timeout comme 30, et un drapeau négatif comme -1 sous forme de nombre comparable. Le coût, c’est que le lecteur ne peut pas distinguer une quantité d’un identifiant, et c’est là que les dégâts arrivent.

Quatre cas échouent silencieusement et les quatre apparaissent dans de vrais fichiers de configuration. Un identifiant zéro-rempli écrit 007 devient le nombre 7. Un mode de fichier Unix écrit 0755 devient 755, ce qui est un mode différent et sera appliqué comme tel. Un masque hexadécimal écrit 0x1F devient 31, correct en valeur et faux dans chaque ligne de log qui le réimprime. Une version épinglée à 1.0 devient 1.

Le quatrième cas est plus subtil : un entier plus grand qu’environ neuf trillions perd de la précision, parce que les nombres JSON sont des doubles IEEE. Un identifiant 64 bits écrit 9223372036854775807 sort comme 9223372036854776000. Rien ne vous prévient. Si une clé porte un ID snowflake, un numéro de série ou une référence de compte, mettez-la entre guillemets dans le fichier INI source — les valeurs entre guillemets sont quand même parsées, donc la parade la plus sûre est de préfixer ou suffixer avec quelque chose de non numérique, ou de corriger la valeur dans le JSON après coup.

Cela vaut la peine de savoir quelles clés vous n’avez pas besoin de vérifier. Tout ce qui porte une unité est sûr, donc une limite mémoire écrite 128M reste la chaîne 128M. Les adresses pointées restent des chaînes, donc 127.0.0.1 passe sans être touchée. Les heures comme 08:00 restent des chaînes, comme les chemins, les URLs, et tout ce qui contient une lettre qui n’est pas partie d’un nombre.

Une valeur contenant un signe égal survit aussi, parce que la ligne est découpée au premier signe égal seulement, ce qui garde une chaîne de connexion ou un paramètre de requête intact. Les guillemets autour sont retirés, mais seulement la paire la plus extérieure — une valeur écrite avec du remplissage à l’intérieur des guillemets garde ce remplissage, tandis qu’une valeur non quotée est rognée aux deux bouts. À l’intérieur de ces guillemets, et seulement là, une barre oblique inversée commence un échappement : une barre oblique inversée suivie d’un n devient un saut de ligne, et deux barres obliques inversées deviennent une seule. C’est ce qui permet à une valeur multi-ligne de survivre au voyage aller vers INI et retour, et c’est pourquoi un chemin Windows non quoté tel que C: ew est lu exactement tel qu’il est écrit alors que le même chemin à l’intérieur de guillemets ne l’est pas.

Les fichiers INI Windows et php.ini utilisent On et Off bien plus souvent que true et false, et le lecteur ne les traite pas comme des booléens. Ils sortent comme les chaînes « On » et « Off », ce qui est défendable — ce sont, après tout, rien que des mots — et n’est presque jamais ce que le consommateur du JSON attend.

La même chose s’applique à yes et no, et à 1 et 0 utilisés comme drapeaux, qui deviennent les nombres 1 et 0 plutôt que des booléens. Ce qui lit le JSON doit décider ce qui compte comme truthy, et l’habitude la plus sûre est de normaliser ces clés explicitement dans le code consommateur plutôt que de supposer que la conversion les a rendues cohérentes. Une config avec engine à On et debug à false a maintenant deux sortes différentes de oui dedans.

L’ordre des clés est préservé presque partout, ce qui compte quand vous lisez un diff plutôt qu’une machine. Les sections sortent dans l’ordre où elles sont apparues, et les clés dans une section gardent l’ordre où elles ont été écrites.

L’exception, ce sont les clés numériques. Les objets JavaScript mettent les clés d’allure entière en premier et dans l’ordre numérique ascendant, avant toute autre clé, donc une section écrite 10, 2, name sort comme 2, 10, name. Les fichiers INI qui utilisent des nombres comme clés — listes de serveurs, règles ordonnées, entrées de playlist — sortent réordonnés. Si l’ordre a du sens dans votre fichier, cette section veut être un tableau JSON, et la transformer est une édition manuelle.

INI n’a pas de spécification, donc les implémentations ne sont pas d’accord sur les en-têtes de section répétés : certaines les fusionnent, certaines gardent les deux, certaines prennent la dernière. Ce lecteur commence une section vide à chaque fois qu’il rencontre un en-tête, donc un fichier contenant [logging] deux fois ne garde que les clés du second bloc. Le premier bloc est parti, et le JSON est valide, et rien ne le signale.

Ce schéma apparaît dès que des configurations sont assemblées par concaténation, ce qui est une astuce de déploiement courante — un fichier de base plus une surcouche d’environnement, ajoutés. Greppez la source pour les en-têtes dupliqués avant de convertir. Les clés dupliquées à l’intérieur d’une même section se comportent de la même manière, avec la dernière assignation qui gagne.

C’est la perte qui est structurelle plutôt qu’incidente. INI supporte les commentaires et les utilise abondamment ; JSON, tel que spécifié dans la RFC 8259, n’a aucune syntaxe de commentaire. Même un convertisseur qui voudrait les préserver n’aurait nulle part où les mettre, à part inventer une convention comme une clé _comment qu’aucun consommateur ne lirait.

Sur un fichier de paramètres, c’est souvent la plus grosse chose que vous perdez. La note qui enregistre pourquoi une taille de pool est 12 plutôt que la valeur par défaut, le bloc commenté gardé en exemple, la ligne marquant une valeur comme réglée pour un client — rien de tout cela ne passe. Gardez le fichier INI d’origine en gestion de version à côté du JSON plutôt que de traiter la conversion comme un remplacement.

La sortie est du JSON ordinaire avec indentation à deux espaces, donc jq, Node, Python et tout validateur de JSON Schema le lisent sans cérémonie. Une section devient un chemin d’objet — .database.host dans jq — et un schéma peut alors affirmer que le port est un nombre et que l’host est une chaîne, ce qui est le gain réel sur le fichier INI, puisqu’un fichier INI ne peut être validé par rien.

Les conversions de fichiers de cette taille sont instantanées et tournent entièrement dans le navigateur, avec un plafond de 100 Mo en offre gratuite qu’aucun fichier de configuration n’atteindra jamais. La contrainte pratique n’est pas la taille mais la relecture : lisez les valeurs numériques en sortie une fois, avant que le JSON ne devienne le fichier auquel tout le reste fait confiance.