Hallo "community",

vielleicht hat jemand für mich einen Tip was ich genau suche ;-)

vorneweg: Ich bin nicht der Hardcore-Programmierer, und perl liest sich für mich momentan eher wie klingonisch als wie eine leicht verständliche Programmiersprache ... aber das mag sich ja noch ändern.

Ich habe folgende Aufgabenstellung:

ich möchte verschiedene csv "Nutzdaten" Dateien auf syntaktische Korrektheit prüfen. Die zugrunde liegende Definitionsdatei soll in einer (E)BNF Form den Dateinamen, sowie die Struktur und Syntax der Nutzdatendatei beschreiben, z.B. (siehe unten). das ganze soll in perl passieren (5.6.0)

Um es mal "sehr top-down" zu formulieren:

Es fehlt mir zwischen dem Funktionsaufruf ....

syntaxcheck.pl definitionsdatei.ebnf TEMP1_IN_20080908_01.DAT

... und der Meldung:
"file sucessfully verified"

oder irgendwelche sinnigen prägnanten Fehlermeldungen, wie z.B.
Syntaxerror in data row 123, field B03 (Fieldname): wrong b03_datatype
Syntaxerror in data row 129, field B05 (Fieldname): wrong b03_value

... "nur noch" das Stückchen perl-code syntaxcheck.pl, welches das macht was ich brauche


Hat da irgendjemand eine heiße Spur für mich? Ich kann mir fast kaum vorstellen, daß eine derartige Aufgabenstellung nicht schon mal da gewesen wäre ...




=====================

DateiName = InterfaceName '_' InterfaceDirection '_' FN-Datum '_' FN-Sequenz '.' FN-Dateityp .

InterfaceName = 'TEMP1' ;
InterfaceDirection = 'IN' ;
FN-Datum = DATE_format_01 ; (* Format: JJJJMMTT *)
FN-Sequenz = Ziffer Ziffer ; (* [00..99] *)
FN-Dateityp = 'DAT' ;

(* -------------------------------------------------------------------- *)

DataFile = Header {Body} Trailer ;
Header = HeaderRecord NewLine ;
Body = BodyRecord NewLine ;
Trailer = TrailerRecord (NewLine | EndOfFile) ;

HeaderSeperator = HS ;
BodySeperator = BS ;
TrailerSeperator = TS ;

HS = '|' ;
BS = ';' ;
TS = '|' ;

HeaderRecord = H01 HS H02 HS H03 HS H04 ;
BodyRecord = B01 BS B02 BS B03 BS B04 BS B05 ;
TrailerRecord = T01 TS T02 ;

....

T01_Attributename = 'PROCESS_VERSION'
T01_Comment = 'version number of generating process'
T01_Datatype = VARCHAR(10)
T01_Validity = mandatory
T01_Value = *

T02_Attributename = 'AN_DS'
T02_Comment = 'count of data records in the file (exceptheader and except footer line)'
T02_Datatype = NUMBER(5)
T02_Validity = mandatory
T02_Value = *

