Skip to content

Guide

Regex-Spickzettel: gängige Muster, die jeder Entwickler braucht

Fünfundzwanzig Muster, die Sie wirklich nutzen, die Greedy/Lazy-Unterscheidung, der die Hälfte aller Regex-Bugs zu verdanken ist, und wo sich JavaScript-Regex von PCRE unterscheidet.

By Published

Eine funktionierende Regex ist kein Einzeiler, den man auswendig lernt; sie ist ein Einzeiler plus die Annahmen über Ihre Eingabe und Ihren Dialekt. Dieser Spickzettel ergänzt jedes Muster um das, was es tatsächlich matcht, die Randfälle, die es verfehlt, und in welchen Regex-Engines es funktioniert. Werfen Sie jedes davon in unseren Live-Regex-Tester, um Treffer und Captures interaktiv zu sehen.

Verwendete Notation

Muster werden ohne die umgebenden /.../-Begrenzer gezeigt, außer wo Flags zählen. Gehen Sie davon aus, dass ^ und $ an einen einzelnen Wert (das ganze Feld) verankert sind, nicht mehrzeilig. Wenn ein Muster nicht universelle Funktionen nutzt, erläutert der Dialekthinweis, in welchen Engines es funktioniert. Wo es sowohl eine permissive als auch eine strikte Form gibt, werden beide angegeben.

Bezeichner und Namen

E-Mail — permissiv

^[^\s@]+@[^\s@]+\.[^\s@]+$

Drei Zeichenklassen, getrennt durch @ und ., von denen keine Leerraum oder ein weiteres@ enthält. Sie akzeptiert nahezu jede reale E-Mail und lehnt die offensichtlichsten Tippfehler ab. Sie validiert nicht gegen RFC 5322 – zitierte lokale Teile und IP-Literal-Domains rutschen durch oder werden abgelehnt, je nach Ecke.

E-Mail — HTML5-Formularspezifikation

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

Das Muster, das WHATWG für HTML input type=“email“ festlegt. Strenger als die permissive Form, beansprucht aber dennoch keine vollständige RFC-5322-Abdeckung – die Spezifikation nennt sich ausdrücklich „bewusst nicht konform“. Verwenden Sie dies, wenn Sie das Browserverhalten nachbilden wollen.

URL — nur HTTPS

^https://[^\s/$.?#].[^\s]*$

Permissive HTTPS-URL. Lehnt offensichtlichen Müll ab, akzeptiert aber alles hinter dem Host, das kein Leerraum ist. Für echte Validierung verlassen Sie sich auf new URL() in der Wirtssprache; Regex dient dem Filtern von Eingaben, nicht ihrem Parsen.

Slug (URL-sicherer Bezeichner)

^[a-z0-9]+(?:-[a-z0-9]+)*$

Kleinbuchstaben und Ziffern mit einzelnen Bindestrichen zwischen den Gruppen. Keine führenden oder abschließenden Bindestriche, keine Doppelbindestriche. Das ist die Slug-Form, die jedes CMS verwendet.

Benutzername — alphanumerisch und Unterstrich, 3–20 Zeichen

^[A-Za-z0-9_]{3,20}$

UUID (beliebige Version)

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

UUID v4 (strikt)

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

Erzwingt die 4 an Position 13 und die Varianten-Bits an Position 17 (eines von 8, 9, a, b). Verwenden Sie dies, wenn Ihnen die Version wichtig ist, nicht nur die Form.

Zahlen, Geld, Codes

Ganzzahl (mit Vorzeichen)

^-?\d+$

Dezimalzahl (mit Vorzeichen, optionaler Nachkommateil)

^-?\d+(?:\.\d+)?$

Geldbetrag (US-Stil)

^\$?\d{1,3}(?:,\d{3})*(?:\.\d{2})?$

Optionales Dollarzeichen, Tausendertrennzeichen alle drei Ziffern, optionale zwei Nachkommastellen für Cent. Behandelt keine negativen Werte; für die Buchhaltung stellen Sie ^-? voran oder klammern es ein.

Hex-Farbe (3, 4, 6 oder 8 Stellen)

