Regex-Muster-Bibliothek

Über diese Bibliothek

Dies ist eine kuratierte, durchsuchbare Sammlung von 60+ häufig verwendeten regulären Ausdrücken, organisiert nach Kategorie. Jedes Muster enthält eine Beschreibung, die Regex selbst und Beispiel-Treffer. Klicken Sie auf ein Muster, um es zu kopieren, oder nutzen Sie das Schnelltest-Panel, um Text direkt auf dieser Seite zu validieren.

Alles läuft in Ihrem Browser, keine Muster oder Teststrings werden irgendwohin gesendet. Verwenden Sie diese Muster in JavaScript, Python, PHP, Java, Go oder jeder Sprache, die reguläre Ausdrücke unterstützt. Für fortgeschrittenes Testen mit Flags und Capture-Gruppen probieren Sie unseren Regex-Tester und Debugger.

Woher reguläre Ausdrücke stammen

Die mathematische Idee einer «regulären Menge» wurde 1951 von Stephen Cole Kleene im RAND-Forschungsmemorandum Representation of Events in Nerve Nets and Finite Automata formalisiert. Der Operator * auf dieser Seite heißt ihm zu Ehren immer noch Kleene-Stern. Ken Thompson verwandelte die Theorie in einen Algorithmus in seinem Juni-1968-Artikel in Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, und lieferte die erste Regex-Implementierung im QED-Editor bei Bell Labs aus. Bis 1973 trieb dieselbe Engine ed an, dann grep (die wörtliche Erweiterung ist «globally search for regular expression and print»), sed und awk. Larry Walls Perl (1987) und besonders Perl 5 (1994) fügten benannte Gruppen, Lookaround, nicht-gierige Quantifizierer und Unicode-Behandlung hinzu, die zum De-facto-Dialekt namens PCRE wurden, von Philip Hazel 1997 als Bibliothek nach C portiert.

Engine-Varianten und was sich zwischen ihnen ändert

Ein Muster, das in JavaScript sauber läuft, kann in Go stillschweigend scheitern und in POSIX direkt abgelehnt werden. Die fünf Varianten, denen ein Entwickler am wahrscheinlichsten begegnet:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): der Dialekt von grep, sed und awk auf einem Standard-Unix-System. Kein Lookaround, keine benannten Gruppen, keine Unicode-Eigenschafts-Escapes. BRE erfordert zusätzlich das Escapen von (, ), {, } und |.
• PCRE2 (Philip Hazel, 1997, aktuelle Hauptversion 10.x): der funktionsreichste Dialekt. Lookaround, benannte Gruppen (?<name>...), atomare Gruppen, possessive Quantifizierer, Rekursion. Verwendet von PHP preg_*, Apache, nginx, R.
• ECMAScript-Regex (ECMA-262, Regex-Abschnitt 22.2): der JavaScript-Dialekt. ES2018 fügte benannte Gruppen, Lookbehind und die Flags s (dotAll) und u (Unicode) hinzu. ES2022 fügte das Flag d für Match-Indizes hinzu. ES2024 fügte das Flag v mit Mengennotations-Klassen hinzu.
• Python re: nahe an PCRE, verwendet jedoch (?P<name>...) für benannte Gruppen (PEP 433) und einen anderen Verbose-Modus re.X. Das neuere Drittanbieter-Modul regex fügt rekursive Muster und POSIX-Longest-Match-Semantik hinzu.
• RE2 (Russ Cox, 2010): die Engine hinter Gos regexp und Rusts regex-Crate. Kein Lookaround, keine Rückwärtsreferenzen, keine possessiven Quantifizierer, mit Absicht. Der Kompromiss: garantierte lineare Zeit, kein katastrophales Backtracking. Wenn ein Muster aus dieser Bibliothek (?=...) oder \1 verwendet, wird es in Go nicht kompilieren.

Katastrophales Backtracking und ReDoS

Die meisten Regex-Engines in gängigen Sprachen (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) sind Backtracking-Engines. Wenn ein Muster mit verschachtelten Quantifizierern wie (a+)+ auf eine Eingabe trifft, die fast passt, kann die Engine eine exponentielle Anzahl alternativer Pfade ausprobieren, bevor sie aufgibt. Dies ist katastrophales Backtracking, und es ist die Grundlage der von OWASP katalogisierten Angriffsklasse ReDoS (Regular expression Denial of Service).

