Un archivo INI es un archivo de configuración para software de computadora que consta de un contenido basado en texto con una estructura y sintaxis que comprende pares clave-valor para propiedades y secciones que organizan las propiedades. [1] El nombre de estos archivos de configuración proviene de la extensión de nombre de archivo INI , para inicialización , utilizada en el sistema operativo MS-DOS que popularizó este método de configuración de software. El formato se ha convertido en un estándar informal en muchos contextos de configuración, pero muchas aplicaciones en otros sistemas operativos utilizan diferentes extensiones de nombre de archivo, como conf y cfg . [2]
El mecanismo principal de configuración de software en Windows era originalmente un formato de archivo de texto que constaba de líneas de texto con un par clave-valor por línea, organizadas en secciones. Este formato se utilizó para componentes del sistema operativo, como controladores de dispositivos, fuentes y lanzadores de inicio. Las aplicaciones también utilizaban generalmente los archivos INI para almacenar configuraciones individuales. [3]
El formato se mantuvo en plataformas Microsoft Windows de 16 bits hasta Windows 3.1x . A partir de Windows 95, Microsoft favoreció el uso del Registro de Windows y comenzó a alejar a los desarrolladores del uso de archivos INI para la configuración. Todas las versiones posteriores de Windows han utilizado el Registro de Windows para la configuración del sistema, pero las aplicaciones creadas en .NET Framework utilizan archivos XML .config especiales . Las funciones del archivo de inicialización todavía están disponibles en Windows y los desarrolladores aún pueden usarlas.
Además del software de Windows, el software independiente de la plataforma puede utilizar este formato de archivo para la configuración. Algunos archivos de configuración similares a Unix también utilizan un formato similar. INI es legible por humanos y fácil de analizar, por lo que es un formato utilizable para archivos de configuración que no requieren mucha mayor complejidad.
Lo que sigue es una lista no exhaustiva de lugares en los que aparecen los archivos .INI.
El siguiente archivo de ejemplo tiene dos secciones: una para el propietario del software y otra para una conexión a la base de datos de nómina. Los comentarios registran la última persona que modificó el archivo y el motivo de la modificación.
; última modificación el 1 de abril de 2001 por John Doe [propietario] nombre = John Doe organización = Acme Widgets Inc. [base de datos] ; use la dirección IP en caso de que la resolución del nombre de la red no funcione servidor = 192.0.2.62 puerto = 143 archivo = "payroll.dat"
En su sentido más amplio, .INI es un formato informal que se presta bien a la implementación ad hoc sin dejar de ser configurable por humanos. En consecuencia, existen muchas especificaciones variables (donde a veces la implementación de un analizador es la única especificación jamás escrita), llamadas dialectos .INI .
Mientras que las interpretaciones de .INI dependen mucho del gusto personal y del entorno informático (por ejemplo: la necesidad de datos exactos en espacios en blanco; la necesidad de información de tipo de campo; Windows prefiere el plegado de mayúsculas y minúsculas, Unix prefiere la sensibilidad entre mayúsculas y minúsculas; #
-comentarios demarcados tomados prestados de scripts de Unix) , lo que hace que .INI sea propenso a la proliferación, existe un núcleo duro con el que normalmente se asocia el sabor .INI : basado en texto y en líneas, se eliminan los espacios en blanco, las líneas vacías y las líneas de comentarios (por ejemplo ; registers to system-wide mailcap
, # workaround for d5cb328
), se ignoran, los corchetes indican secciones (p. ej [Unit]
., [branch "master"]
), datos como pares clave-valor a menudo demarcados con un signo igual (ASCII 0x3D) (p. ej IconFile=Folder.ico
., time machine = yes
).
Existen intentos de crear analizadores capaces de soportar tantos dialectos como sea posible, [13] y en su interpretación más complicada, el formato .INI es capaz de expresar expresiones S arbitrarias , lo que lo hace equivalente a formatos estandarizados como XML o JSON , aunque con una sintaxis que no está escrita en piedra y que para algunos puede resultar más cómoda.
Como el formato de archivo .INI no está definido de forma rígida, muchos analizadores admiten funciones más allá de las que forman el núcleo común. El soporte implementado es altamente volátil.
Los datos en .INI se guardan en pares clave-valor llamados clave o propiedad . Por lo tanto, la clave puede referirse a todo el par clave-valor o solo a su clave. Un valor también se llama nombre de propiedad . En su representación textual, el par clave-valor está representado por una línea o una línea múltiple donde el inicio del valor se indica mediante un delimitador , generalmente un signo igual ( =
, ASCII 0x3D) pero a veces también dos puntos ( :
, ASCII 0x3A ). ) o espacios en blanco (usados ocasionalmente en el mundo GNU [13] ). La clave de la clave aparece a la izquierda del delimitador, a menudo no está vacía y no debe contener el delimitador. Algunos tipos permiten secuencias de escape en el valor.
En la implementación de Windows, el signo igual y el punto y coma son caracteres reservados y no pueden aparecer en la clave. El analizador elimina cualquier espacio en blanco que rodee la clave. El valor puede contener cualquier carácter (en el estilo de Windows, ningún espacio en blanco rodea el delimitador: por ejemplo IconFile=Folder.ico
).
Los pares clave-valor pueden verse textualmente así:
clave = clave = v nombre = valor sem = ; semver = v5822.433.2
Los pares clave-valor se pueden agrupar en una sección . Algunos dialectos .INI requieren que cada par clave-valor esté en una sección, algunos permiten las llamadas propiedades globales . [14] Cuando se agrupan pares clave-valor, el nombre de la sección aparece en una línea sola, entre corchetes ( [
, ASCII 0x5B y ]
, ASCII 0x5D) y se aplica a todos los pares clave-valor en líneas posteriores hasta otra sección. está declarado. No existe un delimitador explícito de "fin de sección" (como, por ejemplo, XML </tag>
. Por lo tanto, las secciones sintácticamente no se pueden anidar arbitrariamente. Cuando sea necesario, el anidamiento se puede implementar aplanando la jerarquía y concatenando con un carácter delimitador personalizado dentro del nombre de la sección (a menudo .
, ASCII 0x2E). A menudo se admite un nivel de anidamiento, denominado subsecciones .
Documento .INI de ejemplo que emplea secciones anidadas:
[proyecto] nombre = servicio de alquiler de huertos (con aplicación) región de destino = "Área de la Bahía" ; TODO: anunciar puestos vacantes equipo legal = (vacante) [fruta "Apple"] problemas de marca = sabor previsible = conocido [fruit.Date] sabor = novela Problemas de marcas comerciales = "realmente improbable" [fruta "Frambuesa"] problemas previstos = "logística (fruta frágil)" Problemas de marcas = \ posibles [fruit.raspberry.proponents.fred] fecha = 2021-11-23, 08:54 +0900 comentario = "Me gustan las frutas rojas". [fruta "Fecha/proponentes/alfred"] comentario : Vaya, \ \ \ Compraría dátiles. # plegado: ¿Se interpreta "\\\\\nn" como "\\n" o "\n"? # ¿O "\\\\" impide el plegado? editor = Mi nombre puede contener una \ \ nueva línea.
Algunos analizadores permiten el anidamiento de secciones, utilizando puntos como delimitadores de ruta:
[sección] dominio = ejemplo.com [sección.subsección] foo = barra
En algunos casos, también se admite el anidamiento relativo, donde un punto inicial expresa el anidamiento con la sección anterior: [13]
[sección] dominio = ejemplo.com [.subsección] foo = barra
Históricamente, también han existido formas de expresar el anidamiento alternativo al punto (por ejemplo, el archivo de controlador de IBM para Microsoft Windows devlist.ini
, en el que la barra invertida se utilizaba como delimitador de anidamiento en forma de [A\B\C]
; o el archivo de Microsoft Visual Studio AEMANAGR.INI
, que utilizaba una sintaxis completamente diferente). en forma de [A]
y B,C,P = V
). Algunos analizadores no ofrecían ningún soporte de anidamiento y eran ciegos a la jerarquía, pero el anidamiento aún podía emularse parcialmente explotando el hecho de que [A.B.C]
constituye un identificador único.
Los nombres de secciones y propiedades en Windows no distinguen entre mayúsculas y minúsculas . [15] La mayoría de las interpretaciones .INI de estilo Unix prohíben por completo el plegado de mayúsculas y minúsculas, aunque a veces se permite el plegado de mayúsculas y minúsculas para el nombre de la sección [16] o la clave [17] .
Una línea con espacios en blanco contiguos seguidos de un punto y coma ( ;
, ASCII 0x3E) indica un comentario . Algunos dialectos .INI además permiten el uso del signo numérico ( #
, ASCII 0x23) para indicar un comentario, reflejando los comentarios del shell de Unix . Algunos dialectos .INI, pero no todos, permiten un comentario en una línea de par clave-valor o línea de sección (llamada comentario en línea ), donde algunos requieren espacios en blanco que separan el valor o el corchete de cierre de sección del comentario. No obstante, es posible que el signo numérico se incluya en el nombre de la clave en algunos dialectos y se ignore como tal. Las líneas de comentarios están diseñadas para que un analizador las ignore.
#! /bin/convertir-ini-a-perl | perla | carga ssh wikipedia.org --sanitise=no ; Ambiguo sin mayores conocimientos del dialecto .INI: ; ¿El valor es "vivo" o "vivo #peligrosamente"? Me gusta = vivir #peligrosamente #var=avar = a ; Este es un comentario en línea foo = bar # Este es otro comentario en línea
Según el dialecto GetPrivateProfileString de WinAPI , los comentarios deben aparecer en líneas por sí solos.
El orden de las propiedades de una sección y el orden de las secciones de un archivo son irrelevantes.
La mayoría de las implementaciones solo admiten tener una propiedad con un nombre de pila en una sección. La segunda aparición de un nombre de propiedad puede provocar un aborto , puede ignorarse (y el valor descartado) o puede anular la primera aparición (con el primer valor descartado). Algunos programas utilizan nombres de propiedades duplicados para implementar propiedades con valores múltiples.
La interpretación de declaraciones de varias secciones con el mismo nombre también varía. En algunas implementaciones, las secciones duplicadas simplemente fusionan sus propiedades, como si ocurrieran de forma contigua. Otros pueden cancelar o ignorar algún aspecto del archivo INI.
Algunas implementaciones permiten citar valores, normalmente utilizando comillas dobles y/o apóstrofes . Esto permite la declaración explícita de espacios en blanco y/o el uso de comillas de caracteres especiales (igual, punto y coma, etc.). La función estándar de Windows GetPrivateProfileString admite esto y eliminará las comillas que rodean los valores.
Al emular la sintaxis de C , algunos dialectos permiten doblar líneas mediante una barra invertida ( \
, ASCII 0x5C) como último carácter de una línea. [18] En dicha continuación de línea , las barras invertidas seguidas inmediatamente por EOL (fin de línea) hacen que la barra invertida y el salto de línea se eliminen, transformando las líneas del documento en líneas lógicas .
Algunos dialectos ofrecen distintos soportes para el escape de caracteres , generalmente con el carácter de barra invertida ( \
, ASCII 0x5C) como metacarácter y emulando la sintaxis de C. [19]
No es aconsejable interpretar ciegamente las secuencias de escape, ya que algunas especificaciones silencian explícitamente su metacarácter para secuencias de escape comunes. [20] [21]
En Windows, Profile API es la interfaz de programación utilizada para leer y escribir configuraciones desde archivos .ini clásicos de Windows. Por ejemplo, la función GetPrivateProfileString recupera una cadena de la sección especificada en un archivo de inicialización. (El perfil "privado" se contrasta con GetProfileString
, que se obtiene de WIN.INI ).
El siguiente programa C de muestra demuestra la lectura de valores de propiedad del archivo INI de muestra anterior (sea el nombre del archivo de configuración dbsettings.ini
):
#incluir <ventanas.h> int principal ( int argc , _TCHAR * argv []) { _TCHAR servidor de base de datos [ 1000 ]; int dbport ; GetPrivateProfileString ( "base de datos" , "servidor" , "127.0.0.1" , dbserver , sizeof ( dbserver ) / sizeof ( dbserver [ 0 ]), ". \\ dbsettings.ini" ); dbport = GetPrivateProfileInt ( "base de datos" , "puerto" , 143 , ". \\ dbsettings.ini" ); // NB WritePrivateProfileInt() no existe, sólo WritePrivateProfileString() devolver 0 ; }
El tercer parámetro de la función GetPrivateProfileString es el valor predeterminado, que es "127.0.0.1" y 143 respectivamente en las dos llamadas a funciones anteriores. Si el argumento proporcionado para este parámetro es NULL , el valor predeterminado es una cadena vacía, "" .
En Unix, existen muchas bibliotecas de configuración diferentes para acceder a archivos INI. A menudo ya están incluidos en marcos y kits de herramientas. Ejemplos de analizadores INI para Unix incluyen GLib, iniparser y libconfini.
La asignación de archivos de inicialización crea una asignación entre un archivo INI y el registro de Windows . [57] [58] Se introdujo con Windows NT y Windows 95 como una forma de migrar desde el almacenamiento de configuraciones en archivos .ini clásicos al nuevo registro. La asignación de archivos atrapa las llamadas de la API de perfil y, utilizando la configuración de la sección Registro IniFileMapping , dirige las lecturas y escrituras a los lugares apropiados en el Registro.
Utilizando el siguiente ejemplo, se podría realizar una llamada de cadena para recuperar la clave de nombre de la sección de propietario de un archivo de configuración llamado, por ejemplo, dbsettings.ini . El valor devuelto debe ser la cadena "John Doe":
GetPrivateProfileString("propietario", "nombre", ..., "c:\\programs\\oldprogram\\dbsettings.ini");
El mapeo INI toma esta llamada de API de perfil, ignora cualquier ruta en el nombre de archivo dado y verifica si hay una clave de Registro que coincida con el nombre de archivo en el directorio:
Si existe, busca un nombre de entrada que coincida con la sección solicitada. Si se encuentra una entrada, el mapeo INI utiliza su valor como puntero a otra parte del Registro. Luego busca la configuración INI solicitada en esa parte del Registro.
Si no se encuentra ningún nombre de entrada coincidente y hay una entrada bajo el nombre de entrada (predeterminado) , la asignación INI la utiliza en su lugar. Por tanto, cada nombre de sección no necesita su propia entrada.
Entonces, en este caso, la llamada de perfil para la sección [propietario] se asigna a:
donde se encuentra que el nombre de la entrada del Registro " name " coincide con la clave INI solicitada. Luego, el valor de "John Doe" se devuelve a la llamada de perfil. En este caso, el prefijo @ predeterminado evita que cualquier lectura vaya al archivo dbsettings.ini en el disco. El resultado es que cualquier configuración que no se encuentre en el Registro no se busca en el archivo INI.
La entrada del Registro " base de datos " no tiene el prefijo @ en el valor; por lo tanto, solo para la [database]
sección , primero se toman las configuraciones en el Registro, seguidas por las configuraciones en el archivo dbsettings.ini en el disco.
A partir de Windows 95 , Microsoft comenzó a promover fuertemente el uso del registro de Windows sobre los archivos INI. [59] Los archivos INI normalmente están limitados a dos niveles (secciones y propiedades) y no manejan bien los datos binarios. Esta decisión, sin embargo, no ha estado inmune a las críticas, debido a que el registro es monolítico, opaco y binario, debe estar sincronizado con el sistema de archivos y representa un único punto de falla para el sistema operativo. [60]
Posteriormente, los archivos de configuración basados en XML se convirtieron en una opción popular para codificar la configuración en archivos de texto. [ cita necesaria ] XML permite niveles y anidamientos arbitrariamente complejos, y tiene mecanismos estándar para codificar datos binarios .
Más recientemente, los formatos de serialización de datos , como JSON , TOML y YAML, pueden servir como formatos de configuración. Estos tres formatos alternativos pueden anidarse arbitrariamente, pero tienen una sintaxis diferente a la del archivo INI. Entre ellos, TOML se parece más a INI, pero se rechazó la idea de hacer que TOML fuera deliberadamente compatible con un gran subconjunto de INI. [61]
Sin embargo, los analizadores INI más nuevos permiten el mismo nivel arbitrario de anidamiento de XML , JSON , TOML y YAML , ofrecen soporte equivalente de valores escritos y Unicode , aunque mantienen el "estado informal" de los archivos INI al permitir múltiples sintaxis para expresar lo mismo. . [62]
php.ini
"a
en el siguiente ejemplo:[sección]
#a=a
b=b
java.util.Properties