Convertir INI en XML

La correspondance est assez directe pour être prédite. Un en-tête de section devient un élément, chaque clé située en dessous devient un enfant de cet élément, et la valeur devient le texte de l’enfant. Un fichier INI contenant [db] avec host et port en dessous ressort en un élément db contenant un élément host et un élément port, indentés de deux espaces par niveau.

Cette prévisibilité est la raison pour laquelle cette paire mérite un outil plutôt qu’un script. Il n’y a aucune ambiguïté à lever, parce qu’un INI n’offre au convertisseur presque rien à interpréter : un niveau de regroupement, une clé, une valeur par ligne. Tout l’intéressant se passe aux bords, et le reste de cette page parle de ces bords.

XML exige exactement un élément extérieur et un INI n’a pas la notion d’un tel élément. Le convertisseur tranche en regardant ce qu’il a lu : si le fichier contenait une seule section et rien d’autre, cette section devient la racine, de sorte qu’un fichier à une seule section nommée [settings] produit un document dont la balise racine est settings. Tout le reste — deux sections, ou des clés écrites au-dessus du premier en-tête de section — est enveloppé dans un élément racine générique.

Cela mérite d’être su avant d’écrire un XSD ou un XPath contre le résultat. Ajouter une seconde section au fichier INI source change silencieusement l’élément racine de la sortie de settings à root, et toute expression de chemin écrite contre la première version cesse de correspondre. Si la forme du document compte en aval, décidez vous-même de l’enveloppe et gardez-la stable plutôt que de laisser le nombre de sections en décider.

INI n’a aucun système de types : tout ce qui se trouve à droite du signe égal est une suite de caractères. Le lecteur devine quand même, en transformant true et false en booléens et tout ce qui s’analyse comme un nombre en nombre, puis l’écriture XML réimprime ce qu’elle a reçu en texte. Pour la plupart des clés, l’aller-retour est invisible.

Pour certaines, il ne l’est pas. Une valeur écrite 007 est lue comme le nombre 7 et réécrite comme 7. Une clé de version écrite 1.0 devient 1. Un masque hexadécimal écrit 0x1F ressort comme 31, et un mode de fichier Unix écrit 0755 ressort comme 755, ce qui n’est pas le même mode. Tout ce qui porte une unité survit intact, donc 128M reste 128M, et il en va de même pour des adresses pointées comme 127.0.0.1 et des horaires comme 08:00, parce qu’aucun ne s’analyse comme un seul nombre.

XML est bien plus strict que INI sur les noms. Une clé INI peut contenir des espaces, des barres obliques, des deux-points et des crochets ; un nom d’élément ne peut contenir que des lettres, des chiffres, des soulignés, des traits d’union, des points et guère plus, et il ne doit pas commencer par un chiffre. L’écriture substitue donc un souligné à chaque caractère qu’elle ne peut pas employer, et préfixe d’un souligné tout nom qui commence par autre chose qu’une lettre ou un souligné.

La substitution n’est pas réversible, si bien que deux clés qui ne diffèrent que par leur ponctuation entrent en collision sur le même nom d’élément — « log level » et « log-level » ne se télescopent pas, parce que le trait d’union est autorisé, mais « log level » et « log/level » deviennent tous deux log_level. Si votre fichier INI comporte des clés de ce genre, renommez-les dans la source avant de convertir plutôt que d’essayer de démêler ensuite quel élément venait de quelle ligne.

Un en-tête de section écrit [database.pool] ressemble à de l’imbrication, et en TOML il s’imbriquerait. Ici, il ne le fait pas : le lecteur prend tout ce qui se trouve entre les crochets comme un seul nom de section, de sorte que la sortie contient un élément unique nommé database.pool avec les clés à l’intérieur. Les points sont autorisés dans les noms d’élément XML, le document est donc valide ; il est seulement plat là où vous attendiez peut-être de la profondeur.

Si le schéma cible veut un vrai emboîtement, cette structure doit être créée plutôt que convertie. La séquence honnête consiste à convertir d’abord, puis à remodeler le XML résultant en XSLT ou à la main, parce qu’un convertisseur qui devinerait l’imbrication à partir de la ponctuation se tromperait sur chaque fichier INI où un point fait partie d’un nom plutôt que d’être un séparateur — et les fichiers de configuration PHP, où des clés comme date.timezone sont partout, sont exactement ce cas.

INI n’a pas de norme, seulement des conventions, et l’un des points sur lesquels les implémentations divergent est la signification d’un en-tête de section répété. Certaines fusionnent les deux blocs. Ce lecteur ne le fait pas : il crée une section vide neuve à chaque en-tête rencontré, si bien qu’un fichier où [logging] apparaît deux fois ne garde que les clés de la seconde occurrence et perd entièrement le premier bloc, sans erreur.

Les en-têtes répétés sont rares dans les fichiers écrits à la main et fréquents dans les fichiers assemblés par concaténation — une configuration de base à laquelle on a ajouté en queue un surcouche d’environnement, qui est un véritable motif de déploiement. Cherchez dans la source les en-têtes en doublon avant de convertir, parce que la défaillance est silencieuse et que la sortie est un document XML parfaitement bien formé auquel manquent simplement des réglages.

Les deux formats acceptent des commentaires. INI les marque d’un point-virgule ou d’un dièse, XML d’un bloc entre chevrons, et cette conversion n’en transporte aucun : les lignes de commentaire sont ignorées à la lecture et ne réapparaissent jamais. Le registre reconnaît aux deux formats la capacité d’en porter, ce qui fait de la perte un artefact du pipeline plutôt qu’une limitation de la cible.

Sur un fichier de configuration, c’est plus important qu’il n’y paraît. La ligne située au-dessus d’un timeout et expliquant qu’il a été porté à 90 secondes à cause d’un rapport lent est en général le seul endroit où cette décision est documentée. Copiez l’original commenté dans le gestionnaire de versions avant de convertir, et rattachez les explications au XML ensuite ; aucune conversion automatisée de ce type ne peut le faire à votre place.

La raison de cette migration n’est presque jamais la syntaxe. XML 1.0 est une recommandation du W3C depuis 1998, et autour de lui se trouve la machinerie qui a toujours manqué à INI : des schémas XSD qui rejettent une configuration à la moindre clé mal orthographiée avant que l’application ne démarre, XPath pour extraire une seule valeur d’un gros document, XSLT pour le remodeler, et les signatures numériques XML pour affirmer qu’un fichier de configuration n’a pas été modifié.

Rien de tout cela n’arrive avec la conversion. La sortie est un document bien formé, sans schéma attaché et sans espace de noms déclaré, et écrire le schéma est le véritable travail — la conversion ne fait que vous donner un document de départ sur lequel l’écrire. Si vous n’avez pas l’intention de valider, signer ou transformer le résultat, la migration n’achète que de la verbosité et rien d’autre.

Si l’application qui lit le fichier est celle qui l’a écrit, et qu’aucune chaîne en aval n’a besoin d’un schéma, convertir est un coût sans retour. Un fichier INI est éditable par quiconque sait ouvrir le Bloc-notes, et c’est une véritable propriété opérationnelle quand la personne qui modifie un réglage à deux heures du matin n’est pas une développeuse ou un développeur.

La conversion est aussi le mauvais outil si ce dont vous avez réellement besoin est de deux ou trois valeurs extraites du fichier plutôt que du fichier entier. Lisez-les directement. Ce convertisseur existe pour le cas où le fichier INI est la configuration et où la configuration migre, pas pour extraire un fragment.