Hi,

wahrscheinlich ne Art Blade oder Twig Template was du da hast. Egal, jedenfalls mit Regex klappt das eigl recht gut: regex101.com/r/OwyjCw/1


Link

jan99 schrieb:

mehrere in einer Zeile

findest Du mit der Match.NextMatch Methode: learn.microsoft.com/de-de/dotn…tch?view=netframework-4.8

"\" vor "{" und "}" ist unnötig.

ich denke doch. In solchen Klammern notiert man im RegexPattern, wieviele Wiederholungen erwartet werden.
Kann sein, dass die Regex-Engine aus dem Kontext erkennt, dass das hier nicht der Fall ist, aber mein Stand der BestPractice ist, Zeichen zu escapen, die im Regex Funktionalität triggern.

jan99 schrieb:

Am Ende möchte ich eine Liste der Platzhalter haben

Die gibts unter Regex.Matches statt Regex.Match. Man kann mit Lookarounds sogar die Klammern aus den Matches entfernen, also das er wirklich nur das dazwischen erfasst.
(?<={{)[^}]+(?=}}).
Mit Capturing Groups wäre das Pattern einfacher dafür wäre der Code ein bissle länger.

ErfinderDesRades schrieb:

Zeichen zu escapen

Regex ist da ganz eigen manchmal wollen die nur die Klammer_auf escaped haben und bei Klammer_zu ist es egal. Und jede Version ist dann auch noch anders

Einen Lookarround halte ich hier für übertrieben eine NamedCapturingGroup sollte vollkommen ausreichen. Also z.B. \{\{(?<Text>.+?)\}\} dann kannst du über Match.Groups["Text"].Value auf den Wert zugreifen.

@Eierlein unnötig in speziell genau diesem Fall womöglich schon, ich würde trotzdem immer empfehlen, jegliche Metazeichen zu escapen wenn man sie als Literale benutzen möchte (klick). Das beseitigt zum einen Kompatibilitätsprobleme und zum anderen kann der Pattern so flexibler erweitert werden. Schlampige Pattern zu basteln weil man sich Tastendruck sparen kann steht denke ich in keinem Verhältnis^^


Link

@Fakiz Na erstmal kann man mit Lookarounds nicht übertreiben. Entweder man braucht den Teilstring oder nicht.
Capturing Groups benutze ich eher, wenn ich den Match und die Captures brauche.

Bitte nicht falsch verstehen Lookarounds sind eine tolle Sache wenn man sie an den richtigen Stellen einsetzt. Für das oben genannte Problem sind Sie aber wie "mit Kanonen auf Spatzen schießen". Du kannst ja mal ne CapturingGroup und nen Lookaround bei regex101 gegeneinander antreten lassen mit dem besagten Problem.

Und was soll man da sehen? Es gibt keine Kanonen in Regex in dem Sinne.

Die Performance von RegEx ist iwie schon ein gern diskutiertes Thema, oder? Ja es stimmt, Lookarounds sind heavier als einfach die Capturing Groups zu fetchen und die Matches dann durch ein Trim zu jagen um die curly braces loszuwerden. Speziell ranzig ist RegEx vor allem in Verbindung mit Datenbanken - was mit LIKE raussuchen zu müssen ist schon madig, aber dann noch ein RegEx ... überaus unangenehm (zumeist liegt der Notwendigkeit hierfür aber schon ein fehlerhaftes Datenbankdesign zugrunde).

Regex ist da ganz eigen manchmal ..

Nö, es gibt einfach verschiedene Arten von RegEx-Engines (ich persönlich favorisiere PCRE). Grundsätzlich lieber einmal mehr escaped als einmal zu wenig.

Es gibt keine Kanonen in Regex in dem Sinne

RegEx IST die Kanone

Fakt is, RegEx ist halt geil, und wenn man die Regeln verstanden hat, macht's einfach nur Spaß es zu benutzen. Super für das finden oder Verarbeiten von Texten oder zum greppen von Daten auf der Shell.

Ich finde überhaupt auch das Performance Argument komplett unnötig. RegEx ist hier Performance-Nutzen-Technisch der beste Weg um das Problem zu lösen. Oder will man den String manuell tokenisieren um an die gesuchten Teilstrings zu kommen? - Nein, sicher nicht. Über Performance-Optimierung kann man sich wenn man geil drauf ist auslassen in Fällen wo es Relevanz hat, das heißt wenn man Gigabyty große Dateien parsen oder ein RegEx SELECT auf Tabellen mit Millionen von Rows absetzen muss. Das ist hier nicht der Fall, und es interessiert sicher auch keinen ob die Ergebnisse eine Millisekunde schneller da sind.

Performance ist in den allermeisten Fällen in denen man RegEx benutzt völlig irrelevant.

Für das wofür man RegEx die meiste Zeit braucht kann man jederzeit die Pattern so komplex und ranzig zusammenschustern wie man lustig ist, man bemerkt bei der Ausführung keinen nennenswerten Unterschied. Es interessiert einfach nicht. Man kann RegEx immer und für alles verwenden und muss kein schlechtes Gewissen haben, auch nicht wenn einer mit seinem Performance-Mimimi dahergelaufen kommt.

Wann man RegEx nicht verwenden soll:
- wenn man es mit übertrieben großen Datenmengen zu tun hat
- wenn man versucht, RegEx zu verwenden für Aufgaben die reguläre Ausdrücke nicht leisten können oder für es Parser gibt (verschachtelte Strukturen, XML oder HTML)

Für jeden anderen Fall der hier nicht gelistet ist, kann man jederzeit RegEx nehmen, warum auch nicht. Außer es gibt eine einfachere Möglichkeit (zB wenn Substring o.ä. ausreicht).


Link

Ich denke, Regex wurde doch genau dafür entwickelt um Text zu durchsuchen? Was sind denn die Alternativen? Selber programmieren? Ist das nicht viel eher die "Kanone"

@Haudruferzappeltnoch RegEx wurde auch genau dafür entwickelt, genau so wie Wildcards in der Shell dafür entwickelt wurden, schnell mit Dateien umzugehen.

Die Alternativen hängen doch ganz davon ab, was du machen willst?
Willst du JSON, YAML, XML und Co parsen: nimm einen Parser.

In deinem Fall reicht ein ganz einfacher Regex mit einer Lookup-Table.

Etwas ganz schlichtes wie:



wäre in deinem Fall mMn ganz angebracht. Die genauen Implementierungsdetails sind ja erstmal egal und mit einem ganz einfachen Regex verstehst du auch in drei Wochen noch, was du mit deinem Code mal erreichen wolltest.

Was meinst du "in meinem Fall"? Mein Fall ist quasi wie es TE schon gemacht hat, nur eben + die zwei Punkte die ich nannte. Siehe Post 3

@Haudruferzappeltnoch Du warst mit letzterem nicht gemeint. Das hätte ich klarer schreiben sollen.

In dem Fall des TE würde ich es so implementieren. Ganz simpel mit kleinem RegEx, ohne Schnickschnack.