On-the-fly Regex-Tester: Regex-Lab

Auch mir hat das Teil sehr bei der Ausarbeitung von Ausdrücken geholfen (und nochmal ein Dank an herbivore).

Nur so als Tipp: Wenn ein Ausdruck im Tester funktioniert... aber im .Net Code nicht, dann kann es eigentlich fast nur daran liegen, dass per Default im Tester IgnoreCase geflaggt ist... (Habe ich dann nach mehr als 20 minütiger Suche auch irgendwann festgestellt).

Hallo Programmierhans, hallo zusammen,

danke für den Hinweis! Ich habe diesen bzw. die die folgenden Tipps in Kurzform in den Startbeitrag aufgenommen.

Klar, man sollte alle Flags so übernehmen, wie sie in Regex-Lab gesetzt sind bzw. wie man sie in Regex-Lab gesetzt hat. Bzw. sollte man die Flags in Regex-Lab gleich so setzen, wie man sie später im Code haben möchte.

Aus meiner Sicht gibt es einen weiteren Grund, warum ein Pattern, der in Regex-Lab funktioniert, im Code nicht auf Anhieb funktioniert, nämlich wenn man ihn in ein String-Literal schreibt, ohne richtig zu escapen. Um nicht jeden enthaltenen Blackslash verdoppeln zu müssen, bietet es sich an, vor das String-Literal ein @ zu schreiben (siehe [FAQ] Was bedeutet das @ (=at) vor String-Literalen? Und: Wissenswertes zu Escape-Sequenzen). Selbst dann muss man allerdings noch darauf achten, wenn im Pattern Anführungszeichen (insbesondere zwei Anführungszeichen hintereinander) enthalten sind. Anführungszeichen müssen in String-Literalen mit @ gedoppelt werden, um sie zu escapen.

herbivore

Geiles Teil,

schmiert auch bei codepoints außerhalb der Basic Multilingual Plane (BMP) nicht ab, habe heute erst Expresso damit zum Absturz gebracht, während Regex-Lab einen astreinen capture hatte.

Meine regex: [\u0009\u000a\u000d\u0020-\ud7ff\ue000-\ufffd]|(\ud800-\udbff)|((?≤[\ud800-\udbff])[\udc00-\udfff])

Mein Input: (codepoint 128685)

Hallo yetibrain,

das freut mich zu hören. Ich möchte mich jedoch nicht mit fremden Federn schmücken. Das Lob gebührt den Entwicklern des .NET-Framworks, deren Regex-Methoden ich lediglich aufrufe.

herbivore