Dateiformat bekannt? / Parsen mit PHP

[kai345]

Moin!

Ich habe hier eine Textdatei mit Daten, die ich gerne via PHP einlesen möchte, um sie dann in ein anderes Format zu überführen. Bevor ich mir nun selber irgendeinen Murks zusammenhacke, frage ich erst mal, ob dieses Datenformat bekannt ist und ggf. bereits vorgefertigte Lösungen gibt.

Das Format sieht folgendermaßen aus:

//  line comment
/* 
  block comment
*/

foo = "bar";
bla = "blubb"; 

identifier 
{
    WhatEver = "Die Energie des Verstehens"; // wer kennt's nicht 
    abcde = "fghij";
    #keyword = "content bla bla";
}

self
{
    HTML;
    CSS;
    foobar;
} 

Gibt es da irgendwas von Ratiopha PHP bzw. ist das irgend ein gebräuchliches Format oder muß ich mir da SELF was basteln bzw. die Datei vor-editieren?

[Tabellenkalk]

Hallo,

Das sieht wie eine ini- oder config-Datei aus. Eventüll mal diesbezüglich die Suchergebnisse auf php.net durchgehen...

Gruß
Kalk

[Raketenhandbuchleser]

Die Liste zu filetype() unter "Siehe auch". Da steht nämlich das hoffentlich zielführende "mime_content_type()".

[kai345]

Die Liste zu filetype() unter "Siehe auch". Da steht nämlich das hoffentlich zielführende "mime_content_type()".

text/plain

Schade. Danke trotzdem.

[Raketenirrtumsbenachrichtiger]

Sorry. Du hattest da ein sehr konkretes Datenformat, welches Du parsen willst. Da hilft Dir meine Antwort leider nicht weiter.

[Raktenwissenschaftler]

Hm. Woher stammt denn das Dateiformat? Es muss ja bereits irgendetwas geben, was das Zeug parst. Bevor ich einen neuen Parser schreiben würde würde ich auf jeden Fall ins Auge fassen, das Zeug von der Original-Software parsen und mir dann die Ergebnisse für PHP in einem anderen Format ausgeben zu lassen. (exec(), system(),…)

[kai345]

Hm. Woher stammt denn das Dateiformat? Es muss ja bereits irgendetwas geben, was das Zeug parst. Bevor ich einen neuen Parser schreiben würde würde ich auf jeden Fall ins Auge fassen, das Zeug von der Original-Software parsen und mir dann die Ergebnisse für PHP in einem anderen Format ausgeben zu lassen. (exec(), system(),…)

Das sind eigentlich interne Konfigurationsdateien eines Programmes.

Die Text-Datei enthält unter Anderem die unterstützten Funktionsnamen samt Parametern und Kurz-Beschreibung und die Konstanten-Namen etc. für die Scripting-Sprache dieses Programmes.

Haben will ich das, um für meinen Editor eine Hint-Datei zu erzeugen, die mir dann beim Tippen der Funktionsnamen a) vervollständigt und b) die Parameter anzeigt.

Da das Datenformat offenbar nicht allgemein bekannt ist, werde ich wohl selber Hand anlegen müssen.

[Raketenwissenschaftsphilosph]

interne Konfigurationsdateien eines Programmes.

unterstützten Funktionsnamen samt Parametern und Kurz-Beschreibung und die Konstanten-Namen etc. für die Scripting-Sprache dieses Programmes.

Da das Datenformat offenbar nicht allgemein bekannt ist,

Die eigentliche Raketenwissenschaft ist bekanntlich, die Hilfesuchenden dazu bewegen, mit Namen (und Versionsnummern) von Programmen und Skriptsprachen herauszurücken, damit ihnen geholfen werden kann.

Da das Datenformat offenbar nicht allgemein bekannt ist, werde ich wohl selber Hand anlegen müssen.

Das ist ein wenig wie in dem Sketch, wo einer bei der Feuerwehr anruft und wiederholt nur "Es brennt! Hilfe! Hier brennt es!" sagt. Und dann auf die Frage, "Das habe ich verstanden. Aber wie kommen wir denn zu Ihnen hin?" mit "Wie? Haben Sie denn nicht mehr die roten Autos?" antwortet.

[Raketenwissenschaftspraktiker]

die [uns nicht bekannt gemachte] Scripting-Sprache dieses [uns nicht bekannt gemachten] Programmes

hat nämlich mit sehr hoher Sicherheit eine Funktion (Klasse oder dergleichen) mit welcher die gezeigte Konfiguration gelesen und womöglich sogar geschrieben werden kann. Kennt man diese Funktion (wofür die Nennung von Programm und Skriptsprache Voraussetzung ist), dann kann man sehr leicht die gezeigte Konfiguration in ein anderes, verbreitetes Format wie JSON, meinetwegen "XML" oder "ini" überführen und visa versa.

[pl]

