Was ist eine ini-Datei und was sollte man bei diesen beachten?

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.

Aufbau & Funktionsweise

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:

 

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 werdenje 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, indem man den Text je nach Sprache für die entsprechenden Labels, etc. definiert. Auch nicht unüblich ist es die meisten Parameter in einer SQL-Tabelle unterzubringen und in einer ini-Datei nur die nötigsten Parameter, z. B. für den Aufbau der Verbindung  zur Datenbank, zu hinterlegen.

Über eine ini-Datei lässt sich beispielsweise gut eine Anwendung für einen anderen Kunden umkonfigurieren und 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 anders als ich sie kenne“. Dies einfach nur weil sie komplett auf links konfiguriert worden ist 😀

 

Alternativen

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.

 

Wie öffnet und bearbeitet man eine ini-Datei?

Da es sich bei den ini-Dateien mehroder weniger um einfache Textdateien handelt sind diese ohne großen Aufwand les- und veränderbar. 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.

 

Beispiel in PHP

Für meine PHP-Webprojekte habe ich mir beispielsweise eine config.ini-Datei gebastelt um einige grundlegenede Einstellungen/Parameter für die jeweilige Webseite festlegen zu können:

 

Zum Einlesen gibt es in PHP beispielsweise bereits eine vorgefertigte Funktion, welcher man nur den Pfad zur ini-Datei übergeben muss:

Die einzelnen Parameter werden durch diese Funktion in ein Array eingelesen.

 

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. 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 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. Beispieksweise könnte der Endanwender die SQL-Abfrage beliebig ändern oder 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 die je nach Kontext dann mit erhöhten Benutzerrechten ausgeführt wird.

Zu den Gefahren durch zu großzügig vergebene Benutzerrechte hhabe ich bereits folgende passende Artikel veröffentlicht:

Die Gefahr durch mit Adminrechten ausgeführte Skripte

Zugriffsrechte für Ordner-Freigaben für Branchensoftware einschränken

Schreibe einen Kommentar