RegEx-Formatierung

[idefix2]

Code:

(?x)  ^  (@#D(?:GREGORIAN|JULIAN|HEBREW|FRENCH\s*R)@  \s*)?    (?:(ABT|EST|CAL|INT) \s*)?  (?:(\d+) \s*)?  
(?:(JUN|AUG|VEND|TIS) \s*)? (\d+/\d+|\d*) \s* (B\.C\.|BC)?  $

Wenn nach dem BC keine Leerstellen folgen dürfen, sonst am Ende vor dem $ nochmal \s*

Die Erklärung zum Aufbau des Datums verstehe ich schon, nicht klar ist mir, was man mit so inhomogenen Datumsangaben in der Folge anfangen kann - aber das musst du wissen

[hansklok]

Zitat von idefix2:

Die Erklärung zum Aufbau des Datums verstehe ich schon, nicht klar ist mir, was man mit so inhomogenen Datumsangaben in der Folge anfangen kann - aber das musst du wissen

http://genwiki.genealogy.net/GEDCOM/DATE-Tag

[idefix2]

ok.

Was noch fehlt, ist die Behandlung des Klartexts in Klammern am Schluss:

Code:

(?:\( ([^)]*) \) \s* )

liefert dir den Text zwischen den Klammern, ohne die Klammern selbst - vorausgesetzt, der Text in den Klammern enthält selbst keine schliessende Klammer. Wenn das auch erlaubt sein soll, wäre es einfach (.*) statt ([^)]*)

[hansklok]

Schau mal bitte hier mein Beispielcode http://rubular.com/r/8DBJT9K0tH. Das matcht leider noch nicht alles.
Zumal die dualen Jahresangaben nur gesamt und nicht gesondert gematcht werden. Ich benötige aber jeweils einen Match für 1917 und 18.

[idefix2]

Klar.
Das ? nach dem letzten Klammerausdruck fehlt, deswegen matcht er nur die drei Ausdrücke, die (Muttis Geburtstag) enthalten.
Deshalb: (?:\( ([^)]*) \) \s* )?

Ich denke, es ist einfacher, die verbleibenden Probleme im Programmcode als via Regex zu lösen: Die Unterscheidung, welche Ziffern Jahreszahlen und welche Tage sind, ist im Regex schwierig - da müsste man Riesen Teilausdrücke duplizieren, um die verschiedenen Varianten richtig zu unterscheiden.
Die Jahreszahlen könntest du natürlich getrennt einfangen, dann bekommst du aber DREI verschiedene Ergebnisfelder für "einzige Jahreszahl", "Jahreszahl 1 von 2" und "Jahreszahl 2 von 2" - und ein Teil der Jahreszahl landet u.U. beim Tag, wenn kein Tag angegeben ist. Regex ist gut, aber derart komplexe Fallunterscheidungen sind auf der Programmebene besser aufgehoben.

[Dejan Vu]

Ist das eine Denksportaufgabe oder warum machst Du das mit RegEx?

Ich würde das nämlich als kleine Heuristik programmieren, also à la 'If Pos('HEBREW, text) <> 0 then'.

Dann kannst Du unit tests schreiben und Probleme in Ruhe dursteppen. Versteh mich nicht falsch: regEx kann das, nur wird das eben irgendwann einmal so kompliziert, dass das micht mehr wartbar ist. Lass doch mal etwas dazukommen. Dann sitzt Du doch tagelang an der Anpassung...

[idefix2]

Zitat von Dejan Vu:

Ist das eine Denksportaufgabe oder warum machst Du das mit RegEx?

Ich würde das nämlich als kleine Heuristik programmieren, also à la 'If Pos('HEBREW, text) <> 0 then'.

Regex ist Pos&Co in jedem Fall vorzuziehen, es ist ungleich bequemer. Schau dir an, wieviel Code du brauchst, um nur

Code:

