Für die meisten die schon länger beruflich im IT-Bereich unterwegs sind dürften ini-Dateien nichts unbekanntes sein. Für Neulinge stellt sich allerdings vielleicht die Frage wofür ini-Dateien eigentlich gut sind. Grundsätzlich handelt es sich bei ini-Dateien, wie es die Abkürzung vermuten lässt, um „Initialisierungsdateien“. Man könnte aber auch Konfigurationsdatei oder Konfigdatei dazu sagen. Bekannt sind die ini-Dateien eher von Windows-Betriebssystemen und Windows-Anwendungen. Unter Linux findet man eher conf- oder cfg-Dateien um Konfigurationen vorzunehmen. Im Prinzip sind Dateiendungen aber nur Schall und Rauch.
Wie erstellt, öffnet und bearbeitet man eine ini-Datei?
Bei ini-Dateien handelt es sich mehr oder weniger um einfache Textdateien. Diese kann man deshalb ohne großen Aufwand erstellen, lesen und verändern. Zur Bearbeitung benötigt man also nichts weiter als einen einfachen Texteditor wie den Standard-Editor unter Windows. Komfortabler ist natürlich ein Editor wie Notepad++, der die Sektionen farblich abhebt und grundsätzlich einfach viel mehr Komfort bietet:
Um aus einer leeren Datei eine ini-Datei zu machen, muss man lediglich die Dateiendung z.B. im Explorer auf „.ini“ abändern:
Allerdings ist diese ohne passenden Inhalt natürlich von keinem Programm zu gebrauchen.
Neben Notepad++ kann man noch viele andere Programme zum Öffnen und Bearbeiten von ini-Dateien nutzen:
Notepad/Editor (in Windows enthalten), Visual Studio Code (Freeware), UltraEdit und eigentlich alle anderen Code-Editoren sollten ini-Dateien bearbeiten können und meistens auch mit Highlighting anzeigen.
Beispiel in PHP
Für meine PHP-Webprojekte habe ich mir beispielsweise eine config.ini-Datei gebastelt. In dieser können einige grundlegenede Einstellungen/Parameter für die jeweilige Webseite festgelegt werden:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[database] DB_SERVER = localhost DB_USERNAME = testuser DB_PASSWORD = test1234 DB_NAME = testdb SQL_PRAEFIX = db_ [website] ROOTPATH = https://xyz.de/ DOMAIN = xyz.de THEME = theme001 CACHE = true DEBUG = false COMPRESSION = true |
Zum Einlesen gibt es in PHP beispielsweise bereits eine bereits vorgefertigte Funktion. Dieser muss man nur den Pfad zur ini-Datei übergeben:
1 2 |
// import all needed parameters from the config.ini $config = parse_ini_file($config_file); |
Die einzelnen Parameter werden durch diese Funktion automatisch in ein Array eingelesen.
Aufbau & Funktionsweise einer ini-Datei
Besonders verbreitet waren ini-Dateien vor der Einführung der Registry, die jedem Windows-Nutzer bekannt sein dürfte. Diese wurde erst mit Windows NT 3.1 eingeführt. In der ini-Datei werden sogenannte „Schlüssel-Wert-Paare“ angegeben. Den Schlüsseln, die auch als Kenner oder Parameter bezeichnet werden, wird ein Wert zugewiesen. Zur besseren Übersichtlichkeit besteht auch die Möglichkeit Sektionen zur Kategorisierung von Schlüsselpaaren anzulegen. Dies sieht z. B. so aus:
1 2 3 4 5 6 |
[Sektion1] Schlüssel=Wert ; Dies ist ein Beispiel-Kommentar [Sektion2] Schlüssel2=Wert Schlüssel3=Wert |
Beim Erstellen oder Editieren einer ini-Datei sind normalerweise folgende Regeln zu beachten:
- Jede Sektion darf nur einmal vorkommen
- Jeder Schlüssel darf nur einmal je Sektion vorkommen
- Auf Werte wird mittels Sektion und Schlüssel zugegriffen
- Auskommentiert wird mit einem Semikolon und immer eine ganze Zeile und nicht hinter einem Schlüsselpaar oder einer Sektion
- Leerzeichen und Anführungszeichen werden je nach Programm unterschiedlich behandelt
- Es wird nicht zwischen Groß- und Kleinschreibung unterschieden
- False und No werden als 0, True und Yes als 1 interpretiert
Allerdings kann man natürlich in einer eigenen Anwendung mit den Daten aus einer ini-Datei machen was man will und z. B. auch Groß- und Kleinschreibung unterscheiden. Man kann mit diesen z. B. auch unterschiedliche Sprachen für die eigene Anwendung abbilden. Dies funktioniert, indem man den Text je nach Sprache für die entsprechenden Labels, etc. in einer ini-Datei definiert. Auch nicht unüblich ist es die meisten Parameter eher in einer SQL-Tabelle zu hinterlegen. In einer ini-Datei landen dann nur die nötigsten Parameter, z. B. für den Aufbau der Verbindung zur Datenbank.
Über eine ini-Datei lässt sich beispielsweise gut eine Anwendung für einen anderen Kunden umkonfigurieren. Mit den entsprechenden Einträgen lässt sich das Verhalten einer Anwendung unter Umständen komplett verändern. Zumindest wenn die Anwendung solche weitreichenden Änderungen zulässt. Dies kann leider auch zu einem Nachteil werden. Nämlich genau dann, wenn es irgendwann gefühlt 10.000, im schlimmsten Fall weitestgehend undokumentierte, Konfigurationsmöglichkeiten, gibt.
Deshalb kann es passieren, dass man mal ein Zitat wie dieses hört: „Bei dem Kunden ist die Anwendung ja komplett auf links gedreht worden“. Dies einfach nur weil sie komplett anders konfiguriert worden ist 😀
Was gehört besser nicht in eine ini-Datei?
Theoretisch sollte man ganz großen Abstand davon nehmen irgendwelche Passworte (z. B. für Datenbankzugriffe) in eine ini-Datei zu schreiben. Wenn diese für die Endanwender einer Business-Anwendung auf irgendeine Weise zugänglich sind ist dies ein Super-GAU. Bei dem vorherigen Beispiel wäre dies nicht der Fall gewesen.
In der Praxis ist es aber eher so, dass man bei der Suche nach ini-Dateien, z. B. auf einem Server für eine Branchenanwendung, in den meisten Fällen eine Datei finden wird, in welcher meist im Klartext (!) die Zugangsdaten zum Datenbankserver oder dergleichen angegeben sind. Deshalb wurde mir schon desöfteren vom Support einer solchen Anwendung die Frage gestellt, wie ich es denn geschafft hätte selbständig in der Datenbank rumzusuchen. Auf meine Aussage, dass ich einfach die Zugangsdaten aus der ini-Datei genommen habe, wusste der neugierige Supporter dann auch nichts mehr zu sagen 😀
Dabei hätte man die Zugangsdaten dort schon angeben können, solange diese z. B. als Salted Hash und nicht im Klartext hinterlegt worden wären.
Ebenfalls etwas kritisch ist es, wenn man SQL-Abfragen oder Quellcode aus einem der Parameter der ini-Datei einliest. Hierdurch gewinnt man für bestimmte Anwendungszwecke zwar eine gewisse Flexibilität, aber öffnet auf der anderen Seite auch immer Hintertürchen. Beispielsweise könnte der Endanwender die SQL-Abfrage beliebig ändern. Wenn beispielsweise ein Pfad zu einer zu startenden Anwendung/Batch-Datei oder dergleichen angegeben werden kann, könnte ein Pfad zu einer selbstgeschriebenen Datei angegeben werden. Diese könnte je nach Kontext dann mit erhöhten Benutzerrechten ausgeführt werden.
Zu den Gefahren durch zu großzügig vergebene Benutzerrechte hhabe ich bereits folgende passende Artikel veröffentlicht:
Zugriffsrechte für Ordner-Freigaben für Branchensoftware einschränken
Alternativen zu ini-Dateien
Mittlerweile werden auch folgende Dateien gerne als Alternativen zu ini-Dateien genutzt:
- XML (Extensible Markup Language)
- JSON (JavaScript Object Notation)
- YAML (YAML Ain’t Markup Language)
- TOML (Tom’s Obvious, Minimal Language)
Im Linux-Umfeld gibt es sogenannte conf- bzw. cfg-Dateien. Diese entsprechen von ihrem Aufbau her den ini-Dateien. Im Unterschied wird dort ein Kommentar allerdings mit einer # eingeleitet. Dort kann es auch sein, dass die Dateien gar keine Dateiendung haben.