Convertir INI a XML

El archivo se recorre línea a línea. Las líneas vacías y las que empiezan por punto y coma o por almohadilla se descartan; una línea entre corchetes abre una sección; el resto se parte por el primer signo igual en clave y valor. Si el valor viene entre comillas, se le quitan. El resultado es un objeto: las claves sueltas del principio quedan en la raíz y cada sección se convierte en un objeto hijo con su nombre.

Ese objeto es el único punto de encuentro entre los dos formatos. El escritor de XML no ve un INI, ve una estructura, y todo lo que esta página hace o deja de hacer se explica por lo que cabe en ella. El analizador está escrito a mano y no viene de un paquete, porque las bibliotecas de INI no se ponen de acuerdo ni sobre qué carácter abre un comentario.

Un documento XML necesita exactamente un elemento raíz y un INI no tiene ninguno. La regla que se aplica es sencilla: si al leer el archivo queda una sola clave de primer nivel, ésa se convierte en la raíz; si queda más de una, todo se envuelve en un elemento llamado root.

En la práctica eso significa que un INI con una única sección produce un XML cuya raíz lleva el nombre de esa sección, y que un INI con tres secciones —o con una clave suelta antes de la primera sección— produce un root con tres hijos. Merece la pena mirar la primera línea del resultado antes de meterlo en un validador que espera una raíz concreta.

Ésta es la que hay que saber si el archivo está escrito en castellano. Un nombre de elemento se depura antes de escribirlo: todo lo que no sea una letra sin tilde de la A a la Z, un dígito, un guion bajo, un punto o un guion se sustituye por un guion bajo. Una sección llamada [Configuración] sale como el elemento Configuraci_n, y una clave contraseña sale como contrase_a.

También se depuran los espacios y los comienzos que no son válidos: [Datos del cliente] se convierte en Datos_del_cliente, y una clave que empiece por un dígito recibe un guion bajo delante, porque un nombre de elemento XML no puede empezar por número. Nada de esto rompe el archivo —el XML resultante es válido y se abre en cualquier parte—, pero si otro programa espera encontrar la etiqueta con su tilde, no la va a encontrar.

La depuración se aplica solo a los nombres. En el contenido de los elementos únicamente se escapan los cuatro caracteres que XML no permite tal cual —ampersand, menor que, mayor que y comillas dobles—, así que una tilde, una eñe, una diéresis, un signo de apertura de interrogación o un símbolo de euro pasan intactos.

Es una asimetría que confunde si no se conoce: el mismo archivo puede tener el valor «Dirección de envío» perfectamente escrito dentro de un elemento llamado Direcci_n. Si la etiqueta importa, la solución es renombrar la sección en el INI con letras sin tilde antes de convertir, no arreglar el XML después.

Todo lo que empieza por punto y coma o por almohadilla se descarta al leer, y el escritor de XML no emite comentarios en ningún caso. Un archivo de configuración documentado línea a línea sale convertido en datos limpios sin una sola explicación.

Ocurre en las cuatro direcciones de esta familia: YAML, TOML, INI y XML pierden los comentarios al convertirse en cualquiera de los otros, porque el valor al que se analizan no tiene un canal donde guardarlos. Si los comentarios eran la mitad del valor del archivo —y en una configuración suelen serlo—, conserva el INI original en lugar de sustituirlo por el XML.

Un INI es texto puro y la lectura decide tipos: true y false se convierten en booleanos y cualquier cosa que se interprete como un número finito se convierte en número. Suena inofensivo y tiene tres consecuencias muy concretas.

Un código escrito como 007 se convierte en el número 7 y pierde los ceros a la izquierda. Un valor 1.0 se convierte en el número 1 y sale escrito como 1, sin el decimal, así que una cadena de versión deja de parecerlo. Y —esto es puramente nuestro— un valor escrito con coma decimal, 1,5, no se interpreta como número y se queda tal cual como texto, mientras que 1.5 sí se convierte. Si el INI lo escribió una herramienta con configuración regional española, el mismo campo puede acabar tipado de dos maneras distintas en dos archivos.

El escritor de XML sigue una convención: una clave que empieza por arroba se escribe como atributo del elemento en lugar de como elemento hijo, y una clave llamada #text se escribe como el texto del propio elemento. Es la misma convención con la que se leen los XML en la dirección contraria, de modo que una ida y vuelta devuelve el documento de partida.

En un INI eso se puede aprovechar deliberadamente: una línea @id=17 dentro de una sección produce un atributo id="17" en el elemento correspondiente. Y también se puede tropezar con ello sin querer, si el archivo usaba la arroba por otro motivo. Merece la pena mirarlo si tu INI tiene claves con símbolos delante.

Cada cabecera entre corchetes crea un objeto nuevo y lo coloca en la raíz bajo ese nombre. Si el archivo repite una cabecera —[usuario] dos veces, por ejemplo—, la segunda sustituye a la primera y las claves de la primera no llegan al XML.

La duplicación no es frecuente en archivos escritos a mano, pero aparece al concatenar dos configuraciones o al pegar un fragmento de documentación dentro de un archivo existente. Si el número de elementos del XML no cuadra con el número de secciones que creías tener, ésa es la primera causa que hay que descartar.

Una línea que no es una cabecera de sección y no contiene ningún signo igual se salta en silencio. Es lo que permite sobrevivir a archivos con una línea suelta de encabezado o con restos de una edición a medias.

Del lado bueno, el orden se respeta escrupulosamente: nada ordena las claves ni las secciones en ningún punto del camino, así que el XML sale en el mismo orden en que estaba escrito el INI. Eso hace que comparar los dos archivos con un visor de diferencias sea una manera rápida de comprobar que no falta nada.

INI es un formato de Windows y las rutas de Windows van llenas de barras invertidas, que en casi cualquier otro sitio significan un escape. Aquí la lectura las respeta: un valor sin comillas se toma exactamente como está escrito, así que ruta=C:\nuevo llega íntegro y no se convierte en una ruta con un salto de línea en medio.

El escape solo se aplica a los valores que nosotros escribimos y solo cuando hace falta, y en ese caso el valor va entre comillas para que al releerlo se recupere el mismo texto. Es una asimetría deliberada: los archivos escritos a mano son los que hay que respetar tal cual, y los que generamos nosotros son los que podemos permitirnos citar.

Los cuatro formatos de árbol de esta familia se convierten entre sí y todos conservan la estructura de secciones que sale de leer el INI. JSON, YAML, TOML y XML tienen todos dónde guardar un objeto dentro de otro, así que la elección entre ellos es de destino y de gusto, no de pérdida.

La dirección incómoda es la contraria. INI no tiene anidamiento: cualquier estructura de más de un nivel que se convierta hacia INI se aplana en claves con puntos, y eso no se deshace después. Si estás moviendo configuración entre sistemas y en algún punto pasa por un INI, ése es el paso donde se pierde la forma.

Esta conversión es JavaScript normal dentro de tu pestaña: no hay módulo WebAssembly que bajar y no hay servidor de por medio. Un archivo de configuración es de las cosas que menos deberían subirse a una página web —lleva rutas internas, nombres de servidor, a veces credenciales— y aquí sencillamente no se transmite.

El tope por archivo son 100 MB, que un INI no alcanza jamás, y puedes soltar hasta cien archivos de una vez para que vuelvan juntos en un ZIP. Es lo razonable cuando lo que estás migrando es la configuración de una flota de equipos y no un archivo suelto.