ECMAScript vs PCRE dialect valstrikken

Waarom dialectvalstrikken in echte apps verschijnen

De meeste teams leren één smaak goed kennen en plakken patronen over stacks. Een backend dat PCRE-stijlfuncties gebruikt (recursieve subpatronen, bepaalde lookbehind-vormen, possessieve quantifiers) accepteert een patroon dat de browser niet eens kan parseren. Het omgekeerde gebeurt ook: een JavaScript u-flag Unicode-patroon gedraagt zich anders wanneer iemand het naar een byte-georiënteerde PCRE-build port zonder dezelfde Unicode-eigenschappen.

Ik behandel dialect als onderdeel van het contract, op dezelfde manier als ik SQL-dialect behandel. Als de runtime ECMAScript RegExp is, is de bron van waarheid het ECMA-262 RegExp-gedeelte. Als de runtime PCRE is, is de bron van waarheid de PCRE-documentatie. Testers die stilzwijgend engines wisselen, verbergen de bug totdat deze in productie komt.

Waar de mismatch meestal binnenkomt

- Gedeelde "validatiebibliotheek"-snippets gekopieerd van Stack Overflow zonder engine-tag - CI die Python re uitvoert terwijl de edge-gateway JavaScript uitvoert - WAF of logparsers die PCRE gebruiken terwijl het app-formulier ECMAScript gebruikt - LLM-gegenereerde regex die standaard PCRE-achtige syntaxis gebruikt, tenzij je de smaak vastzet. Het is belangrijk om de juiste engine te gebruiken en te testen om dit soort problemen te voorkomen. Ook moet je op letten dat je geen RegexProof of -problemen introduceert.

Verschillen in lookbehind en lookaround

Variabele-lengte lookbehind is een klassieke valkuil. Motoren zijn het oneens over welke lengtes legaal zijn, en sommige oudere JavaScript-motoren hadden helemaal geen lookbehind. Zelfs als beide partijen lookbehind ondersteunen, kan de set van toegestane patronen binnen de bewering verschillen. Als uw poort afhankelijk is van 'het vorige token moet X zijn', schrijf dan een eenheidstest in de productiemotor, niet in een PCRE-speeltuin.

Lookahead is meer algemeen geaccepteerd, maar het combineren van lookaround met geneste kwantoren verhoogt het ReDoS-risico. Dialectveiligheid en denial-of-serviceveiligheid zijn separate controles; slaag voor de ene en u kunt nog steeds falen voor de andere. De ReDoS-notities van OWASP blijven de praktische checklist voor de tweede controle (OWASP ReDoS).

Praktische regel

Als een functie niet in ECMA-262 RegExp zit, lever deze dan niet aan de browser. Als u PCRE-only-functies nodig heeft, houd het patroon dan aan de PCRE-kant en retourneer een boolean of een genormaliseerd token naar JavaScript in plaats van het ruwe patroon te verzenden.

Unicode-modi en karakterklassen

Unicode-eigenschapontsnappingen, astrale vlaktekens en hoofdlettergevoeligheid zijn afhankelijk van vlaggen en engine-Unicode-tabellen. Een patroon geschreven met de JavaScript-u-vlag is niet hetzelfde object als een PCRE-patroon met UTF-modus ingeschakeld onder verschillende opties. Dot-all / single-line-gedrag verschilt ook in naamgeving en standaardinstellingen over smaakvarianten heen.

Wanneer ik gegenereerde patronen beoordeel, stel ik drie vragen: welke codepunten moeten overeenkomen, welke mogen niet en of het patroon ervan uitgaat dat de tekst alleen bestaat uit BMP (Basic Multilingual Plane)-tekens. E-mail, emoji en CJK-invoer zijn waar stilzwijgende mismatch verschijnt.

Controlelijst — Unicode

- Noteer de exacte vlaggen die in productie worden gebruikt (i, m, s/dotAll, u, v waar beschikbaar) - Neem ten minste één astrale-vlaktestuk op als gebruikerstekst emoji kan bevatten - Ga er niet van uit dat \w “letters in elke taal” betekent - Geef de voorkeur aan expliciete bereiken of eigenschapontsnappingen die u in de engine heeft geverifieerd

Recursie, backreferences en "hulprijke" PCRE-functies

Recursieve patronen en sommige subroutine-aanroepen zijn sterke punten van PCRE. ECMAScript RegExp biedt niet hetzelfde gereedschapskist. Generatoren die gebalanceerde-scheidingstekenpatronen met recursie emitteren, zullen falen wanneer de consument JavaScript is. Atomische groepen en possessieve kwantoren zijn een ander comfort aan de kant van PCRE dat JavaScript in dezelfde vorm ontbeert.

Het gedrag van backreferences rondom gefaalde groepen en lege overeenkomsten kan mensen die patronen tussen motoren verplaatsen ook verrassen. De foutmodus is zelden een crash; het is een stille verkeerde acceptatie of afwijzing bij randinvoer.