^#(?:[0-9a-fA-F]{3,4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$

Die 4- und 8-stelligen Formen enthalten einen Alphakanal (#RRGGBBAA), der von CSS Color Level 4 und jedem modernen Browser unterstützt wird.

Semantische Version (SemVer 2.0.0)

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Dies ist die kanonische Regex, die auf semver.org veröffentlicht ist. Sie erfasst Major, Minor, Patch, optionalen Pre-Release und optionale Build-Metadaten. Sie lehnt führende Nullen in numerischen Komponenten korrekt ab.

Datum und Uhrzeit

ISO-8601-Datum (YYYY-MM-DD)

^\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])$

Beschränkt den Monat auf 01–12 und den Tag auf 01–31. Prüft nicht, ob der Tag im angegebenen Monat existiert (30. Feb. geht durch). Für echte Datumsvalidierung mit der Wirtssprache parsen und auf Fehler prüfen.

ISO-8601-Zeitstempel mit Zeitzone

^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d+)?(?:Z|[+-]\d{2}:\d{2})$

Akzeptiert Z für UTC oder einen numerischen Offset wie +02:00. Erlaubt optionale Sekundenbruchteile.

HH:MM 24-Stunden-Zeit

^(?:[01]\d|2[0-3]):[0-5]\d$

Netzwerkadressen

IPv4