Stack Overflow, 20. Juli 2016: ein Muster, das zum Trimmen führender und nachgestellter Leerzeichen entwickelt wurde, angewandt auf einen Fragetext mit 20 000 aufeinanderfolgenden Leerzeichen, benötigte 11 Minuten CPU pro Anfrage und machte die Site 34 Minuten lang nicht erreichbar. Das Post-mortem im offiziellen Stack-Status-Blog empfahl, Trim-Regex durch nativen String-Trim zu ersetzen.

Cloudflare, 2. Juli 2019: eine WAF-Regel mit dem verschachtelten Quantifizierer-Muster .*(?:.*=.*) wurde global ausgerollt und verbrauchte 27 Minuten lang 100 % CPU auf jedem Edge-Server, wodurch große Teile des öffentlichen Internets offline gingen. Cloudflares Post-mortem in ihrem Blog schrieb den Wechsel zur regex-Crate von Rust (einer RE2-basierten, linearzeitigen Engine) das Verhindern einer Wiederholung zu.

Die defensiven Lektionen: verschachtelte Quantifizierer vermeiden ((a+)+, (a*)*, (a|aa)+); Trim im Stil \s+$ auf angreiferkontrollierten Eingaben vermeiden; atomare Gruppen (?>...) oder possessive Quantifizierer a++ in PCRE bevorzugen; und für hochdurchsatzbasierte Dienste eine RE2-basierte Engine in Erwägung ziehen.

E-Mail, URL, Telefon, Datum, Kreditkarte: wann man Regex nicht verwendet

E-Mail. Die vollständige Grammatik von RFC 5322 (Oktober 2008) kompiliert zu einer Regex von etwa 3 000 Zeichen. Die HTML5-Spezifikation des W3C für die Validierung von <input type="email"> verwendet eine viel kürzere «sieht-das-plausibel-nach-E-Mail-aus»-Regex, die der richtige Ausgangspunkt für clientseitige Hinweise ist. RFC 6531 (Februar 2012) erlaubt Nicht-ASCII-Adressen wie 用户@example.com, die eine reine ASCII-Regex fälschlicherweise ablehnt. Der Industriekonsens seit RFC 6532: validiere E-Mails nicht mit Regex, sondern sende stattdessen eine Verifizierungs-E-Mail.

URLs. RFC 3986 (Januar 2005) ist die generische URI-Syntax-Spezifikation, aber der WHATWG URL Living Standard weicht absichtlich davon ab, um dem zu entsprechen, was Browser tatsächlich akzeptieren. Verwende new URL("...") in JavaScript oder urllib.parse in Python statt einer Regex für alles, was über eine schnelle visuelle Prüfung hinausgeht.

Telefonnummern. Die ITU-T-Empfehlung E.164 (aktuelle Überarbeitung November 2010) erlaubt bis zu 15 Ziffern mit optionalem +-Präfix, aber länderspezifische Regeln variieren enorm. Googles Open-Source-Bibliothek libphonenumber kodiert die Regeln pro Land für jedes Territorium und ist der einzige zuverlässige länderübergreifende Validator.

Daten. Eine Regex wie ^\d{4}-\d{2}-\d{2}$ passt zum Kalenderformat ISO 8601-1:2019, akzeptiert aber auch 2026-02-31. Datumsgültigkeit erfordert Kalenderlogik, keine Mustererkennung; verwende Date.parse() oder eine Datumsbibliothek.

Kreditkarten. Eine Regex kann zur Ziffernlänge und zum IIN-Präfix passen (Visa beginnt mit 4, Mastercard mit 51-55 oder 2221-2720, Amex mit 34 oder 37), kann aber die Luhn-Prüfsumme nicht verifizieren (Hans Peter Luhn, IBM, US-Patent 2 950 048, erteilt August 1960). Luhn erfordert eine Ziffer-für-Ziffer-Summe modulo 10.

Häufige Arten, wie Entwickler diese Bibliothek nutzen

• Clientseitige Formularhinweise, mit dem Verständnis, dass ein Regex-Treffer ein Hinweis ist, keine endgültige Validierung.
• Log-Scraping, Zeitstempel, IPs, Fehlercodes und URLs aus Anwendungs-Logs in eine Pipeline ziehen.
• Einmalige Datenbereinigung: Leerzeichen normalisieren, HTML-Tags entfernen, zwischen Datumsformaten konvertieren, Titel slugifizieren.
• Editor-Suchen-und-Ersetzen in VS Code, Sublime, vim, IntelliJ, wo die Regex-Variante nah an PCRE liegt.
• Router- und URL-Übereinstimmungsmuster in Express, Flask, FastAPI, Rails.
• WAF- und Intrusion-Detection-Regeln, mit extremer Vorsicht vor ReDoS, wie der Cloudflare-Vorfall 2019 zeigte.
• Schnelle Zeichenkettentests im Testpanel am unteren Seitenrand, bevor das Muster in Code übernommen wird.

