Convertir JSON en INI

Toute la conversion tient dans cette phrase. Un fichier INI est une liste de sections, chacune contenant des lignes plates clé-valeur, et il n’existe aucun moyen d’imbriquer une section dans une section. Il n’a pas de spécification — il date de 1985, précède l’idée qu’un format de configuration en aurait besoin une, et chaque analyseur a des opinions légèrement différentes sur les guillemets et les commentaires — c’est pourquoi le registre le marque comme hérité plutôt que comme actuel.

JSON imbrique sans limite. La conversion doit donc projeter un arbre sur deux niveaux, et la question intéressante n’est pas de savoir si cela fonctionne mais ce qu’elle fait du troisième niveau et de tout ce qui se trouve en dessous. La réponse courte est qu’elle conserve les données et abandonne la structure, ce qui est le bon compromis dans le sens où un fichier de configuration voyage en général.

Chaque clé de premier niveau dont la valeur est un objet devient une section : un fichier JSON contenant des objets server, logging et database produit [server], [logging] et [database], avec les clés à l’intérieur écrites en dessous. Pour des réglages écrits à l’origine par une personne, c’est très souvent une correspondance exacte, et la sortie est le fichier que vous auriez tapé.

Les clés de premier niveau tenant une valeur simple — un drapeau de débogage, un numéro de version — sont écrites au-dessus du premier en-tête de section plutôt qu’après. Ce n’est pas un choix de style : une section INI s’approprie chaque ligne qui la suit jusqu’à l’en-tête suivant, de sorte qu’une clé nue écrite plus bas deviendrait membre de la section précédente et changerait de sens.

Un troisième niveau d’imbrication est écrit en clé pointée. Si server contient un objet tls contenant un chemin de certificat, la sortie est une section [server] contenant une ligne tls.cert. Rien n’est écarté, et le chemin qui ramène à la forme d’origine est inscrit dans le nom de la clé.

Certains analyseurs comprennent cette convention et reconstituent l’imbrication ; la plupart ne le font pas, et traitent tls.cert comme une clé qui se trouve contenir un point. L’un ou l’autre convient en général pour lire un réglage. Ce qui ne l’est pas, c’est l’aller-retour en général — une clé JSON qui contient réellement un point devient indiscernable d’un niveau d’imbrication, et aucun lecteur ne peut dire laquelle des deux elle était.

La clé survit et la valeur ne survit pas : un null sort en clé, signe égal et rien. C’est ce qui se rapproche le plus d’une valeur non définie en INI, puisque le format n’a ni null ni moyen d’en exprimer un.

Ce que votre analyseur en fait varie, et cela mérite dix secondes pour s’en assurer. Le configparser de Python renvoie une chaîne vide. Certains lecteurs renvoient eux aussi la chaîne vide mais la traitent comme false dans un contexte booléen, et quelques-uns ignorent la clé. Si la différence entre « réglé à rien » et « non réglé » pilote le comportement de l’application, supprimez ces lignes à la main plutôt que de livrer l’ambiguïté.

INI n’a pas de liste. Un tableau de trois hôtes autorisés devient trois lignes indexées 0, 1 et 2, ce qui préserve chaque valeur et ne correspond à presque aucune convention d’analyseur. Les formats qui acceptent des listes attendent en général une seule ligne avec les valeurs séparées par des virgules, et quelques-uns attendent la même clé répétée.

C’est la partie de la conversion qui mérite d’être modifiée dans le JSON avant l’opération plutôt que dans l’INI après. Joignez le tableau en une seule chaîne avec le séparateur qu’attend l’application, convertissez, et la sortie est une ligne que l’analyseur lit nativement. Faire la chose dans l’autre sens oblige à éditer à la main chaque groupe numéroté.

Un tableau JSON de premier niveau produit des sections nommées d’après les positions du tableau : [0], [1], [2], chacune contenant les clés d’un enregistrement. Le fichier est syntaxiquement un INI valide et il n’existe aucun programme sensé qui le lise.

