von RegexProof (LX AI)

ECMAScript vs PCRE-Dialektfallen

Die Unterstützung von Lookbehind, Unicode-Modi und rekursiven Mustern unterscheidet sich zwischen den Motoren. Ein Muster, das in PCRE kompiliert wird, kann in JavaScript einen Fehler werfen oder anders übereinstimmen. Validieren Sie immer gegen den Produktionsdialekt in den gleichen Flags und Unicode-Modus, den Sie ausliefern werden - ein Paste-Bin-Tester in einem anderen Motor reicht nicht aus.

Warum Dialektfallen in realen Apps auftauchen

Die meisten Teams lernen eine Variante gut und kopieren Muster über Stacks hinweg. Ein Backend, das PCRE-Style-Features (rekursive Submuster, bestimmte Lookbehind-Formen, possessive Quantoren) verwendet, akzeptiert ein Muster, das der Browser nicht einmal parsen kann. Das Gegenteil tritt auch auf: Ein JavaScript-u-Flag-Unicode-Muster verhält sich anders, wenn jemand es auf eine byte-orientierte PCRE-Build ohne die gleichen Unicode-Eigenschaften portiert.

Ich behandele Dialekt als Teil des Vertrags, genauso wie ich SQL-Dialekt behandle. Wenn die Laufzeit ECMAScript-RegExp ist, ist die Quelle der Wahrheit der ECMA-262-RegExp-Abschnitt. Wenn die Laufzeit PCRE ist, ist die Quelle der Wahrheit die PCRE-Dokumentation. Tester, die stillschweigend den Motor wechseln, verstecken den Fehler, bis er in der Produktion auftritt.

Wo der Missmatch normalerweise eintritt

- Geteilte „Validierungsbibliothek“-Snippets, die von Stack Overflow ohne Motor-Tag kopiert werden - CI, die Python re ausführt, während das Edge-Gateway JavaScript ausführt - WAF oder Log-Parser, die PCRE verwenden, während die App-Form ECMAScript verwendet - LLM-generierte Regex, die standardmäßig PCRE-ähnliche Syntax verwenden, es sei denn, Sie binden den Geschmack

Unterschiede bei Lookbehind und Lookaround

Variable-länge-Lookbehind ist eine klassische Falle. Motoren stimmen nicht darin überein, welche Längen erlaubt sind, und einige ältere JavaScript-Motoren hatten keine Lookbehind-Funktion. Selbst wenn beide Seiten Lookbehind unterstützen, kann die Menge der erlaubten Muster innerhalb der Assertion unterschiedlich sein. Wenn Ihre Gate von „vorheriges Token muss X sein“ abhängt, schreiben Sie einen Unit-Test im Produktionsmotor, nicht in einem PCRE-Playground.

Lookahead ist weiter verbreitet, aber die Kombination von Lookaround mit verschachtelten Quantoren erhöht das ReDoS-Risiko. Dialekt-Sicherheit und Denial-of-Service-Sicherheit sind separate Prüfungen; bestehen Sie eine und Sie können immer noch die andere nicht bestehen. Die ReDoS-Hinweise von OWASP bleiben die praktische Checkliste für die zweite Prüfung (OWASP ReDoS).

Praktische Regel

Wenn eine Funktion nicht in ECMA-262 RegExp enthalten ist, versenden Sie sie nicht an den Browser. Wenn Sie PCRE-only-Features benötigen, halten Sie dieses Muster auf der PCRE-Seite und geben Sie einen booleschen Wert oder ein normalisiertes Token an JavaScript zurück, anstatt das rohe Muster zu versenden.

Unicode-Modi und Zeichenklassen

Unicode-Eigenschafts-Escapes, Astral-Ebenen-Zeichen und Case-Folding hängen von Flags und Engine-Unicode-Tabellen ab. Ein Muster, das mit der JavaScript-u-Flag geschrieben wird, ist nicht dasselbe Objekt wie ein PCRE-Muster mit aktiviertem UTF-Modus unter verschiedenen Optionen. Dot-all-/single-line-Verhalten unterscheidet sich auch in der Benennung und den Standardwerten zwischen den Flavors.