^(?:(?:25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)$

Oktettbereich streng 0–255. Lehnt führende Nullen wie 192.168.001.001 ab (für Menschen eindeutig, doch manche Systeme interpretieren sie als oktal, daher ist die Ablehnung vertretbar).

IPv6 — praxistauglich

^(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$

Matcht die kanonische Achtergruppenform. Sie matcht kein IPv6 mit ::-Kompression oder mit eingebettetem IPv4 wie ::ffff:192.0.2.1. Die vollständige RFC-4291-Regex ist über hundert Zeichen lang; für den Produktiveinsatz verlassen Sie sich auf das inet-pton-Äquivalent Ihrer Sprache.

MAC-Adresse

^(?:[0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}$

Portnummer

^(?:6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|[1-5]\d{4}|[1-9]\d{0,3}|0)$

0–65535, streng begrenzt.

Telefonnummern

US-Telefon — permissiv

^(?:\+?1[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$

Optionales +1, optionale Klammern um die Vorwahl, optionale Trennzeichen aus Bindestrich, Punkt oder Leerzeichen. Akzeptiert die gängigen US-Formate; lehnt Nicht-US-Nummern ab.

Internationales Telefon (E.164)

^\+[1-9]\d{1,14}$

E.164 ist die ITU-Spezifikation: führendes +, Ländercode mit Nicht-Null-Beginn, Gesamtlänge 2–15 Ziffern einschließlich Ländercode. Keine Leerzeichen, keine Klammern. Das ist das Format, das jedes SMS-Gateway und die meisten CRMs erwarten.

Zeichenketten und Struktur

Nur-Leerraum-Zeichenkette

^\s*$

Führenden/abschließenden Leerraum entfernen (durch leer ersetzen)

^\s+|\s+$

Mehrere Leerzeichen zu einem reduzieren (durch einzelnes Leerzeichen ersetzen)

\s{2,}

Inhalt zwischen Klammern matchen (lazy)

\[([^\]]*)\]

Erfasst Zeichen, die keine schließende Klammer sind – die negierte Zeichenklasse ist der sauberste Weg für ein nicht gieriges „alles bis zum nächsten Begrenzer“.

Quantorenverhalten

Greedy (Standard)

*, +, ? und {n,m} matchen standardmäßig so viel wie möglich und geben dann zurück, um einen Match für den Rest des Musters zu finden. Bei <b>hi</b><b>bye</b> matcht das Muster <b>.*</b> die gesamte Zeichenkette, nicht das erste Tag-Paar.

Lazy (Suffix ?)

Fügen Sie ein ? hinzu, damit ein Quantor so wenig wie möglich matcht. <b>.*?</b> matcht nur <b>hi</b>, was fast immer das ist, was Sie wollten.

Possessive und atomare Gruppen

Possessive Quantoren (*+, ++) und atomare Gruppen ((?>...)) weigern sich, nach einem Match zurückzugehen. Sie eliminieren katastrophales Backtracking bei pathologischen Eingaben. PCRE, Java und Ruby unterstützen sie; JavaScript nicht (nutzen Sie einen Workaround wie ein Lookahead mit Rückwärtsreferenz).

Lookahead und Lookbehind

Lookarounds behaupten eine Bedingung, ohne Zeichen zu verbrauchen. Sie sind nullbreit.

  • Positives Lookahead (?=...) – „gefolgt von“. \d+(?=px) matcht Ziffern, auf die px folgt, ohne das px in den Match aufzunehmen.
  • Negatives Lookahead (?!...) – „nicht gefolgt von“. foo(?!bar) matcht foo, auf das nicht bar folgt.
  • Positives Lookbehind (?<=...) – „vorangestellt von“.
  • Negatives Lookbehind (?<!...) – „nicht vorangestellt von“.

JavaScript unterstützt Lookahead in allen Versionen, Lookbehind erst ab ES2018. Viele ältere Engines (und die V8-Version in manchen gebündelten Node-Builds) beschränken Lookbehinds auf Muster fester Breite; PCRE und Pythons regex-Modul erlauben variable Breite.

Erwähnenswerte Dialektunterschiede

  • JavaScript: keine possessiven Quantoren, keine atomaren Gruppen, Lookbehind ab ES2018. Das g-Flag (global) lässt String.match alle Treffer zurückgeben, ändert aber das Verhalten von String.replace – die fehleranfälligste Ecke der JS-Regex.
  • PCRE (Perl-kompatibel): die Funktions-Obermenge. Genutzt von PHP, nginx, vielen Kommandozeilenwerkzeugen. Rekursive Muster, Bedingungen, possessive Quantoren, atomare Gruppen, benannte Captures – alles unterstützt.
  • Python: das standardmäßige re-Modul kommt PCRE nahe, minus einiger Funktionen. Das Drittanbieter-regex-Modul fügt den Rest hinzu, plus Lookbehinds variabler Breite und atomare Gruppen.
  • Go (RE2): bewusst lineare Laufzeit. Keine Rückwärtsreferenzen, kein Lookaround. Langsamer bei einfachen Mustern, immun gegen katastrophales Backtracking. Rusts regex-Crate ist dieselbe Familie.
  • .NET: ähnlich wie PCRE, plus einige einzigartige Funktionen wie balancierende Gruppen (mit denen man tatsächlich verschachtelte Klammern matchen kann – auf eine Weise, die jeder andere Dialekt nicht kann).

Ein über die Dialekte hinweg hervorzuhebendes Flag: Unicode-Eigenschaftsescapes (\p{Letter}, \p{Number}, \p{Script=Greek}) matchen nach Codepunkt-Kategorie statt nach rohem Byte. JavaScript braucht das u-Flag, PCRE braucht (*UCP) oder den /u-Modifikator, Python unterstützt sie im Drittanbieter-regex-Modul. Ohne sie bedeutet \w nur ASCII [A-Za-z0-9_], und Ihr „beliebigen Namen matchen“-Muster lehnt stillschweigend die halbe Welt ab.

Die Muster, die man nie schreiben sollte

  • HTML-Parsen. Nutzen Sie einen echten Parser (DOMParser im Browser, BeautifulSoup in Python, go-html in Go). Regex kann ein einzelnes Attribut aus einer wohlbekannten Form extrahieren, mehr nicht.
  • JSON-Parsen. Jede Sprache hat JSON.parse. Nutzen Sie es.
  • Programmiersprachen parsen. Nutzen Sie einen Parser-Kombinator oder eine echte Grammatik.
  • Alles, was verschachtelte Begrenzer matchen muss. Klassische reguläre Sprachen können nicht zählen. Nutzen Sie einen Parser.

Das ehrliche Fazit

Regex ist ein scharfes Werkzeug mit einem kleinen, gut verstandenen Anwendungsbereich: Zeichenketten fester Form, einfaches Eingabefiltern, Suchen-und-Ersetzen in Texteditoren. Die Muster in diesem Spickzettel decken die 80 % der Fälle ab, die im Alltagscode vorkommen. Für die 20 %, die regexförmig aussehen, es aber nicht sind – verschachtelte Strukturen, natürliche Sprache, semantische Validierung – greifen Sie stattdessen zu einem Parser.

Und wenn Sie eine Regex schreiben, fügen Sie sie mit drei repräsentativen und drei pathologischen Eingaben in unseren Tester ein, bevor Sie sie committen. Das Muster, das bei Ihrem einen Testfall funktioniert, ist das Muster, das bei jemand anderem die Produktion lahmlegt.

Frequently asked questions

Warum lehnt meine E-Mail-Regex gültige Adressen ab?
Weil die RFC-5322-Grammatik für gültige E-Mail-Adressen über eine Seite lang ist und Konstrukte wie zitierte lokale Teile ("user name"@example.com) und IP-Literal-Domains (user@[192.168.0.1]) umfasst. Die meisten „E-Mail-Regexe“ erzwingen nur eine winzige gemeinsame Teilmenge. Für echte Validierung senden Sie eine Bestätigungs-E-Mail – die Regex kann nur offensichtliche Tippfehler herausfiltern.
Unterscheidet sich der Regex-Dialekt wirklich so stark zwischen Sprachen?
Ja. JavaScript unterstützt Lookahead, bekam Lookbehind aber erst 2018 (ES2018) und benannte Gruppen im selben Release. Python nutzt re für einfache Regex und regex für fortgeschrittene Funktionen wie rekursive Muster. PCRE hat die meisten Funktionen und kommt einer „Regex-Obermenge“ am nächsten. .NET hat seine eigenen Eigenheiten. Testen Sie immer in der tatsächlichen Laufzeitumgebung, nicht in regex101 mit dem falschen Dialekt.
Greedy vs. Lazy-Quantoren – welche will ich?
Greedy (Standard) matcht so viel wie möglich; Lazy (Suffix ?) matcht so wenig wie möglich. Für .* innerhalb von HTML-Tags wollen Sie fast immer Lazy: .*? – sonst matcht <b>hi</b><b>bye</b> alles vom ersten <b> bis zum letzten </b>. Beim numerischen Parsen mit bekannter Feldlänge ist Greedy meist in Ordnung.
Wann sollte ich keine Regex verwenden?
Beim Parsen von HTML, JSON, YAML, Programmiersprachen oder allem mit verschachtelter Struktur. Regex ist ein Werkzeug für reguläre Sprachen; sobald Sie zählen oder rekursieren müssen (verschachtelte Klammern, offene/geschlossene Tags), nehmen Sie einen echten Parser. Die „HTML mit Regex parsen“-Antwort auf Stack Overflow wurde zum Kultklassiker, weil der Rat korrekt ist.
Wie validiert man eine URL am sichersten?
Übergeben Sie sie dem URL-Konstruktor der tatsächlichen Sprache – JavaScripts new URL(input), Pythons urllib.parse.urlparse, Javas java.net.URI. Diese setzen die relevanten RFCs um und behandeln Randfälle (internationale Domains, Portbereiche, Schema-Validierung), die eine Regex nicht abdeckt. Nutzen Sie Regex nur, um vor diesem Aufruf auf syntaktische Plausibilität zu filtern.
Warum ist meine Regex bei bestimmten Eingaben so langsam?
Katastrophales Backtracking. Muster mit verschachtelten oder überlappenden Quantoren – wie (a+)+ oder (.*).* – können bei bestimmten Eingaben exponentielle Zeit brauchen. Der globale Cloudflare-Ausfall im Juli 2019 war eine Regex, die genau das tat. Gegenmaßnahmen: verschachtelte Quantoren vermeiden, atomare Gruppen (?>...) oder possessive Quantoren in unterstützenden Dialekten nutzen, oder eine Engine mit linearer Laufzeit wie Rusts regex oder Googles RE2 einsetzen.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

Related

Published May 31, 2026