Konfigurationsdateien müssen der Anforderung genügen leicht editierbar zu sein. Das sind XML Dateien mit Sicherheit nicht. Und dann ist es noch eine ganz andere Frage wie eine Konfiguration produktiv aufzustellen ist, da ist nämlich die Performanze vordergründig und die Lesbarkeit völlig uninteressant (Deployment).

Man könnte aber auch ein Backend aufsetzen was zwischen Lesbarkeit und einem performanten Deployment vermittelt, also so daß derjenige der die Konfig schreibt, mit der Datei gar nichts mehr zu tun hat. Und natürlich kann man eine Konfiguration auch in einer Datenbank aufstellen.

1000 Ideen!

[Der Martin]

Hi,

Konfigurationsdateien müssen der Anforderung genügen leicht editierbar zu sein.

hehe, erzähl das mal den Programmierern bei Microsoft!

Das sind XML Dateien mit Sicherheit nicht.

Doch, sind sie. So einigermaßen. Wenn man sie ordentlich formatiert, sind sie sogar recht gut les- und editierbar (oder wenn man einen dafür vorgesehenen Editor verwendet).

Und dann ist es noch eine ganz andere Frage wie eine Konfiguration produktiv aufzustellen ist, da ist nämlich die Performanze vordergründig und die Lesbarkeit völlig uninteressant (Deployment).

Kommt drauf an. Wenn z.B. die Konfiguration eines Dienstes nur einmalig beim Start dieses Dienstes gelesen, geparst und dann in geeigneter Form im Arbeitsspeicher gehalten wird, sind etwa 0.729s Rechenzeit fürs Parsen egal. Die sind aber nicht egal, wenn die Konfiguration häufig neu gelesen wird, weil sie sich jederzeit im lsufenden Betrieb ändern kann (z.B. bei Samba).

Man könnte aber auch ein Backend aufsetzen was zwischen Lesbarkeit und einem performanten Deployment vermittelt, also so daß derjenige der die Konfig schreibt, mit der Datei gar nichts mehr zu tun hat.

Auch eine Möglichkeit. Postfix macht das so.

Und natürlich kann man eine Konfiguration auch in einer Datenbank aufstellen.

Klar. Man kann sich auch ein Feingewinde ins Knie schneiden und mit der Schraube den Schmerz regulieren. ;-)

Ciao,
 Martin

[pl]

Hi,

Konfigurationsdateien müssen der Anforderung genügen leicht editierbar zu sein.

hehe, erzähl das mal den Programmierern bei Microsoft!

die INI Datei ist vom Mircosoft.

Und natürlich kann man eine Konfiguration auch in einer Datenbank aufstellen.

Klar. Man kann sich auch ein Feingewinde ins Knie schneiden und mit der Schraube den Schmerz regulieren. ;-)

Oder phpmyadmin als Konfig-Editor verwenden 😉

MFG

PS: Ich benutze übrigens auch ein proprietäres Dateiformat. D.h., die Konfiguration bearbeite ich als INI Datei mit derzeit ca. 2000 Zeilen. Ein nachgelagerter Deployment-Prozess wandelt dann diese INI in ein maschinenlesbares Dateiformat um was der Server kriegt. Diese Datei ist in Perl, C und in PHP gleichermaßen performant lesbar.

[Der Martin]

Hallo,

Konfigurationsdateien müssen der Anforderung genügen leicht editierbar zu sein.

hehe, erzähl das mal den Programmierern bei Microsoft!

die INI Datei ist vom Mircosoft.

ich weiß. Das INI-Format ist auch einwandfrei, zumal das Lesen und Schreiben sogar mit einigen Funktionen des Windows-API unterstützt wird. Für andere Plattformen gibt es vermutlich entsprechende Bibliotheken. Wenn nicht, kann man sich diese Funktionen auch mit vertretbarem Aufwand selber schreiben.

Microsoft hat aber leider das INI-Format ab Windows 4 für "discouraged" erklärt (vermutlich weil es einfach gut ist), und die Softwareentwickler aufgefordert, stattdessen die Registry zu verwenden.

Ciao,
 Martin

[pl]

Es ist auch kein Problem, mehrere Konfig-Dateien verschiedener Formate (ini, xml, json) zu einer Konfiguration zusammenzufassen. Was z.B. mein Deployment-Prozess macht. Ähnliches machen ja auch Installationsprogramme die bestimmte Systemdaten in die Konfiguration linken (Makefile.PL) bevor die eigentliche Installation erfolgt.

MFG

[Gunnar Bittersmann]

@@Raketenwissenschaftsphilosph

Das ist ein wenig wie in dem Sketch, wo einer bei der Feuerwehr anruft und wiederholt nur "Es brennt! Hilfe! Hier brennt es!" sagt. Und dann auf die Frage, "Das habe ich verstanden. Aber wie kommen wir denn zu Ihnen hin?" mit "Wie? Haben Sie denn nicht mehr die roten Autos?" antwortet.

Was als Beispiel herhalten kann, wie man Eingabefelder beschriften sollte.