Functie | ECMAScript RegExp | PCRE (typisch) | Scheepsregel Variabele-lengte lookbehind | Beperkt / engine-versie-afhankelijk | Breder ondersteuning | Test in doelmotor Recursieve subpatronen | Niet beschikbaar | Beschikbaar | Houd server-side alleen Possessief / atomisch | Niet hetzelfde gereedschapskist | Beschikbaar | Plak niet in JS Unicode-eigenschap-escapes | Met u/v | Met UTF + opties | Match-vlaggen expliciet Genoemde groepen | Ondersteund in moderne motoren | Ondersteund | Verifieer nog steeds vervangsyntax

Stap-voor-stap workflow die ik gebruik voordat ik een patroon verzend

- Schrijf eerst de acceptatievoorbeelden en afwijzingsvoorbeelden (vijf van elk is genoeg om te beginnen). - Zet de engine en vlaggen vast in de titel van de ticket (bijvoorbeeld: "ECMAScript, vlaggen u + i"). - Genereer of maak het patroon voor die engine alleen. - Voer de fixtures uit in dezelfde runtime waar de gebruiker op klikt (browserbuild of Node-versie die u implementeert). - Scan op geneste quantoren en overlappende alternatie (ReDoS-pas). - Pas dan plak je het in een tweede engine als je echt een dubbele runtime nodig hebt - verwacht bewerkingen.

RegexProof is ontworpen om de keuze van de smaak expliciet te houden en groepen uit te leggen voordat je plakt. Het vervangt niet het uitvoeren van fixtures in uw staging-binaire bestand.

Gangbare fouten

Beslissingscriteria: één motor of twee

Blijf bij één motor wanneer het patroon gebruikersinvoer in één laag afhandelt. Splits motoren alleen wanneer je twee eigenaren, twee fixture-bestanden en een gedocumenteerde mapping hebt. Dual-engine "deelt hetzelfde teken" is hoe dialectvalstrikken incidenten worden.

Wat dit niet is

Dit artikel is geen volledige vergelijking van elke regex-smaken, geen garantie dat RegexProof (of enig ander hulpmiddel) elke dialectfout vindt, en geen bewering dat het doorstaan van tests betekent dat het patroon veilig is onder adversarial load. We verzinnen geen klantmetrieken.

Hoe kaart ik een ticket naar een engine-contract

Elk regex-ticket moet de runtime benoemen op de manier waarop we een database benoemen: "Node 20 ECMAScript RegExp, flags u+i" of "gateway PCRE2 UTF, geen recursie." Zonder die regel discussiëren reviewers over smaak in plaats van contracten. Ik plak de engine-regel in de PR-beschrijving en in de header van het fixture-bestand, zodat CI en mensen één verhaal delen.

Wanneer product vraagt om "dezelfde regel in de browser en op de edge", splits ik het werk in twee patronen met twee fixture-bestanden. Gedeelde intentie is prima; gedeelde ongeverifieerde strings zijn dat niet. De kosten van het onderhoud van twee kleine patronen zijn lager dan de kosten van één dialectincident op een inlog- of checkout-veld.

Sjabloon voor de PR-beschrijving

LLM-gegenereerde regex: bevestig de smaak in de prompt

Als je een model vraagt om 'een regex voor e-mails' zonder ECMAScript of PCRE te noemen, krijg je vaak een antwoord met de smaak van PCRE met lookbehind of possessive gewoontes. RegexProof dwingt een smaakeuze af om deze reden. Voer de fixtures nog steeds uit in uw binaire bestand; een heldere verklaring is geen groene CI-taak.

Ik verbied ook het kopiëren en plakken van chatlogs naar productie zonder een tweede mens die elke groep kan verklaren. De foutmodus is niet dramatische syntaxisfouten - het zijn stille verkeerde accepts op Unicode randgevallen weken later.

Notities van operators van verzending micro-SaaS formulieren

Openbare formulieren trekken vreemde Unicode, nulbrede tekens en plakklussen van kantoorsoftware aan. Dialectvalkuilen komen tot uiting als “werkt op mijn laptop” omdat de laptop-tester een andere motor gebruikte dan de edge-knooppunt. Houd één staging-host aan die productieregex-vlaggen exact weerspiegelt.

Wanneer een klant een vals afwijzen rapporteert, vraag dan naar de exacte codepunten (een hexadump van de string) voordat je het patroon “oplost”. Veel dialectbugs zijn onzichtbaar in schermafbeeldingen.

Afronding

Bevestig de dialect, schrijf fixtures in die dialect, en maak je dan zorgen over elegantie. De dure bug is het patroon dat werkt in de verkeerde tester. Houd de productiemotor eerlijk, en behandel cross-engine plakken als een portingtaak met zijn eigen review.

Referenties

- ECMA-262 RegExp - PCRE - OWASP ReDoS

Probeer het product: RegexProof

2026-09-16 · alleen primaire bronnen · geen gefabriceerde verkeersmetrieken

Gerelateerde artikelen

- redos-heuristics-for-application-regex-2026 - De LX AI Micro-SaaS Topic Matrix