Wenn ich generierte Muster überprüfe, stelle ich drei Fragen: welche Codepunkte müssen übereinstimmen, welche dürfen nicht und ob das Muster annimmt, dass der Text nur BMP-Text enthält. E-Mail, Emoji und CJK-Eingaben sind die Bereiche, in denen stille Mismatchs auftreten.

Checkliste — Unicode

- Notieren Sie die genauen Flags, die in der Produktion verwendet werden (i, m, s/dotAll, u, v wenn verfügbar) - Fügen Sie mindestens ein astral-plane-Fixture hinzu, wenn Benutzertext Emoji enthalten kann - Vermeiden Sie die Annahme, dass \w „Buchstaben in jeder Sprache“ bedeutet - Verwenden Sie explizite Bereiche oder Eigenschafts-Escapes, die Sie im Engine verifiziert haben

Rekursion, Backreferences und „hilfreiche“ PCRE-Features

Rekursive Muster und einige Subroutine-Aufrufe sind PCRE-Stärken. ECMAScript-RegExp bietet Ihnen nicht das gleiche Toolkit. Generatoren, die balancierte-Trennzeichen-Muster mit Rekursion emittieren, schlagen fehl, wenn der Verbraucher JavaScript ist. Atomare Gruppen und possessive Quantoren sind ein weiteres PCRE-seitiges Komfort, das JavaScript in der gleichen Form nicht bietet.

Das Verhalten von Backreferences bei fehlgeschlagenen Gruppen und leeren Übereinstimmungen kann auch Menschen überraschen, die Muster zwischen Engines verschieben. Der Fehlermodus ist selten ein Absturz; es ist eine stille falsche Akzeptanz oder Ablehnung bei Randeingaben.

Schritt-für-Schritt-Arbeitsablauf, den ich vor dem Versand eines Musters verwende

- Schreiben Sie zunächst die Akzeptanzbeispiele und Ablehnungsbeispiele (fünf sind genug, um zu beginnen). - Pin den Motor und die Flaggen im Ticket-Titel (Beispiel: „ECMAScript, Flaggen u + i“). - Generieren oder erstellen Sie das Muster nur für diesen Motor. - Führen Sie die Fixtures in der gleichen Laufzeit aus, die der Benutzer trifft (Browser-Build oder Node-Version, die Sie bereitstellen). - Scannen Sie nach verschachtelten Quantifizierern und überlappenden Alternationen (ReDoS-Prüfung). - Fügen Sie das Muster nur dann in einen zweiten Motor ein, wenn Sie tatsächlich eine duale Laufzeit benötigen — erwarten Sie Bearbeitungen.

RegexProof ist so konzipiert, dass die Wahl der Geschmacksrichtung explizit bleibt und Gruppen vor dem Einfügen erklärt werden. Es ersetzt nicht das Ausführen von Fixtures in Ihrem Staging-Binärcode.

Häufige Fehler

- Ein grüner Test auf regex101 mit der falschen Geschmacksrichtung vertrauen - Ein Muster über WAF (PCRE) und Frontend (ECMAScript) teilen, ohne duale Fixtures zu verwenden - Ermöglichen Sie es einem LLM, Lookbehind oder Rekursion ohne Angabe des Motors zu emittieren - „Es wurde kompiliert“ als „es entspricht dem, was wir meinen“ behandeln - ReDoS-Überprüfung überspringen, weil das Muster „nur für Validierung“ ist.

Entscheidungskriterien: Ein Motor oder zwei

Bleiben Sie bei einem Motor, wenn das Muster Benutzereingaben in einer einzigen Ebene steuert. Teilen Sie die Motoren nur dann, wenn Sie zwei Besitzer, zwei Fixture-Dateien und eine dokumentierte Zuordnung haben. Der Dual-Motor teilt sich dieselbe Zeichenfolge, wie Dialektfallen zu Vorfällen werden.

Wofür dies nicht ist