Nicht

<label>
  Wie kommen wir zu Ihnen hin?
  <textarea name="address"></textarea>
</label>

sondern

<label>
  Ihre Adresse:
  <textarea name="address"></textarea>
</label>

LLAP 🖖

[Raketenwissenschaftler]

Was als Beispiel herhalten kann, wie man Eingabefelder beschriften sollte.

Nicht

<label>
  Wie kommen wir zu Ihnen hin?
  <textarea name="address"></textarea>
</label>

sondern

<label>
  Ihre Adresse:
  <textarea name="address"></textarea>
</label>

Nanu? Hab ich doch richtig gemacht.

[Gunnar Bittersmann]

@@Raketenwissenschaftler

Nanu? Hab ich doch richtig gemacht.

Der Mensch in der Notrufzentrale aber nicht.

LLAP 🖖

[pl]

Bevor ich mir nun selber irgendeinen Murks zusammenhacke,

Die Datei ist der Murks. Hast Du Dir schonmal überlegt wie die Datenstruktur aussehen soll die nach dem Parsen dabei rauskommt?

MFG

PS: Ich ahne Schreckliches: Typhus 3

[TS]

Hello,

Bevor ich mir nun selber irgendeinen Murks zusammenhacke,

Die Datei ist der Murks. Hast Du Dir schonmal überlegt wie die Datenstruktur aussehen soll die nach dem Parsen dabei rauskommt?

MFG

PS: Ich ahne Schreckliches: Typhus 3

Was zickst Du rum? ;-)

Das INI-Format von PHP ist auch nicht intelligenter, aber logisch so ähnlich aufgebaut.

Die INI-Dateien kann man als assoziative Arrays darstellen. Siehe parse_ini_file()

Glück Auf
Tom vom Berg

[pl]

Die INI-Dateien kann man als assoziative Arrays darstellen. Siehe parse_ini_file()

Genau. Deswegen frag ich mich ja, was jemanden dazu treibt ein proprietäres Dateiformat verwenden zu wollen. MFG

[1unitedpower]

Die INI-Dateien kann man als assoziative Arrays darstellen. Siehe parse_ini_file()

Genau. Deswegen frag ich mich ja, was jemanden dazu treibt ein proprietäres Dateiformat verwenden zu wollen.

Die Geister, die sie riefen.

[kai345]

Die INI-Dateien kann man als assoziative Arrays darstellen. Siehe parse_ini_file()

Genau. Deswegen frag ich mich ja, was jemanden dazu treibt ein proprietäres Dateiformat verwenden zu wollen. MFG

Wie fast immer auch hier am Thema vorbei. Es geht nicht darum, weshalb der Autor des Programmes dieses Format gewählt hat.

[pl]

Die INI-Dateien kann man als assoziative Arrays darstellen. Siehe parse_ini_file()

Genau. Deswegen frag ich mich ja, was jemanden dazu treibt ein proprietäres Dateiformat verwenden zu wollen. MFG

Wie fast immer auch hier am Thema vorbei. Es geht nicht darum, weshalb der Autor des Programmes dieses Format gewählt hat.

Deswegen hab ich ja gefragt wie die Datenstruktur nach dem Parsen aussehen soll. Und genau das geht eben nicht am Thema vorbei sondern ist die Kernfrage in Sachen Dateiformat. MFG

[1unitedpower]

Gibt es da irgendwas von Ratiopha PHP bzw. ist das irgend ein gebräuchliches Format oder muß ich mir da SELF was basteln bzw. die Datei vor-editieren?

Ich erkenne das Format zumindest nicht wieder. Mit ein paar Änderungen lässt sich daraus aber HJSON machen. Dafür gibt es auch einen PHP-Parser.

Wenn das eine einmalige Geschichte ist, dann würde ich das Format per Hand editieren. Wenn das eine häufig wiederkehrende Aufgabe ist, dann könnte es sich lohnen einen eigenen Parser dafür zu schreiben. Ich habe im Fourm schon hier und da über Parser in PHP geschrieben. Vielleicht hilft das ja. An deiner Stelle würde ich vermutlich sogar den HJSON-Parser forken und für deinen Fall anpassen.

[kai345]

Wenn das eine häufig wiederkehrende Aufgabe ist, dann könnte es sich lohnen einen eigenen Parser dafür zu schreiben. Ich habe im Fourm schon hier und da über Parser in PHP geschrieben. Vielleicht hilft das ja. An deiner Stelle würde ich vermutlich sogar den HJSON-Parser forken und für deinen Fall anpassen.

Sehr interessant. Ich werde auf jeden Fall den HJSON-Parser als Inspiration für meinen Parser nehmen, falls ich ihn nicht direkt als Grundlage verwenden sollte. Ich muß mich mal in den HJSONParser Source-Code vertiefen, um zu sehen, was für mich einfacher ist.

Auf jeden Fall kann ich damit etwas anfangen.

Thx.