Convertir XML a INI

El aplanado construye una ruta con puntos hasta cada valor del documento y después parte cada ruta una sola vez: lo que va antes del primer punto es la sección y el resto es la clave. Un documento XML tiene un único elemento raíz, así que ese primer tramo es el mismo para todos los valores del archivo y la salida es una sección con una lista larga de claves con puntos debajo.

Conviene ajustar la expectativa, porque no es lo que hace esta misma conversión partiendo de YAML o de JSON, donde varias claves de primer nivel dan varias secciones. Si quieres una sección por grupo lógico, el camino práctico es convertir los fragmentos por separado —una conversión por cada hijo de la raíz— en vez de esperar que la herramienta decida qué nivel merece encabezado.

Toma la forma estándar: una raíz de configuración, un elemento de ajustes de aplicación y dentro varios elementos de alta que llevan cada uno un atributo de clave y otro de valor. La salida es una sección con el nombre de la raíz, y dentro claves que dicen ajustes.alta.0.@clave con el nombre del ajuste y ajustes.alta.0.@valor con su contenido, y luego el mismo patrón con el índice 1 para la entrada siguiente.

Es fiel y no es bonito. La información que de verdad querías —que el tiempo de espera son treinta segundos— queda repartida en dos líneas que solo están relacionadas por compartir un índice. Si el destino es un script, suele costar menos leer esas dos líneas y escribir la pareja a mano que enseñarle esta forma al consumidor. La conversión rinde cuando el XML tiene nombres de elemento reales con valores reales, y rinde poco con el patrón de clave y valor como atributos que .NET prefiere.

Cada atributo aporta un tramo de clave con una arroba delante, así que un elemento con un atributo de identificador contribuye una clave terminada en @id. Un elemento que lleva a la vez atributos y texto propio guarda ese texto bajo un tramo llamado #text, porque los atributos ya ocuparon la clave del elemento.

Ninguno de los dos prefijos es un convenio de INI y ningún analizador de INI los va a tratar de forma especial. Están ahí para que nada colisione: un atributo llamado valor y un elemento hijo llamado valor escribirían en la misma clave. Y son lo primero que hay que quitar si el archivo va a un programa en lugar de a una persona. Renombrar claves en la salida es seguro; al INI ya no le queda ninguna estructura que romper.

Dos o más hermanos con la misma etiqueta se convierten en un array al interpretar el XML y reciben tramos numéricos: cero, uno, dos, en el orden del documento. El orden se conserva, que es la parte importante para una lista de reglas o para una ruta de búsqueda.

Una sola aparición no recibe número, porque el analizador no tenía forma de saber que ese elemento se repite: un elemento suelto es simplemente un objeto. Así que la misma configuración con una entrada y con dos produce nombres de clave distintos, y un script que empareje con el índice cero no encuentra nada el día que el archivo tiene un solo ajuste. Escribe el consumidor para probar las dos formas, o normaliza las claves después de convertir.

Dos cosas de la salida describen el XML y no tus ajustes. Un documento que empieza con la línea de versión y codificación produce una sección propia encabezada por un signo de interrogación con sus valores dentro, y cualquier declaración de espacio de nombres sobre la raíz se convierte en una clave con arroba dentro de la sección principal. Ninguna de las dos significa nada para quien lea el INI.

Bórralas. Un encabezado de sección con un signo de interrogación es legal en el sentido de que el INI no tiene especificación que violar, y aun así va a confundir a la siguiente persona y posiblemente al analizador que lo lea. El valor de la codificación tampoco merece confianza: un atributo escrito 1.0 se interpreta como número y sale como 1, así que la declaración de la salida ni siquiera dice lo que decía el original.

Un bloque de licencia, un script incrustado o una descripción con formato son un elemento con varias líneas de texto, y una entrada de INI es una línea. Hasta el 9 de agosto de 2026 el escritor emitía esos saltos tal cual, así que toda línea posterior a la primera quedaba en el archivo sin ninguna clave delante.

Lo peor no era el valor truncado. Una de esas líneas sueltas con corchetes se leía de vuelta como el encabezado de una sección que no existía en ningún XML, y el siguiente ajuste legítimo se recogía dentro de esa sección inventada: una cadena en un campo movía en silencio a un campo hermano a otro objeto. Está medido en el propio código y sostenido por una prueba, con un ejemplo en el que una nota de bienvenida fabricaba una sección de administración con una contraseña dentro.

