Convertir XML en INI

L’aplatissement construit un chemin pointé vers chaque valeur du document, puis coupe chaque chemin une fois : la partie avant le premier point devient la section, le reste devient la clé. Un document XML a un seul élément racine, donc ce premier segment est le même pour toutes les valeurs du fichier, et la sortie est une section avec une longue liste de clés pointées en dessous.

Cela mérite d’être su d’entrée, parce que ce n’est pas ce que fait la même conversion depuis YAML ou JSON, où plusieurs clés de premier niveau donnent plusieurs sections. Si vous voulez une section par groupe logique, la voie pratique est de convertir les fragments séparément — une conversion par enfant de la racine — plutôt que d’attendre de l’outil qu’il choisisse quel niveau mérite un en-tête.

Prenons la forme standard .NET : une racine configuration, un élément appSettings, et à l’intérieur plusieurs éléments add portant chacun des attributs key et value. La sortie est une section intitulée configuration, et à l’intérieur des clés lisant appSettings.add.0.@key valant Timeout et appSettings.add.0.@value valant 30, puis le même schéma avec l’index 1 pour l’entrée suivante.

C’est fidèle et ce n’est pas joli. L’information que vous vouliez réellement — Timeout vaut 30 — est répartie sur deux lignes qui ne sont apparentées que par leur index partagé. Si la destination est un script, c’est en général moins de travail de lire les deux lignes et d’écrire Timeout=30 vous-même que d’apprendre au consommateur cette forme. La conversion est surtout utile quand le XML a de vrais noms d’éléments portant de vraies valeurs, et surtout inutile sur le schéma clé-valeur-attribut que .NET privilégie.

Chaque attribut devient un segment de clé préfixé par @, donc un élément avec un attribut id contribue une clé se terminant par @id. Un élément qui porte à la fois des attributs et son propre texte stocke ce texte sous un segment nommé #text, puisque les attributs ont déjà pris la clé de l’élément.

Aucun des deux préfixes n’est une convention INI standard, et aucun parseur INI ne les traitera à part. Ils sont là pour que rien n’entre en collision — un attribut nommé value et un élément enfant nommé value écriraient sinon sur la même clé — et ils sont la première chose à retirer si le fichier est remis à un programme plutôt que lu. Renommer des clés dans la sortie est sûr ; il n’y a plus de structure INI à casser.

Deux frères ou plus avec le même tag deviennent un tableau pendant l’analyse et reçoivent des segments numériques : add.0, add.1, add.2, dans l’ordre du document. L’ordre est préservé, ce qui est la partie qui compte pour une liste de règles ou un chemin de recherche.

Une occurrence unique ne reçoit pas de numéro, parce que l’analyseur n’avait aucun moyen de savoir que l’élément se répète - un seul élément add est un simple objet. Donc la même config avec une entrée et avec deux produit des noms de clés différents, et un script qui cherche appSettings.add.0.@key ne trouve rien le jour où le fichier a un seul paramètre. Écrivez le consommateur pour essayer les deux, ou normalisez les clés après la conversion.

Deux choses dans la sortie décrivent le XML plutôt que vos paramètres. Un document qui s’ouvre par une déclaration de version et d’encodage produit une section intitulée ?xml contenant ces valeurs, et toute déclaration d’espace de noms sur la racine devient une clé comme @xmlns à l’intérieur de la section principale. Aucun des deux ne signifie quoi que ce soit pour un consommateur INI.

Supprimez les deux. Un en-tête de section contenant un point d’interrogation est légal au sens où INI n’a pas de spécification à violer, et il va malgré tout dérouter la personne suivante et possiblement le parseur qui le lira. La valeur d’encodage mérite aussi d’être ignorée plutôt que d’être crue : un attribut lisant 1.0 est analysé comme un nombre et ressort en 1, donc la déclaration dans la sortie ne dit même pas ce que disait l’original.

Un bloc de licence, un script incorporé ou une description mise en forme est un élément tenant plusieurs lignes de texte, et une entrée INI est une seule ligne. Jusqu’au 9 août 2026, l’écrivain émettait ces sauts de ligne tels quels, donc chaque ligne après la première restait dans le fichier sans clé devant elle — écartée à l’aller s’il n’y avait pas de signe égal, et pire s’il y en avait : une ligne ressemblant à un en-tête crocheté ouvrait une section qui n’était dans aucun document XML, et le paramètre suivant était lu à l’intérieur.

L’écrivain enveloppe maintenant une telle valeur entre guillemets et écrit chaque saut de ligne comme une barre oblique inverse suivie d’un n, donc l’élément reste une seule entrée et revient intact à travers ce convertisseur. Cela vaut tout de même la peine de savoir quels éléments dans le XML portent du texte multiligne, parce que le programme que vous alimentez peut lire la barre oblique inverse littéralement. Quand ce programme compte, mettez le bloc dans son propre fichier et laissez l’INI porter le chemin vers lui.

Plus qu’on ne s’y attendrait. Les valeurs conservent leurs points-virgules, leurs barres obliques, leurs espaces et leurs signes égal incorporés, parce que les parseurs INI ne se découpent qu’au premier signe égal — donc une chaîne de connexion lisant Server=db;Database=x survit comme une seule valeur et se relit correctement.

L’ordre des éléments est préservé partout, et la position relative des attributs et des enfants aussi. Les valeurs d’apparence numérique sont analysées à l’aller, ce qui est où sont les exceptions : un attribut version écrit 1.0 devient 1 et un identifiant à zéros initiaux écrit 007 devient 7. Tout ce que vous traitiez comme un jeton opaque mérite d’être vérifié dans la sortie.

Les commentaires sont supprimés, et sur un fichier de paramètres c’est en général le texte le plus précieux présent. Les espaces de noms cessent de signifier quoi que ce soit une fois que les préfixes ne sont plus que des caractères dans un nom de clé. La distinction entre un attribut et un élément enfant ne survit que comme un @ dans une chaîne. Rien dans l’INI ne peut être validé, parce qu’INI n’a pas de langage de schéma.

C’est le résumé honnête du sens : XML est une recommandation du W3C depuis 1998 et porte des schémas, du XPath, des transformations et des signatures ; INI existe depuis 1985 et ne porte que des lignes. Convertir dans ce sens perd tout cela et il n’y a pas de chemin de retour, donc l’original XML appartient au contrôle de version indépendamment de ce qu’il advient de l’INI.

Beaucoup de gens qui arrivent à cette paire veulent une poignée de paramètres, pas un document aplati. Si c’est le cas, lisez-les depuis le XML et tapez-les dans le fichier INI sous la forme attendue par le programme consommateur. Cela prend quelques minutes, le résultat est lisible, et aucun des artefacts ci-dessus n’y apparaît.

Utilisez le convertisseur quand le fichier est assez gros pour que le lire à la main soit là où arrivent les erreurs, ou quand vous voulez un inventaire complet de ce que contient une config d’un fournisseur avant de décider quelles parties comptent. Les deux sont de bonnes raisons. Convertir wholesale une config XML et livrer le résultat comme nouveau fichier de paramètres ne l’est pas.