Dieser Artikel ist kein umfassender Vergleich aller Regex-Flavors, keine Garantie, dass RegexProof (oder ein anderes Tool) jeden Dialektfehler erkennt, und kein Anspruch, dass das Bestehen von Fixtures bedeutet, dass das Muster unter adversarialer Last sicher ist. Wir erfinden keine Kundenmetriken. Verwenden Sie es als Operator-Checkliste; halten Sie die ECMA-262- und PCRE-Dokumente offen, wenn Sie über Randfälle diskutieren.

Wie ich ein Ticket einem Engine-Vertrag zuordne

Jedes Regex-Ticket sollte den Runtime wie eine Datenbank benennen: „Node 20 ECMAScript RegExp, Flags u+i“ oder „Gateway PCRE2 UTF, keine Rekursion.“ Ohne diese Zeile streiten Reviewer über Geschmack anstelle von Verträgen. Ich füge die Engine-Zeile in die PR-Beschreibung und in die Fixture-Datei-Hauptzeile ein, damit CI und Menschen eine gemeinsame Geschichte teilen.

Wenn das Produkt nach „derselben Regel im Browser und am Rand“ fragt, teile ich die Arbeit in zwei Muster mit zwei Fixture-Dateien auf. Geteilte Absicht ist in Ordnung; unverifizierte gemeinsame Zeichenfolgen sind es nicht. Die Kosten für die Wartung von zwei kleinen Mustern sind geringer als die Kosten für ein Dialekt-Incident auf einem Login- oder Checkout-Feld.

Vorlage für die PR-Beschreibung

- Engine + Version + Flags - Fünf Akzept-Fixturen und fünf Ablehn-Fixturen (rohe Zeichenfolgen, keine Paraphrasen) - Maximale Eingabelänge vor dem Matcher - ReDoS-Hinweis: verschachtelte Quantoren überprüft ja/nein - Besitzer für Restrisiko, wenn das Muster komplex bleiben muss

LLM-generiertes Regex: Pinne die Flavor in der Prompt

Wenn Sie ein Modell nach „einem Regex für E-Mails“ fragen, ohne ECMAScript oder PCRE zu benennen, erhalten Sie oft eine PCRE-Flavor-Antwort mit Lookbehind oder possessiven Gewohnheiten. RegexProof erzwingt eine Flavor-Wahl aus diesem Grund. Führen Sie die Fixture dennoch in Ihrem Binär aus; eine saubere Erklärung ist nicht gleichbedeutend mit einem grünen CI-Job.

Ich verbiete auch das Übernehmen von Chat-Protokollen in die Produktion ohne eine zweite Person, die jede Gruppe erklären kann. Der Fehlermodus ist nicht dramatischer Syntaxfehler — es ist leise falsche Akzeptanz auf Unicode-Edge-Cases Wochen später.

Hinweise der Betreiber zu Versand von Mikro-SaaS-Formularen

Öffentliche Formulare ziehen seltsame Unicode-Zeichen, Nullbreitenzeichen und Kopierjobs von Office-Suiten an. Dialektfallen treten als „funktioniert auf meinem Laptop“ auf, weil der Laptop-Tester einen anderen Motor als den Edge-Node verwendet hat. Halten Sie einen Staging-Host bereit, der die Produktions-Regex-Flags genau spiegelt.

Wenn ein Kunde einen falschen Ablehnung meldet, fragen Sie nach den genauen Codepunkten (einem Hex-Dump der Zeichenfolge), bevor Sie das Muster „beheben“. Viele Dialektfehler sind in Screenshots unsichtbar.

Schluss

Fixieren Sie den Dialekt, schreiben Sie Fixtures in diesem Dialekt und kümmern Sie sich dann um Eleganz. Der teure Fehler ist das Muster, das im falschen Tester funktioniert. Halten Sie den Produktionsmotor ehrlich und behandeln Sie die Übertragung zwischen Motoren als eine Portierungsaufgabe mit eigener Überprüfung.

Quellen

- ECMA-262 RegExp - PCRE - OWASP ReDoS

Probieren Sie das Produkt: RegexProof

2026-09-16 · nur primäre Quellen · keine gefälschten Traffic-Metriken