Convertir INI a JSON

El resultado es un único objeto JSON. Cada encabezado de sección se convierte en una clave que contiene un objeto propio, y los pares clave-valor bajo ese encabezado pasan a ser sus propiedades. Las claves escritas antes de cualquier encabezado —lo que muchas herramientas llaman el bloque global— quedan en el nivel superior, junto a los objetos de sección y no dentro de un envoltorio.

Esa es toda la traducción estructural, porque en un INI no hay nada más que traducir. Lo que hace interesante a este par no es la forma sino los valores, que no cruzan tan literalmente como la forma.

Un INI no tiene tipos: todo lo que sigue al signo igual son caracteres, y cada programa que lo lee decide por su cuenta qué significan. Este lector decide así: las cadenas exactas «true» y «false» pasan a ser booleanos JSON, cualquier cosa que se interprete como un número finito pasa a ser un número JSON, y todo lo demás se queda como texto.

Para la mayoría de la configuración es la decisión correcta y te ahorra una pasada de conversión al otro lado: un puerto sale como 8080 y no como «8080», un tiempo de espera como 30, y una bandera negativa como un número comparable. El coste es que el lector no distingue una cantidad de un identificador, y ahí es donde se produce el daño.

Cuatro casos fallan en silencio y los cuatro aparecen en ficheros reales. Un identificador con ceros a la izquierda escrito 007 se convierte en el número 7. Un código postal escrito 08001 —Barcelona— se convierte en 8001, y con él se va la provincia. Un modo de fichero de Unix escrito 0755 se convierte en 755, que es un modo distinto y se aplicará como tal. Una máscara hexadecimal escrita 0x1F se convierte en 31: correcta en valor y equivocada en cada línea de registro que la imprima de vuelta.

Y hay un quinto que sorprende: un teléfono guardado como +34600123456 sale como el número 34600123456, sin el signo más, porque el signo delante de las cifras es parte de la notación numérica. Un DNI escrito con su letra, 12345678Z, se salva justamente por la letra. Si una clave guarda un identificador, un número de serie o una referencia de cuenta, revísala en la salida antes de fiarte de ella.

Aquí hay una asimetría que conviene tener presente. Un precio escrito 1,50 se queda como el texto «1,50», porque para el conversor una coma no es un separador decimal. El mismo precio escrito 1.50 se convierte en el número 1.5, y de paso pierde el cero final si alguien lo estaba usando para dar formato.

Es una salvaguarda involuntaria y no un diseño: te protege de que un importe se convierta en número, y a cambio te deja un fichero de configuración donde unas cantidades son números y otras cadenas según cómo las escribiera quien las puso. Si el consumidor del JSON va a hacer aritmética con esos valores, unifícalos antes de convertir en lugar de descubrirlo en producción.

El caso más sutil es el de los enteros grandes. Los números de JSON son de coma flotante de doble precisión, así que un entero por encima de unos nueve mil billones pierde precisión: un identificador de 64 bits escrito 9223372036854775807 sale como 9223372036854776000. Nada avisa.

La solución más segura no es entrecomillar el valor en el INI, porque los valores entrecomillados también se interpretan: es añadirle algo no numérico, o corregirlo en el JSON después. Si el fichero guarda identificadores de una plataforma que los emite de 64 bits, esa clave merece una comprobación explícita y no una confianza.

Conviene saber qué claves no hace falta revisar. Cualquier cosa con una unidad pegada está a salvo: un límite de memoria escrito 128M sigue siendo el texto «128M». Las direcciones con puntos siguen siendo texto, así que 127.0.0.1 pasa sin tocar. Las horas como 08:00 se quedan en texto, igual que las rutas, las direcciones web y cualquier cosa que contenga una letra que no forme parte de un número.

Un valor con un signo igual también sobrevive, porque la línea se parte solo en el primer igual, lo que mantiene intacta una cadena de conexión o un parámetro de consulta. Las comillas que rodean un valor se quitan, pero solo el par exterior, y solo dentro de esas comillas una barra invertida inicia un escape. Por eso una ruta de Windows sin comillas se lee exactamente como está escrita y la misma ruta entrecomillada no.