(@#D(?:GREGORIAN|JULIAN|HEBREW|FRENCH\s*R)@)?\s*)

via Programm-Code zu scannen. Als regex ist das ein übersichtlicher, problemslos lesbarer Einzeiler (wobei ich mir ja eher den inneren und nicht den äusseren Klammerausdruck für die Weiterverarbeitung merken würde, wie er es macht). Ein Argument für die Verwendung von pos wäre da nur, dass du pro Programmzeile bezahlt wirst.

Allerdings würde ich derart komplexe Regexe eher aufspalten und dann per Programmlogik verknüpfen, vor allem dort, wo Abhängigkeiten zwichen den verschiedenen Varianten bestehen. Wenn du über einen einzigen Regex Tag, Monat und Jahr extrahieren willst, aber alle drei Angaben optional sind, wird es eben recht haarig. Das NUR mit Regex zu machen halte ich nicht für das Gelbe vom Ei, auch wenn es mit grossem Aufwand sicher möglich ist.

[hansklok]

Zitat von Dejan Vu:

Ist das eine Denksportaufgabe oder warum machst Du das mit RegEx?

Eine berechtigte Frage. Ich habe das mal mit den bekannten Springfunktionen gemacht, aber da in einer GEDCOM-Datei dutzende Datumsangaben vorkommen und so eine Datei mal schnell 10000-1000000 Zeilen haben kann, dachte ich, ich nehme RegEx, da das parsen da deutlich schneller vonstatten geht.

Zitat von idefix2:

Regex ist Pos&Co in jedem Fall vorzuziehen, es ist ungleich bequemer. Schau dir an, wieviel Code du brauchst, um nur

Code:

(@#D(?:GREGORIAN|JULIAN|HEBREW|FRENCH\s*R)@)?\s*)

via Programm-Code zu scannen.

Du sagst es.

Nun bisher wird ja auch nur eine Datumsangabe gepasst. Bedacht wurde noch nicht, dass es in Gedcom-Datumsangaben auch Doppeldatierung gibt:

Code:

BET 17 AUG 1917 AND CAL 21 AUG 1918

[idefix2]

Ein Fallstrick sind die "optionalen" Werte und die Abhängigkeiten.
Wenn ich es richtig verstehe, sind je nach Datumstyp unterschiedliche Monatsnamen möglich. Dann ist noch die Frage, ob du überprüfen musst, dass das zusammenpasst, oder ob du dich darauf verlassen kannst. Im zweiten Fall ist es einfacher, denn da kannst du per Regex auch Kombinationen erlauben, die keinen Sinn machen, und die man deswegen als ungültig verwerfen müsste.

Ein weiteres Problem sind die

Code:

\s*

, denn irgend eine Trennung zwischen den Zahlen brauchst du: Also zumindest entweder Monatsnamen (Buchstaben) oder Leerstellen, oder beides, um Zifferngruppen zu trennen. Das muss auch in die Regex Logik hinein, sonst landet, wie in ein paar der Beispiele, ein Teil der Jahreszahl in dem Feld, in dem du den Tag erwartest. Im nachhinein per Programm, wie ich in einem Post weiter oben geschrieben habe, ist es wahrscheinlich gar nicht mehr möglich, das sauber auseinanderzudividieren.


Vielleicht ist es zielführend, erst einfache regexausdrücke zu definieren und den kompletten regex aus diesen einfacheren ausdrücken zusammenzusetzen:

const
einfachesdatum = '.....'; // was auch immer
datumsbereich = '(?:BET\s+' + einfachesdatum + '\s+AND\s+' + einfachesdatum + ')';
datum = '(?:' + datumsbereich + '|' + einfachesdatum + ')';

etc.

Eine andere Idee, um das Parsen zu vereinfachen, wäre, erst einmal den String durchzugehen und prinzipiell überall, wo Buchstaben und Zahlen unmittelbar aufeinanderfolgen, eine Leerstelle einzufügen. Dann kannst du im Regex Trennzeichen zwischen den Gruppen zwingend voraussetzen, mit \s+ statt \s* wird das Erkennen der Pattern stabiler und wahrscheinlich auch schneller.

[Dejan Vu]

Zitat von idefix2:

Regex ist Pos&Co in jedem Fall vorzuziehen, es ist ungleich bequemer.

Findest Du wirklich dieses RegEx-Monstrum 'bequemer'? Würdest Du bei einer Aufgabe dieser Art *wirklich* das Forum bemühen müssen, wenn Du die 'Code'-Methode verwenden würdest?

Zitat:

Schau dir an, wieviel Code du brauchst...via Programm-Code zu scannen.

Wenig Code != Viel Qualität.

Zitat:

Ein Argument für die Verwendung von pos wäre da nur, dass du pro Programmzeile bezahlt wirst.

Wir werden dafür bezahlt, effizient und qualitativ hochwertig zu programmieren. Wir wählen also immer die Methode, die für die Aufgabenstellung am besten geeignet ist. So sehr ich RegEx mag und auch oft einsetze, würde ich davon abraten, wenn ich mehrere Tage benötigte, um den Ausdruck zu formulieren. Das passt irgendwie nicht.

Zitat:

Allerdings würde ich derart komplexe Regexe eher aufspalten und dann per Programmlogik verknüpfen,

Das ist doch mal ein Vorschlag.

Nicht falsch verstehen: RegEx an sich ist schon das richtige Mittel. Nur wenn es für den Programmierer zu komplex wird, wäre eine alternative Vorgehensweise durchaus in Erwägung zu ziehen.

Wenn Du das so hinbekommst, und auch bei Änderungen und Erweiterungen des Ausdrucks keine Probleme bekommst, super. Ich würde hier vermutlich doch etwas grübeln. Zeit ist Geld und daher nehme ich die Lösung, die langfristig am besten ist. Wobei ich mich neulich auch ertappt habe, ein RegEx zu finden, der bei einem SQL-Skript alle nicht deklarierten Variablen findet. Das war auch nicht ohne....