/* definition von standard-datentypen

VARCHAR(10) = xxxxxxxx ?
NUMBER(5) = xxxxxxxxxxx ?

Zu EBNF gibt es zumindest ein Modul: Parse::EBNF
und zu CSV auch ein paar: CSV

Da sucht einer nach was ganz ähnlichem:https://www.xing.com/app/forum?op=showarticles;id=9926765

Gast+2008-09-08 19:42:09--

Da sucht einer nach was ganz ähnlichem:https://www.xing.com/app/forum?op=showarticles;id=9926765

na so ein Zufall ;-)
der hat aber auch noch nix gefunden

Gast+2008-09-08 18:20:14--

Zu EBNF gibt es zumindest ein Modul: Parse::EBNF
und zu CSV auch ein paar: CSV

wie ich schon schrieb, kenne ich mich mit perl fast garnicht aus. Ich wüßte nun auch nicht, wie ich aus diesen Modulen und unter Nutzung von ?welcher? Steuerdatei das gewünschte hinbekäme ...

unaware+2008-09-08 21:30:06--

wie ich schon schrieb, kenne ich mich mit perl fast garnicht aus.

Perl kann man lernen, das haben die meisten hier hinter sich oder sind gerade dabei. Und wenn es an einer bestimmten Stelle hakt, helfen wir auch gerne. Aber du kannst nicht davon ausgehen, dass wir deine Arbeit für dich machen.

moritz+2008-09-08 23:11:29--

Perl kann man lernen, das haben die meisten hier hinter sich oder sind gerade dabei. Und wenn es an einer bestimmten Stelle hakt, helfen wir auch gerne. Aber du kannst nicht davon ausgehen, dass wir deine Arbeit für dich machen.

na kalr kann man das lernen. Ich erwarte ja auch gar nicht, daß jemand meine arbeit macht.

Ich gehe halt einfach davon aus, daß manche Dinge schon mal gemacht wurden. Ich bin sicherlich nicht der erste, der csv Dateien mit perl verwurstet. Und was ist daran verwerflich, da bereits bestehendes mit zu verwerten?

Du solltest eines der fertigen Module zum parsen von CSV verwenden. Die Vailidierung des Formats wird dir sehr viel leichter fallen, wenn du YAML/JSON oder XML verwendest um dein Regelwerk für den Aufbau des Dokuments zu definieren. Wenn du erstmal das Regelwerk parsen musst, so wie du es darstellst, dann solltest du mit ParseRecDescent o.ä. anfangen. Davon rate ich aber ab solange du kein größere Programmiererfahrung hast.

ParseRecDescent ist (E)BNF in seiner Struktur sehr ähnlich und ParseRecDescent ist mächtiger als BNF.
Es sollte Möglich sein zumindest das BNF-Format ohne Änderung der Logik in ParseRecDescent überführen zu können.

zu CSV und BNF:
Einfach ist es Einzelne Felder auf Richtigkeit zu testen. Wenn aber Felder von einander Abhängen, so muß die ganze Zeile geprüft werden.
Schlimm wird es, wenn Zeilen von einader abhängen.

Gast+2008-09-10 01:00:02--

ParseRecDescent ist (E)BNF in seiner Struktur sehr ähnlich und ParseRecDescent ist mächtiger als BNF.
Es sollte Möglich sein zumindest das BNF-Format ohne Änderung der Logik in ParseRecDescent überführen zu können.

ok, ich schau mir das mal an

Quote

zu CSV und BNF:
Einfach ist es Einzelne Felder auf Richtigkeit zu testen. Wenn aber Felder von einander Abhängen, so muß die ganze Zeile geprüft werden.
Schlimm wird es, wenn Zeilen von einader abhängen.

die einzelnen Felder sollen geprüft werden auf:

syntax_1. Belegung=optional, mandatorisch, eindeutig
Wobei die Prüfung auf Eindeutigkeit (unique) sich eh nur auf die aktuelle Datei beziehen könnte, und dann schon genug Mühe macht (Feldwerte sammeln -> sortieren -> doppelte identifizieren.
==> nächst schwächerers Kriterium für unique Felder wäre "mandatorisch", das wäre auch schon ok

syntax_2. Format-Prüfung
vermutlich relativ leicht machbar (Grundtyp = String definierter Länge, numerischer Wert mit definierter Anzahl vorkomma/Nachkommastellen, oder Datum in einer bestimmten Formatform)

syntax_3. Wertebereich-Überprüfung
Da stelle ich mir einen regulären Ausdruck vor, dann sind zumindest "einfache" numerische und alfanumerische Dinge relativ leicht abprüfbar (incl. "*" oder "'a' | 'b' | 'c'" ) . Bei Datums-Formatangaben könnte es etwas kniffliger werden (z.B. "vorgefundene Uhrzeit muß größer/kleiner als $sysdate sein", oder: "Uhrzeit wird mit hh:mm:ss angegeben, aber mm:ss müssen 00:00 enthalten"



semantik_1: (Spaltenabhängigkeiten innerhalb einer Zeile)
zuvor benannte Urzeit-Bereichs-Prüfung könnte schon fast zu derartigen semantischen prüfungen zählen.
Spaltenabhängigkeiten kommen bei meinen Datenformaten auch vor, aber da könnte ich momentan noch drauf verzichten

semantik_2: (Zeilenabhängigkeiten zwischen Zeilen)
"Ende-Record 1. Spalte enthält die Anzahl aller Datenrecords" verlangt ein wenig Arithmetik-Kenntnisse, deises Feld gibts in jeder Datei. Auf dessen Auswertung müsste ich vermutlich initial verzichten
Die unter syntax_1 genannte eindeutigkeit (unique key) fällt im Prinzip in die gleiche Prüfklasse wie die Zählerei