¿Qué es un archivo INI?

INI es un formato de texto plano que se abre en cualquier editor. Se usa para la edición.

La extensión es .ini y el nombre completo, INI Configuration. Ambos importan menos que lo que el archivo puede contener, y de eso trata el resto de esta página.

Se remonta a 1985.

A un formato que lleva tanto tiempo siendo legible se le puede confiar algo que quieras recuperar dentro de diez años.

Está publicada entera, así que cualquiera puede implementarla leyendo el documento en vez de a base de inspeccionar archivos. Por eso aparece en tantos programas, y por eso los archivos escritos hace veinte años siguen abriéndose hoy. Publicada no quiere decir libre de regalías: cuando un formato envuelve un códec, la licencia de las patentes es un asunto aparte que la norma no resuelve.

Sigue abriéndose en todas partes y los programas antiguos aún lo escriben, pero ya no se construye nada nuevo a su alrededor. Convierte lo que quieras conservar y no lo elijas para algo que empieza hoy.

INI tiene sintaxis de comentarios, que es la diferencia entre un archivo que mantiene una persona y uno que escribe un programa. Los comentarios son lo primero que se pierde al convertir a un formato que no los tiene, y nada te avisa.

Notepad y Visual Studio Code lo leen, y también la mayoría de programas del mismo tipo.

Cuando un archivo no se abre, el formato rara vez es el problema: lo más habitual es que el programa sea anterior al formato. Convertir a algo más antiguo es la salida fiable, y para eso está el resto de este sitio.

Ningún navegador lo lee.

Ese es el motivo más frecuente para convertirlo: no que el formato sea malo, sino que el sitio donde quieres mostrar el archivo no sabe leerlo.

INI está pensado para abrirse y cambiarse. Guarda el archivo en este formato mientras el trabajo siga en marcha y exporta desde él cada vez que haga falta una copia terminada.

INI viene de los primeros Windows, donde guardaba la configuración del sistema y la de cada aplicación. Nunca se estandarizó: ningún documento lo define, ningún comité lo tutela, y cada programa que lee uno implementa su propio dialecto.

El núcleo sí es universal: encabezados de sección entre corchetes y, debajo, líneas de clave igual a valor. Todo lo que va más allá de ese núcleo es una moneda al aire. Si el comentario empieza por punto y coma o por almohadilla. Si un valor puede ir entre comillas y qué pasa con esas comillas. Si las claves distinguen mayúsculas. Si un valor puede continuar en la línea siguiente. Si las secciones se anidan, cosa que en casi ningún dialecto ocurre. Dos programas pueden leer el mismo archivo y discrepar legítimamente, y los dos tienen razón.

Escribe timeout=30 y en el archivo hay un 3 y un 0. Que eso se convierta en un número, y que signifique segundos o milisegundos, lo decide íntegramente el programa que lo lee. Lo mismo vale para true, yes, on y 1, todas ellas maneras habituales de escribir un booleano, ninguna definida por el formato y cada biblioteca aceptando un subconjunto distinto.

Esa es la diferencia práctica con JSON, YAML o TOML, que sí tienen tipos. Explica por qué los archivos INI vienen casi siempre acompañados de documentación o de comentarios que aclaran qué significan los valores, y por qué mover un archivo de configuración entre dos implementaciones del mismo programa es más peligroso de lo que parece.

En Windows, todavía, en varios sitios: el desktop.ini que decide cómo se muestra una carpeta, configuración de arranque y de controladores, y una cola larga de aplicaciones que nunca han tenido motivo para cambiar. Los videojuegos son una fuente especialmente abundante: un número enorme de juegos de PC guarda sus ajustes de gráficos y de controles en un INI, que es la razón de que las guías de configuración estén llenas de instrucciones para editar uno.

Fuera de ahí sobrevive en herramientas anteriores a las alternativas modernas: el php.ini de PHP, la configuración de Git, el setup.cfg de Python y sus utilidades de empaquetado, las unidades de systemd y un sinfín de programas pequeños. Los proyectos nuevos tienden a elegir TOML o YAML, pero nada de lo ya instalado se va a reescribir.

Con cualquier editor de texto. Dos reglas evitan casi todo el daño que se suele hacer: copia el archivo antes de tocarlo y cambia una sola cosa cada vez, porque un programa que no arranca por culpa de su configuración rara vez dice a qué línea puso pegas.

Después vienen los detalles que provocan fallos de verdad. Guarda en UTF-8 sin marca de orden de bytes, porque esos bytes invisibles al principio del archivo rompen el primer encabezado de sección en muchos analizadores. No añadas espacios alrededor del signo igual salvo que sepas que el lector los recorta, porque hay lectores que no lo hacen y tu valor pasa a empezar por un espacio. Y no toques las comillas: si los valores existentes van sin ellas, ponerlas puede añadir dos caracteres al valor en lugar de delimitarlo.

Ser evidente. Una persona que no ha visto el archivo en su vida puede abrirlo, encontrar el ajuste que se llama fullscreen, cambiar false por true y acertar. Eso es una propiedad real y es la razón de que el formato haya sobrevivido a todo lo que se diseñó en los noventa para sustituirlo.

También falla con elegancia en el caso superficial: una clave desconocida suele ignorarse en lugar de ser fatal, así que un archivo escrito para una versión más nueva del programa normalmente sigue funcionando en una más vieja. Las alternativas son más estrictas, lo cual es mejor para la corrección y peor para quien está ajustando un juego a medianoche.

Cuando la configuración se ha ido más allá de secciones planas de cadenas de texto. Estructura anidada, listas, fechas, números que necesitan ser números, o cualquier valor donde la diferencia entre la cadena "false" y el booleano false importe: ahí es donde INI deja de ayudar y empieza a esconder errores.

TOML se diseñó precisamente como respuesta a eso: se parece a INI, así que nadie tiene que aprender una forma nueva, y tiene especificación, tipos reales y anidamiento definido. YAML es el otro destino habitual, más potente y bastante más fácil de estropear. Si un archivo está a punto de crecer, TOML es el paso más corto y el que conserva la legibilidad que hacía útil a INI.

INI no tiene dónde poner un objeto dentro de otro, así que al convertir hacia él la estructura se aplana: cada valor final se convierte en una clave cuyo nombre es la ruta completa separada por puntos, y los índices de un array son un tramo más de esa ruta. Un JSON con servidor.base.puerto acaba siendo literalmente una clave llamada así.

Es una decisión consciente y tiene consecuencias que conviene ver antes de convertir. El archivo resultante es correcto y legible, pero ya no es la misma forma: quien lo lea después verá claves largas y planas donde había un árbol, y volver atrás exige que alguien decida que los puntos significaban anidamiento. Los mismos destinos aplanados son CSV, TSV, SQL, XLSX y Parquet; JSON, YAML, TOML, XML y NDJSON conservan el árbol.

Al leer un INI aquí, los comentarios se descartan de forma explícita. No es un descuido: en un archivo de configuración el comentario suele ser la única documentación que hay, así que si lo que tienes delante es el INI comentado de un programa y lo conviertes a otro formato, quédate también con el original. Ninguno de los formatos de configuración de esta web conserva comentarios, ni YAML, ni TOML, ni XML, porque todos se convierten en valores planos sin un canal donde guardarlos.

El orden de las claves, en cambio, se mantiene tal cual: nada ordena alfabéticamente por su cuenta. Eso importa más de lo que parece cuando el archivo va a compararse con otra versión de sí mismo, porque un reordenamiento silencioso convierte un cambio de una línea en un diff ilegible.