Los ficheros INI de Windows y la configuración de PHP usan «On» y «Off» mucho más a menudo que «true» y «false», y el lector no los trata como booleanos: salen como las cadenas «On» y «Off». Es defendible —al fin y al cabo son palabras— y casi nunca es lo que espera quien consume el JSON.

Lo mismo vale para «yes» y «no», y para el 1 y el 0 usados como banderas, que salen como números y no como booleanos. Quien lea el JSON tendrá que decidir qué cuenta como verdadero, y la costumbre más segura es normalizar esas claves explícitamente en el código consumidor. Una configuración con un motor en «On» y una depuración en false tiene ya dos maneras distintas de decir que sí.

El orden se conserva casi siempre, lo que importa cuando lo que vas a leer es una comparación entre versiones y no una máquina. Las secciones salen en el orden en que aparecían y las claves dentro de cada sección mantienen el suyo.

La excepción son las claves numéricas. Un objeto de JavaScript coloca primero las claves que parecen enteros y en orden numérico ascendente, por delante de todas las demás, así que una sección escrita con 10, 2 y «nombre» sale como 2, 10 y «nombre». Los INI que usan números como clave —listas de servidores, reglas ordenadas, entradas de una lista de reproducción— salen reordenados. Si el orden es el significado, esa sección quiere ser un array de JSON, y convertirla es una edición manual.

INI no tiene especificación, así que las implementaciones discrepan sobre los encabezados repetidos: unas los fusionan, otras conservan los dos, otras se quedan con el último. Este lector empieza una sección nueva y vacía cada vez que encuentra un encabezado, de modo que un fichero con dos bloques del mismo nombre conserva solo las claves del segundo. El primero desaparece, el JSON es válido y nada lo señala.

Ese patrón aparece siempre que la configuración se ensambla por concatenación, que es una técnica de despliegue habitual: un fichero base más una capa de entorno, añadida al final. Busca encabezados duplicados en el origen antes de convertir. Las claves repetidas dentro de una misma sección se comportan igual, y gana la última asignación.

Esta es la pérdida estructural y no accidental. INI admite comentarios y los usa mucho; JSON, tal como está especificado, no tiene ninguna sintaxis de comentario. Ni siquiera un conversor que quisiera conservarlos tendría dónde ponerlos, salvo inventando una convención que ningún consumidor leería.

En un fichero de ajustes eso suele ser lo más grande que se pierde. La nota que explica por qué un tamaño de pool es 12 y no el valor por defecto, el bloque comentado guardado como ejemplo, la línea que marca un valor como ajustado para un cliente concreto: nada de eso cruza. Guarda el INI original en el control de versiones junto al JSON en lugar de tratar la conversión como una sustitución.

Un encabezado escrito con puntos dentro, del estilo de los que usan algunas herramientas modernas, no produce objetos anidados: la cadena entre corchetes entera es un nombre de sección, así que obtienes una única clave que literalmente contiene ese punto. INI tiene un nivel de agrupación y ninguna forma de expresar más.

Si lo que quieres es una jerarquía real, el origen equivocado es el INI y el formato correcto es TOML o YAML, que sí la expresan. Convertir desde ellos evita además tener que deshacer a mano esa clave con punto en el otro lado, que es una tarea que se olvida justo hasta que un despliegue lee la ruta que no existe.

La salida es JSON corriente con sangría de dos espacios, así que lo leen sin ceremonia las herramientas de línea de órdenes, cualquier lenguaje y cualquier validador de esquema. Una sección se convierte en una ruta de objeto, y un esquema puede entonces exigir que el puerto sea un número y el host una cadena, que es la ganancia real sobre el INI, porque un INI no lo puede validar nada.

La lectura y la escritura son código ejecutándose en esta página, así que el fichero no sale de tu equipo. En este par eso importa más que en casi ningún otro: los ficheros INI guardan de forma rutinaria contraseñas de bases de datos, claves de API y cadenas de conexión, y subir uno a un conversor cualquiera equivale a publicarlas. La restricción práctica aquí no es el tamaño sino la revisión: lee una vez los valores numéricos de la salida, antes de que el JSON pase a ser el fichero en el que todo lo demás confía.