Cette sortie est un signal plutôt qu’un échec. INI est un format de configuration — un ensemble de réglages nommés pour une seule application — et une liste d’enregistrements est une donnée. Si ce que vous avez est une liste, CSV ou tableur est la cible si une personne doit la lire, et JSON ou base de données si c’est un programme. La conversion ne refuse pas, parce qu’un fichier à un enregistrement est un objet légitime à vouloir, mais une suite de sections numérotées signifie que la réponse à la question initiale était non.

Quasiment toute valeur est écrite exactement comme elle se présente — un chemin, un nom d’hôte, un port, un drapeau — ce qui garde au fichier l’apparence d’un fichier qu’une personne aurait tapé. Trois types de valeurs ne le sont pas. Une valeur contenant un saut de ligne, une valeur qui commence et finit déjà par un guillemet, et une valeur qui a un espace ou une tabulation à l’une ou l’autre extrémité sont entourées de guillemets doubles, et à l’intérieur de ces guillemets un saut de ligne s’écrit barre oblique et n, un retour chariot barre oblique et r, et une barre oblique deux barres obliques.

Cette neutralisation est récente et elle a remplacé un véritable défaut. Jusqu’au 9 août 2026, une chaîne JSON contenant un saut de ligne était écrite telle quelle en vrai saut de ligne, si bien que le JSON {"app":{"motd":"hello\n[admin]\npassword=secret","plain":"x"}} produisait une section [admin] qui n’apparaît nulle part dans la source — et la clé écrite après, plain, était relue à l’intérieur de cette section inventée plutôt que dans app. Une valeur pouvait déplacer ses voisines. Les deux moitiés de ce convertisseur s’accordent désormais sur la neutralisation, donc une valeur multi-ligne survit à l’aller-retour. Un autre programme qui lirait le fichier peut ne pas comprendre la neutralisation et vous redonner les deux caractères au lieu d’un saut de ligne, si bien qu’un certificat ou un script embarqué a toujours sa place dans son propre fichier, l’INI pointant sur le chemin.

INI stocke tout en texte. Un JSON true s’écrit true, un JSON 8080 s’écrit 8080, et ce que ces valeurs signifient ensuite est décidé par ce qui lira le fichier. Le configparser de Python rend la chose explicite avec getboolean et getint, et il accepte yes, on et 1 pour true également.

Cela mérite de savoir dans quel sens va la devinette de votre analyseur avant de se fier à une valeur. Une chaîne de version 1.0 est du texte dans le JSON et sera très probablement relue comme un nombre, et un identifiant de version avec des zéros initiaux les perd dès que quelque chose le traite comme un entier. Quand cela compte, la correction se fait dans l’application qui lit le fichier plutôt que dans le fichier lui-même.

La sortie ne porte aucun commentaire, parce que le JSON n’en a pas à donner. INI en accepte — une ligne commençant par un point-virgule ou un dièse — et ce convertisseur les respecte tous les deux quand il lit dans l’autre sens.

Puisque l’intérêt de déplacer des réglages dans un INI est en général qu’une personne va les éditer, les lignes de commentaire valent la peine d’être ajoutées immédiatement : quelles valeurs sont spécifiques à l’environnement, laquelle doit correspondre à une valeur ailleurs, et quelle section l’application ignore complètement. C’est précisément l’information qu’un fichier JSON généré n’a jamais pu porter.

C’est du JavaScript dans l’onglet de votre navigateur. Le fichier n’est pas téléversé, il n’y a ni compte ni file d’attente, et le niveau gratuit accepte jusqu’à 100 Mo, ce qui est de plusieurs ordres de grandeur supérieur à n’importe quel fichier de configuration.

L’argument de confidentialité n’a rien de décoratif pour cette paire. Les fichiers de réglages contiennent des chaînes de connexion à la base, des points d’accès d’API, des noms d’hôtes internes et, plus souvent que quiconque ne l’admet, un mot de passe qui aurait dû être une variable d’environnement. Convertir un tel fichier sur un serveur distant signifie remettre tout cela à un tiers sans aucun bénéfice, et ici il n’y a rien à remettre.