[PHP] INI-Datei Parser

  • Ich habe, aufgrund von anderem Verwendungszweck, einen relativ simplen Parser für INI-Dateien geschrieben. Der Syntax ist nicht ganz der, den man vielleicht kennt, aber ähnlich und beitet etwas mehr freiheiten.

    Key-Value paare werden mithilfe des = deklariert, jede anweisung trennt eine Zeile.

    Code
    key=value
    key2=value

    Wird ein key doppelt definiert, wird der alte überschrieben.

    Zeieln können belibig eingerückt werden, leere Zeilen und die, die mit einem # beginnen, werden ignoriert. Ein # würde hier also ein KOmmentar bezeichnen.

    Code
    key=value
    #key=value

    Bei den Sections liegt der größte unterschied. Denn, auch aus gründen des Codeverständinnes und der Vermeidung unnötiger kompliziertheit, muss deren Ende gekennzeichnet werden.

    Code
    [section]
    key=value
    [END]

    Eine Section nicht zu beenden, endet in einer Exception.
    Sections können beliebig oft in einander verschalchtelt werden, es macht hier auch keinen unterschied, ob vor oder nach einer inneren section Key-Value paare stehen.

    Achtung: Die vielen key=value im oberen Beispiel überschreiben sich nicht.

    EDIT: Sorry, das hab ich vergessen:
    Achtung: Sections die doppelt definiert sind, werden ebenfalls überschrieben.

    Nun zu den freiheiten, von denen ich gesprochen habe: Ein = in einer anweisung ist nicht zwingen nötig. Somit kann man quasi listen definieren:

    Code
    file_description=Produktliste
    [products]
     Computer
     Auto 
     Waschbecken
     Kugelschreiber
    [END]

    Soviel zum Syntax.

    Die Verwendung in PHP:

    Vom perser kommt ein Array zurück, das die Key-Value paare enthält. Sections sind ein Array mit gleichen beedingungen, wie das ausgangs-Array.

    Code
    #userdata.ini
    name=Tobse
    [sprachen]
    Deutsch
    Englisch
    [END]
    PHP
    // je nachdem, wie man die Klasse an/ablegt
    include("INIParser.class.php");
    $file="userdata.ini";
    $user=INIParser::parseFile($file);
    echo "Benutzername: ".$user['name'];
    echo "Spricht folgende Sprachen: ".implode(",", $user['sprachen']);

    um als Beispiel hier noch das Array, dass INI::parseFile zurück gibt aufzuzeigen:

    PHP
    Array (
        "name"=>"Tobse",
        "sprachen"=>Array (
            "Deutsch",
            "Englisch"
        )
    )

    Zusätzlich zu INIParser::parseFile gibt es ncoh INIParser::parse. Diese Methode nimmt ein Array (oder einen String, den sie mithilfe von explode bei \n´s nach zeilen zeilt).
    Achtung: INIParser::parse und INIParser::parseFile sind statisch und INIParser abstrakt.


    Hier der Quellcode:

    Feedback herzlich willkommen, aber bitte Konstruktives.

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

    5 Mal editiert, zuletzt von Tobse (7. Mai 2011 um 17:04)

  • Ich verstehe nicht ganz, wieso ich ein ini-File schreiben sollte, dass sich an Konventionen halten muss, die von einer spezifischen PHP-Klasse vorgegeben werden. Durch deine eigenen Konventionen geht die eventuelle Wiederverwendbarkeit in anderen Sprachen flöten. Also welchen Mehrwert bietet es mir ein ini-File zu schreiben, dass auf deine PHP-Klasse angewiesen ist und nichts weiter macht als mir ein assoziatives Array zu erstellen, statt einfach eine PHP-Datei zu erstellen in die ich direkt mein Array schreibe?

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • Wenn du z.B. in einem CMS einstellungsmöglichkeiten für erweiterungen bieten möchtest, dann ist ein ini file sicherer. Denn wenn du das in einer PHP-Datei ablegst, kann da ja sonst noch was für code drin sein. Ich habe das z.B. auch dazu verwendet, informationen zum Aussehen und inhalt von Fehlerseiten zu definieren (HTTP Status code, div. Farben und 2 Texte).

    Zum Beitrag von Unregistriert:
    Ja, ich weiss, dass es diese Funktion gibt. Allerdings war mir die 2te Sache mit den Sections wichtig, also das Array ohne keys. Auch finde ich es übersichtlicher, die Sections o aufzuteilen anstadt mit den punkten im namen.

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

  • Keine deiner Begründungen rechtfertigen deine Klasse und die vom Standard abweichende Ini-Datei.

  • ini-Dateien sind nach meiner Auffassung für Settings gedacht, nicht für Datenhaltung. Und ich lasse in meinen Systemen niemanden Settings festlegen und ini-Dateien anlegen, dem ich nicht auch weit genug vertraue um ihn php-Dateien anlegen zu lassen.
    Wenn es um Daten geht die von Außenstehenden eingepflegt werden, dann kriegen sie eine Web-Oberfläche über die sie das machen können, und ich entscheide in welcher Form ich die Daten ablege.

    Guck dir mal an wofür hier die ini-Datei verwendet wird:
    http://samuelsjoberg.com/archive/2007/01/url-dispatcher
    In so einer Form macht das schon wesentlich mehr Sinn für mich.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • Dann eben Settings, es kann ja sein, dass es mehrer config.ini s (anstadt config.phps) gibt. Ein Interface für die Daten wäre zwar schön - allerdings, was wenn der Ausenstehende nicht bei jedem, der das verwendet, das interface konfigurieren kann.
    Wer die Klase verwenden will, soll, wer nicht, nicht.
    @Unregistriert: Ich muss mich hier in KEINER Weise rechtfertigen. Buntz es oder lass es sein.

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

  • @Unregistriert: Ich muss mich hier in KEINER Weise rechtfertigen. Buntz es oder lass es sein.


    Habe ich auch nicht behaupter und ich lass es

  • Natürlich musst du dich nicht rechtfertigen, und meine Kritik ist auch keineswegs böse, sondern konstruktiv gemeint.

    Ich spreche mal nur von mir persönlich: Ich habe sicherlich über 90% meiner Klassen/Libraries die ich mir im Lauf der Jahre geschrieben habe mittlerweile verworfen und kann über das meiste davon nur noch den Kopf schütteln. Und so wird es dir auch mit deinem ini-Parser früher oder später gehen. Deine Klasse bietet nicht den geringsten Mehrwert gegenüber ini-Files die sich an die gängigen Konventionen halten, dafür aber mindestens einen enormen Nachteil, nämlich das diese ini-Files völlig auf deine PHP-Klasse angewiesen sind. Moderne professionelle Softwareentwicklung setzt aber voll auf Entkoppelung und Wiederverwendbarkeit der verschiedenen Elemente. Und da wird deine Klasse ein No-Go.
    Mach einen txt-Parser draus, dann kommen wenigstens keine Mißverständnisse auf. ini-Files haben nunmal (aus gutem Grund) Syntax-Konventionen. Und die über Bord zu werfen und somit jegliche Möglichkeit der Wiederverwendbarkeit zu eliminieren, einzig und allein aus dem Grund, weil dir persönlich eine andere Schreibweise besser gefällt, ist nichts was für die Allgemeinheit sonderlich interessant ist.

    Wie gesagt, das ist nicht böse sondern konstruktiv gemeint. Ich weiß deine Bereitschaft deine Codes der Allgemeinheit zur Verfügung zu stellen durchaus zu schätzen. Aber wer etwas veröffentlich muss auch das Feedback akzeptieren.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • oder mach *.tobse files und nen tobse-parser :mrgreen:

    dann weiß jeder dass ne config.tobse von deinem parser geparsed werden muss.. vielleicht erschaffst du ja so einen neuen standard ;)

  • SinnlosS:
    Das mit dem Rechtfertigen war an den Unregistrierten gerichtet. Ich aktzeptiere deine Kritik auch, ich seh auch deine argumente. Sicherlich, ich bin bereits über dinge aus früheren Zeiten gestolpert, die ich ohne nachzudenken, einfach nur vom sehen des Namens und den ersten erinnerunge, was darins ein könnte, gelöscht.

    synaptic: Ha, das wärs doch ;)

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

  • Ich seh da kein Problem, wenn man nen eigenes config-file Format haben will, warum auch nicht… Und natürlich hat es Mehrwert, nur das Wort INI gehört da nicht rein.



    Ok, ich habe mich vielleicht etwas zu sehr an INI aufgehangen. Kein Mehrwert bezog sich auf die Alternative eine PHP-Datei zu schreiben in der die Daten direkt als Array stehen, statt ein eigenes Format zu nutzen das dann erst noch geparst werden muß und auf eine bestimmte PHP-Klasse angewiesen ist.
    Ein Greifen des Arguments, das Config-Dateien von Personen angelegt werden sollen, denen nicht genug vertraut wird um sie direkt php-Dateien anlegen zu lassen, ist mir halt noch nie untergekommen und halte ich, zumindest bei mir, auch für die Zukunft für so unwahrscheinlich, dass ich mir darum keine Gedanken mache.

    Trotzdem kamen meine Postings vielleicht etwas zu negativ rüber. Wem die Klasse hilft, und sei es nur zeitweise, der soll sie selbstverständlich verwenden, ich will das niemandem aus- oder schlechtreden. Es ging mir wohl mehr darum warum ich für mich persönlich keinen großen Nutzen darin sehe. Andere können das natürlich anders sehen.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • Ich finde das direkte Setzen in PHP-Dateien nicht so sinnvoll. Eine solche beschränkte Konfigurationsdatei kann man auch mit einem Programm bearbeiten und die Konfigurationsdatei muss nicht wissen, wo im Script die Daten hinsollen.

  • Außerdem können so andere Programme/Dienste/Sprachen drauf zu greifen

    Nicht vergessen die nicht .php Files von externen zugriffen zu schützen :)

  • ... Eine solche beschränkte Konfigurationsdatei kann man auch mit einem Programm bearbeiten.


    Mit einem Programm das extra für diese Datei geschrieben werden muss, da es eine eigene Syntax nutzt.

    ... und die Konfigurationsdatei muss nicht wissen, wo im Script die Daten hinsollen...


    Ich verstehe nicht was du damit meinst, bzw. wo der Unterschied zu einem PHP-Daten-Array in einer Datei sein soll.

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook

  • ich glaub deruser wollte damit nur sagen, dass man mit ner php-file mehr kaputt machen könnte..
    bei ner ini oder cfg hat man halt nur die entsprechenden information in einem name-wert-paar und man kann auch nichts anderes tun, als sich eben dieser config bemächtigen.

    aber lieber sinnlos, ich kann dein denken und deine bedenken gänzlich nachempfinden.
    wenn ich ne spezielle config bräuchte, würd ich die explizit anlegen und gar net lange suchen ob ne *.ini oder ne *.tobse-file adäquat wären.
    demnach wäre aber auch ein eigener parser fix geschrieben :)

    naja ich klink mich hier wieder aus.

  • Mit einem Programm das extra für diese Datei geschrieben werden muss, da es eine eigene Syntax nutzt.


    Äh, im einfachsten Fall schreibst du eine Funktion, die ein Array nach .tobse exportiert, sonst eben etwas spezieller. Bei PHP geht das nicht, du kannst nicht einfach PHP-Code mit einem Programm manipulieren (außer mit einem Texteditor), weil das Programm PHP verstehen müsste, und das geht nicht.

    Zitat von SinnlosS

    Ich verstehe nicht was du damit meinst, bzw. wo der Unterschied zu einem PHP-Daten-Array in einer Datei sein soll.


    Das, was Synaptic sagte, und die Konfiguration hängt nicht von der internen Datenhaltung im Programm ab (ob die Daten mit der Konfiguration jetzt in irgendeiner globalen Variable, in Objekt xy oder sonstwo landen oder vllt. direkt verarbeitet werden) ebenso wenig wie von der Programmiersprache. Zudem ist sie einfacher zu lesen.

  • Ich halte das miit dem Misstrauen schon für berechtigt. Angenommen, du hast eine Dynamische seite mit festem Layout, in die der Admin aber nach belieben (und ohne zig Viren-Scanns) Themes einbinden können soll, dann wäre es leichtsinnig, eine PHP-Datei zu nehmen, denn die kann mehr als nur key-value (und muss übrigens genauso geparst werden...).
    Warum haben denn
    - Winamp Themes nur XMLs und Bilder
    - PhpMyadmin Themes auch nur inis und Stylesheets
    - WinRAR Themes haben auch nur ne ini und Bilder

    Weil das Risiko einfach unnötig hoch ist. Man braucht ja kein Rechenzentrum, um 2+10 zu rechnen.

    Der, der weiß dass er nichts weiß, weiß mehr als der, der nicht weiß, dass er nichts weiß.

    Wer nach etwas fragt, geht grundsätzlich das Risiko ein, es auch zu bekommen!

    Einmal editiert, zuletzt von Tobse (14. Mai 2011 um 01:48)


  • Das, was Synaptic sagte, und die Konfiguration hängt nicht von der internen Datenhaltung im Programm ab (ob die Daten mit der Konfiguration jetzt in irgendeiner globalen Variable, in Objekt xy oder sonstwo landen oder vllt. direkt verarbeitet werden) ebenso wenig wie von der Programmiersprache. Zudem ist sie einfacher zu lesen.


    Zum ersten Punkt (Sicherheit) habe ich meinen Standpunkt bereits zweimal dargelegt. Zum zweiten, die Klasse von Tobse parst aus einer Config-Datei ein Array, bei meinem Beispiel steht das Array direkt in einer Datei. Und diese Datei mit dem PHP-Array kann ich genauso an jeder beliebigen Stelle einbinden, an der ich auch die Config-Datei parsen lassen kann. Das macht nun wirklich keinen Unterschied.



    - Winamp Themes nur XMLs und Bilder
    - PhpMyadmin Themes auch nur inis und Stylesheets
    - WinRAR Themes haben auch nur ne ini und Bilder



    Fällt dir was auf? ini, xml? Das sind standardisierte Formate, und gegen die Verwendung selbiger hab auch ich persönlich gar nichts. (Und für niemand anderen als mich persönlich argumentiere ich hier noch, wie bereits gesagt. Ich maße mir nicht an für die Allgemeinheit zu sprechen)

    "Programming today is a race between software engineers
    striving to build bigger and better idiot-proof programs,
    and the universe trying to build bigger and better idiots.
    So far, the universe is winning."
    Rick Cook