Häufige Fehler

• Anker vergessen. Ohne ^ und $ (oder \A und \z in PCRE) passt eine Validierungs-Regex, wenn das Muster irgendwo in der Zeichenkette erscheint. /\d{4}/ passt zu «year 2026 was good», was fast nie gewollt ist.
• Auf .* über mehrere Dinge vertrauen. <a href=".*"> auf der Eingabe <a href="a"><a href="b"> fängt über beide Tags hinweg, weil .* gierig ist. Verwende .*? für faul oder besser, parse mit einem echten Parser.
• Annehmen, dass der Punkt Zeilenumbrüche passt. Standardmäßig passt . zu allem außer Zeilenterminatoren. Verwende das Flag s (dotAll) in JS oder re.DOTALL in Python oder den Inline-Modifikator (?s) in PCRE.
• Annehmen, dass \w Nicht-ASCII-Buchstaben einschließt. Im ASCII-Modus ist \w gleich [a-zA-Z0-9_]. Füge das Flag u in JS hinzu (ES2018+) und verwende \p{L} für jeden Unicode-Buchstaben; in Python füge re.UNICODE hinzu (Standard in Python 3).
• Rückwärtsreferenzen in Go. Gos regexp ist RE2 und lehnt \1 zur Kompilierzeit ab. Der Fehler «error parsing regexp: invalid escape sequence: \1» bedeutet, dass das Muster in einen Nicht-Regex-Ansatz aufgeteilt werden muss.
• HTML mit Regex parsen. Bekanntermaßen nicht durchführbar: HTML ist keine reguläre Sprache. Verwende einen DOM-Parser (den eingebauten DOMParser des Browsers, cheerio, BeautifulSoup, lxml).

Weitere häufig gestellte Fragen

Warum verwenden manche Muster (?:...) statt (...)?

(?:...) ist eine nicht-einfangende Gruppe: sie gruppiert für Wiederholung oder Alternation, weist aber keinen Backreference-Slot zu. Es ist schneller und vermeidet die Verschmutzung von $1, $2 im Ergebnis-Array. Verwende (...), wenn du den eingefangenen Text extrahieren musst; verwende (?:...) nur zum Gruppieren.

Was sind die häufigsten Regex-Flags?

i Groß-/Kleinschreibung-unabhängig, g global (alle finden, JS-spezifisches Verhalten), m mehrzeilig (so dass ^ und $ Zeilengrenzen passen), s dotAll (so dass . Zeilenumbrüche passt, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v Mengennotations-Klassen (ES2024+). Kombiniere als /pattern/gimsu.

Wie matche ich ein literales Sonderzeichen?

Escapiere es mit einem Backslash. Die Regex-Metazeichen, die für einen literalen Match escapiert werden müssen, sind: . ^ $ * + ? ( ) [ ] { } | \ /. Innerhalb einer Zeichenklasse [...] ist die Menge der Sonderzeichen kleiner: nur ] \ ^ - müssen escapiert werden, je nach Position.

Kann ich die Muster dieser Bibliothek in Shell-Skripten verwenden?

Ja, mit Vorbehalten. grep verwendet standardmäßig POSIX BRE; grep -E verwendet ERE; grep -P verwendet PCRE auf Systemen, wo libpcre verlinkt ist (GNU grep, macOS grep mit Homebrew). Muster, die Lookaround, benannte Gruppen oder Unicode-Escapes verwenden, benötigen grep -P oder ripgrep (das Rusts RE2-basierte Engine verwendet und Lookaround ablehnt).

Werden diese Muster an einen Server gesendet?

Nein. Jede Regex auf dieser Seite, jede Suche, die du eintippst, und jede Zeichenkette, die du im Schnelltestpanel testest, wird in der JavaScript-Engine deines Browsers verarbeitet. Es wird kein Netzwerkaufruf getätigt. Die Musterdaten selbst werden als statische JSON-Datei im Seitenbundle ausgeliefert. Öffne den Netzwerk-Tab in DevTools zur Überprüfung.