El escritor envuelve ahora ese valor entre comillas y escribe cada salto de línea como una barra invertida seguida de una ene, de modo que el elemento sigue siendo una sola entrada y vuelve intacto a través de este conversor. Se escapan únicamente la barra invertida, el salto de línea y el retorno de carro; ningún otro carácter de un valor puede romper un analizador orientado a líneas.

El escape se deshace solo cuando el valor venía entrecomillado, y ese detalle es deliberado. El INI es un formato de Windows y lo más común dentro de uno es una ruta sin comillas, así que desescapar siempre habría leído una línea escrita a mano con una ruta como si tuviera un salto de línea dentro: una corrupción nueva introducida por el arreglo de otra. Aun así, conviene saber qué elementos de tu XML llevan texto multilínea, porque el programa al que alimentas puede leer la barra invertida literalmente. Si ese programa importa, pon el bloque en su propio archivo y deja que el INI lleve solo la ruta.

Más de lo que uno esperaría. Los valores conservan sus puntos y comas, sus barras, sus espacios y sus signos de igual incrustados, porque el analizador de INI parte por el primer signo de igual y solo por ése. Una cadena de conexión con varios parámetros separados por punto y coma sobrevive como un único valor y se vuelve a leer correctamente.

También un marcador de comentario en mitad de una línea: el punto y coma y la almohadilla solo abren un comentario al principio de la línea, así que dentro de un valor son caracteres corrientes. Y el orden de los elementos se conserva de principio a fin, igual que la posición relativa de atributos e hijos.

Los valores con pinta de número se interpretan como números al leer el XML, y ahí están las excepciones que duelen. Un atributo de versión escrito 1.0 sale como 1. Un identificador escrito 007 sale como 7. Un código postal de Barcelona escrito 08001 sale como 8001, y ninguno de los tres provoca un error.

Es el mismo comportamiento que en las otras conversiones que salen de XML en este sitio, y en un archivo de configuración pica de una forma concreta: los números de puerto están bien, las versiones de protocolo no, y los identificadores de licencia o de instalación con ceros delante quedan mal. Repasa en la salida cualquier valor que trataras como una cadena opaca antes de dárselo a nada.

Los comentarios se descartan, y en un archivo de ajustes suelen ser el texto más valioso que hay. Los espacios de nombres dejan de significar nada en cuanto los prefijos son solo caracteres dentro de un nombre de clave. La diferencia entre un atributo y un elemento hijo sobrevive únicamente como una arroba en una cadena. Y en el INI no se puede validar nada, porque el INI no tiene ningún lenguaje de esquema.

Ése es el resumen honesto de la dirección. El XML es una recomendación del consorcio de la web desde 1998 y viene acompañado de esquemas, rutas de consulta, transformaciones y firmas; el INI existe desde 1985 y no lleva más que líneas. Convertir en este sentido lo deja todo atrás y no hay vuelta, así que el XML original pertenece al control de versiones pase lo que pase con el INI.

Muchísima gente que llega a este par quiere un puñado de ajustes, no un documento aplanado. Si es tu caso, léelos del XML y escríbelos en el INI con la forma que espera el programa que los va a consumir. Se tarda unos minutos, el resultado es legible y no aparece en él ninguno de los artefactos de esta página.

Usa el conversor cuando el archivo sea lo bastante grande como para que leerlo a mano sea justo de donde salen los errores, o cuando quieras un inventario completo de lo que contiene la configuración de un proveedor antes de decidir qué partes importan. Los dos son buenos motivos. Convertir un XML entero y entregar el resultado como el nuevo archivo de ajustes, no.

El analizador de XML y el escritor de INI funcionan los dos dentro de esta página, en JavaScript corriente y sin descargar ningún motor. No se sube nada, no hay cuenta y no hay cupo diario; el panel de red del navegador durante una conversión es la forma de comprobarlo en diez segundos.

Con este tipo de archivo eso deja de ser un detalle. Una configuración de aplicación lleva con frecuencia cadenas de conexión con usuario y contraseña, claves de servicios y rutas internas, y subirla a un conversor para recuperarla en otro formato es entregarle todo eso a un tercero a cambio de un aplanado. El límite gratuito es de 100 MB por archivo, que ninguna configuración va a rozar, y se pueden soltar hasta cien de una vez.