@Programmierer:
wir stehen auf der selben Seite! Was du schreibst ist mir alles klar und
du hast meine Zustimmung.
Deswegen wollte ich dem TO sagen, wie es richtig geht.
Gleichzeitig wollte ich ihn aber nicht entmutigen, weil ich weiß, dass
man mit Regexes (+ Zusatzlogik) recht weit kommen kann.
Dazu ein lustiger Schwank aus meinem früheren Entwicklerdasein:
Ich war mal in einem Projekt, da musste im Wesentlichen HTML geparsed
werden, um dann ein paar Spezialelemente durch personalisierte Daten zu
ersetzen (Herr/Frau, Vorname, Nachname, vorbereitete Kontent-Blöcke).
Mein erster Vorschlag war, dafür eine Template-Engine zu nehmen. Das
wurde abgelehnt. Ich kam später in das Projekt "und sie hatten da schon
was", das sie auch weiter für die Personalisierung von E-Mails verwenden
wollten. Meine Aufgabe war es, etwas ähnliches fürs Web zu bauen (Idee:
personalisierte Landing Pages und Formulare).
Also habe ich mir den E-Mail-Code angeschaut und eine
Regex-Replace-Hölle mit Ausnahmeregeln gefunden.
Wenig begeistert schlug ich einen richtigen Parser mit Grammatik vor.
Beim E-Mail-Versand hätte das zusätzlich den Vorteil gehabt, dass man
den geparsten AST aufbewahren kann. Für jede neue personalisierte Mail
muss dann nur einmal der AST traversiert werden, anstelle bei jeder
neuen Mail ein halbes dutzend mal mit Regexes drüberlaufen zu müssen.
Das wurde auch abgelehnt, weil der Entwickler der Regex-Lösung eine Art
Guru-Status hatte. Aber immerhin verstand ich langsam, warum man eine
fast dreistellige Anzahl an Servern für den Mailversand brauchte...
Nach langem Hin und Her durfte ich es wenigstens in meinem Teil richtig
machen. Als Parser habe ich ANTLR ausgewählt und ich weiß daher aus
Erfahrung, dass das etliche Tage dauern kann, wenn man es das erste mal
macht. Selbst wenn man ein anständiger Programmierer ist und die Worte
Grammatik und kontextfrei schon mal gehört hat.
Im Ergebnis haben beide Lösungen funktioniert.
Änderungen an meinem Code, z.B. ein neues Element hinzufügen, musste ich
allerdings selber machen, weil der Code "so kompliziert" war.
Aber eigentlich war es einfach: 1. Grammatik anpassen, so dass für das
neue Knotenelement eine neue Klasse instantiiert wird. 2. Neue
Knotenklasse mit zusätzlicher Funktionalität schreiben.
Auf der anderen Seite war das schwieriger. Die ganze Parserei war in
einem File, das mit jedem neuen Element größer wurde. Und dann gab es
darin einen (für mich unverständlichen) Wust an Bedingungen und
Sonderregeln, die bei jedem neuen Element teilweise angepasst oder
repliziert werden mussten.
Und dann gab es immer wieder unerwartete Einschränkungen: z.B. waren
Anführungszeichen und spitze Klammern in einzeiligen Kommentaren
abgefangen, spitze Klammern in einem Attributwert dagegen nicht.
Aber letztlich konnte man damit trotzdem arbeiten. Sowas macht man dann
halt nicht, mit der Zeit lernt man die Eigenheiten des Systems kennen.
Und auch auf meiner Seite will ich nicht verschweigen, dass es bei
ungültigen (d.h. nicht der Grammatik entsprechenden) Eingabedaten gar
nicht so leicht ist, eine Fehlermeldung mit hilfreicher Angabe zur
Problemstelle zu geben.