De regex die mij de meeste tijd kostte was er een die ik niet schreef Het was vier jaar oud, zat in een validatielaag, en zag eruit alsof er een kat over het toetsenbord had gelopen: geneste groepen, een lookahead, twee karakterklassen, en een {2,} verstopt aan het einde Een support ticket zei dat het was het afwijzen van geldige input, en voordat ik het kon repareren moest ik het begrijpen, wat betekende dat mentaal draaien van de motor over het patroon een token per keer Dat is de belasting die elke ontwikkelaar betaalt op een onbekende regex, en het is precies de belasting de Regex-uitlegger op Toolz.dev is gebouwd om te verwijderen Deze gids gaat over het lezen van reguliere expressies in plaats van ze te decoderen, en hoe een uitsplitsing per token een muur van symbolen verandert in iets dat je kunt beoordelen zoals gewone code.
tl;dr: Een regex-uitlegger parseert een reguliere expressie en beschrijft elk onderdeel in gewoon Engels, in de volgorde waarin de engine het leest: ankers, karakterklassen, kwantoren, groepen, lookarounds en ontsnappingen, allemaal gelabeld en ingesprongen, zodat de geneste structuur zichtbaar is Regex-uitlegger valideert het patroon met de echte JavaScript-engine en voert de hele uitsplitsing uit in uw browser, zonder dat er iets is geüpload.
Wat is een regex-uitlegger?
Een regex-uitlegger neemt een reguliere expressie en vertaalt deze, construct voor construct, naar een beschrijving die je kunt lezen. In plaats van ernaar te staren ^(?<user>[a-z0-9._%+-]+)@ en als je de betekenis ervan in je hoofd reconstrueert, krijg je een geordende lijst: dit is een begin-van-tekenreeks-anker, dit is een benoemde vastleggroep genaamd gebruiker, dit is een tekenklasse die overeenkomt met een kleine letter, een cijfer, een punt, een procentteken, een plus of een koppelteken, en deze kwantificator betekent een of meer keren. Het patroon is niet veranderd, maar de moeite om het te begrijpen is van je hoofd naar het gereedschap verplaatst.
De waarde komt voort uit het feit dat reguliere expressies opzettelijk compact zijn Elk symbool draagt betekenis, en dezelfde intentie kan op veel verschillende manieren worden geschreven, dus er is geen betrouwbare manier om een patroon te skimmen zoals je een functie skimt Een enkele verdwaalde backslash verandert een letterlijke stip in & quot; elk teken, & quot; en een hebzuchtige kwantificator waarbij je een luie wilt, verandert welke tekst een groep vastlegt, een regex correct lezen betekent de engine simuleren, en de engine met de hand simuleren is traag en foutgevoelig De uitlegger doet die simulatie en laat je het resultaat zien.
Op Toolz.dev is de stroom kort Je plakt het patroon zonder de omliggende schuine strepen, schakelt de vlaggen die het gebruikt om en de uitsplitsing verschijnt onmiddellijk Geneste groepen zijn ingesprongen zodat de vorm van het patroon in één oogopslag zichtbaar is, en elke vlag wordt in context beschreven, zodat je begrijpt hoe het de hele overeenkomst verandert in plaats van alleen de syntaxis.
Hoe verschilt een explainer van een regextester?
Deze twee tools beantwoorden verschillende vragen, en weten welke je nodig hebt bespaart tijd Een regex tester voert een patroon uit tegen voorbeeldtekst en laat zien wat het overeenkomt: de gemarkeerde overeenkomsten, de capture groepen, en elke fout Het antwoordt & quot; doet dit patroon wat ik wil op deze input." Een uitlegger beschrijft wat het patroon betekent zonder enige testinvoer helemaal geen Antwoorden & quot; wat zegt dit patroon eigenlijk."
Je grijpt naar de uitlegger wanneer de regex het onbekende is, niet de gegevens Een pull-verzoek dat een validatiepatroon toevoegt, een codebase vol ongedocumenteerde expressies erft, of een antwoord probeert te begrijpen dat je van een forum hebt gekopieerd, zijn allemaal gevallen waarin je het patroon hebt en moet weten wat het doet voordat je het vertrouwt. Je reikt naar de regex-tester wanneer je het patroon al begrijpt en het gedrag ervan wilt bevestigen aan de hand van echte voorbeelden In de praktijk werken de twee als een paar: leg een patroon uit om het te begrijpen, test het vervolgens om het te bewijzen. De tester en de uitlegger zitten om precies die reden naast elkaar op Toolz.dev.
Er is een derde hulpmiddel in de familie dat de moeite waard is om te benoemen De Regex-bouwer stelt een patroon samen uit componenten en sjablonen wanneer je helemaal opnieuw begint Bouw, leg uit, test: die drie bestrijken de volledige levenscyclus van het werken met een reguliere expressie, van het schrijven van een hoef je er nog geen te begrijpen die je niet hebt geschreven.
Wat blijkt uit de uitsplitsing eigenlijk?
De uitlegger loopt het patroon van links naar rechts en zendt één gelabelde regel per construct uit, in de volgorde waarin de engine ze tegenkomt. Die volgorde is belangrijk, omdat een reguliere expressie opeenvolgend wordt gelezen, en het achtereenvolgens zien van de tokens weerspiegelt hoe de matching feitelijk verloopt.
Ankers komen in de meeste patronen op de eerste plaats De ^ en $ symbolen komen niet overeen met tekens; ze beweren een positie, het begin en einde van de string, of het begin en einde van elke regel wanneer de vlag met meerdere regels is ingesteld. De uitlegger merkt dit dubbele gedrag op, dus je wordt nooit verrast door een anker dat zich anders gedraagt onder de m flag.
Karakterklassen, geschreven tussen vierkante haken, beschrijven een enkel teken dat uit een set is getrokken De uitlegger breidt de set uit tot woorden: bereiken als a-z word " het bereik a tot z, & quot; steno ontsnapt als \d word " een cijfer, & quot; en een leidende caret wordt & quot; elk teken dat NOT" de vermelde set is. Een dichte klasse zoals [a-zA-Z0-9._%+-] leest als een gewone lijst in plaats van een puzzel.
Kwantificatoren zijn waar subtiele bugs leven, dus krijgen ze hun eigen lijnen A * is nul of meer, + is een of meer, ? is nul of één, en {n,m} is een expliciet bereik Cruciaal is dat de uitlegger luie kwantoren markeert, degene die met een achterwerk zijn geschreven ? zoals zoals +? of *?, omdat het verschil tussen hebzuchtig en lui verandert welke tekst een patroon vastlegt zonder ook maar één zichtbaar teken elders te veranderen.
Groepen en lookarounds zijn ingesprongen om nesting te laten zien. Het vangen van groepen, niet-vangende groepen, genoemde groepen en alle vier de lookaround-typen krijgen elk een beschrijving van wat ze doen, en het kinderpatroon daarin is één niveau ingesprongen, zodat de structuur leest als een geneste omtrek in plaats van als een vlakke reeks symbolen.
Hier ziet u hoe de gemeenschappelijke constructies in kaart brengen wat de uitlegger u vertelt:
| Construct | toonbeeld | Wat de uitlegger zegt |
|---|---|---|
| Anker | ^ |
Start-of-string (of begin van een regel met de m-vlag) |
| Karakterklasse | [a-z] |
Een enkel teken uit het bereik a tot z |
| Shorthand | \d |
Een cijfer, 0 tot en met 9 |
| Kwantificator | {2,} |
2 of meer keer herhaald |
| Luie kwantificator | +? |
Een of meerdere keren herhaald, zo min mogelijk |
| groep vastleggen | (...) |
Start van een vastleggroep, opgeslagen voor hergebruik |
| Genoemde groep | (?<id>...) |
Start van een benoemde capturing group "id" |
| Kijk vooruit | (?=...) |
Het ingesloten patroon moet volgen, maar wordt niet geconsumeerd |
| Achtergrondreferentie | \1 |
Komt overeen met dezelfde tekstgroep 1 vastgelegd |
De beschrijvingen volgen de terminologie die wordt gebruikt in de MDN reguliere expressies referentie, dus als je verder wilt lezen over een enkele constructie, zijn de woorden in de uitsplitsing de woorden waarnaar je moet zoeken.
Waarom doet de smaak ertoe?
Reguliere expressies zijn niet één taal; ze zijn een familie van nauw verwante. JavaScript, PCRE (gebruikt door PHP en vele tools), Python's re module, Java en .NET delen allemaal de kernsyntaxis, maar ze divergeren aan de randen, en die randen zijn waar verwarring broedt De Regex Explainer beschrijft JavaScript reguliere expressies, de smaak die wordt gebruikt door browsers en Node.js, omdat dat is waar de tool mee valideert en waar de meeste webontwikkelaars daadwerkelijk op draaien.
De gedeelde kern is groot en betrouwbaar Karakterklassen, de gemeenschappelijke kwantoren, afwisseling met |, groepering, ankers en de standaard steno's zoals \d en \w bedoel overal hetzelfde Als je patroon alleen die gebruikt, is de uitleg accuraat ongeacht de taal waarin je het uiteindelijk gaat uitvoeren De verschillen zitten in de geavanceerde functies: kijk achter ondersteuning kwam laat in JavaScript en verschilt van PCRE, syntaxis met benoemde groepen varieert tussen smaken, en sommige motoren ondersteunen recursie of bezittelijke kwantoren die JavaScript helemaal niet heeft.
De praktische regel is simpel Behandel de uitleg van de gedeelde constructies als gezaghebbend, en controleer elke smaakspecifieke extensie nogmaals aan de hand van de documentatie voor je doeltaal Omdat de uitlegger het patroon eerst valideert met de echte JavaScript-engine, zal een constructie die JavaScript niet ondersteunt eerder als een fout dan als een verkeerde verklaring naar boven komen, wat de veiligere fout is. Als je over de stapel werkt zoals ik, beweeg je tussen een PHP-backend en een JavaScript-frontend, bespaart expliciet zijn over smaak de klasse van bugs waarbij een patroon dat op de ene plaats werkte zich op een andere plek stilletjes misdraagt.
Hoe lees ik er een echt patroon mee?
Neem het monster dat de tool standaard laadt, een e-mailvormig patroon: ^(?<user>[a-z0-9._%+-]+)@(?<domain>[a-z0-9.-]+\.[a-z]{2,})$ met de hoofdletterongevoelige vlag Op zichzelf is het een mondvol.Loop het door de uitleg en het valt uiteen in een korte, leesbare omtrek.
de ^ beweert het begin van de string De eerstgenoemde groep, gebruiker, legt een of meer tekens vast uit een klasse kleine letters, cijfers en de interpunctie die gewoonlijk is toegestaan in het lokale deel van een adres. Dan een letterlijke @. De tweede benoemde groep, domein, legt een of meer letters, cijfers, stippen of koppeltekens vast, gevolgd door een letterlijke stip en een reeks van twee of meer letters, wat het domein op het hoogste niveau is. Tenslotte $ beweert het einde van de string De i vlag betekent dat het geheel ongeacht het geval overeenkomt, dus de klassen met alleen kleine letters accepteren nog steeds invoer in hoofdletters.
Lees die kant op, er springen twee dingen uit die onzichtbaar zijn in het rauwe patroon Ten eerste, de {2,} op het topniveau-domein betekent het patroon accepteert elke TLD van twee of meer letters, wat correct is voor moderne domeinen, maar een geïnternationaliseerde TLD geschreven in niet-Latijnse karakters zou verwerpen. Ten tweede betekenen de ankers dat het patroon moet overeenkomen met de hele string, dus het valideert een heel adres in plaats van er een in een grotere tekst te vinden. Dat zijn precies het soort details dat bepaalt of een validatie-regex te strikt of te los is, en ze zijn duidelijk zichtbaar in de uitsplitsing, terwijl ze gemakkelijk te missen zijn in het origineel.
Als je een patroon eenmaal begrijpt, wil je er vaak iets mee doen Als het een vind-en-vervang patroon is, dan is de Regex Vervang tool voert de vervanging uit met backreference-ondersteuning Als het een extractiepatroon is, is de E-mail Extractor past een samengestelde versie van precies dit soort e-mail toe die overeenkomt met bulktekst De uitlegger is de leesstap; dit zijn de acteerstappen.
Wanneer zou ik dit eigenlijk gebruiken?
Code review is het geval dat ik het meest raak Een teamgenoot voegt een reguliere expressie toe aan een validatielaag of een logparser, en het diff toont een rij symbolen zonder commentaar Het plakken ervan in de uitleg verandert een blik van vijf minuten in een leesbeurt van tien seconden, en het vangt de klassieke recensie-missers op: een onontsnapte stip die bij elk teken past, een hebzuchtige kwantificator die te veel vangt, een anker dat aanwezig of afwezig is terwijl het andersom zou moeten zijn Ik ben begonnen met het plakken van de uitsplitsing in het trekverzoek als commentaar, dat het patroon voor de volgende persoon gratis documenteert.
Leren is de volgende Reguliere expressies zijn een van die vaardigheden die nooit volledig blijven hangen tenzij je ze dagelijks gebruikt, en er na een paar maanden op terugkomen betekent altijd dat je de syntaxis opnieuw leert Het lezen van echte patronen met de uitlegger is een snellere weg terug dan het herlezen van een tutorial, omdat je de constructies in context ziet, echt werk doet, in plaats van als geïsoleerde voorbeelden Na verloop van tijd worden de beschrijvingen overbodig omdat je ze hebt geïnternaliseerd, wat het punt is.
Debuggen sluit de lus Wanneer een patroon overeenkomt met het verkeerde, onthult de uitleg vaak waarom voordat je zelfs maar naar testinvoer grijpt Een kwantificator die hebzuchtig is terwijl het lui zou moeten zijn, een karakterklasse die een personage bevat dat je bent vergeten, een ontbrekend anker waarmee het patroon overeenkomt met een substring: deze zijn allemaal zichtbaar in de uitsplitsing Ik houd de uitleg naast de regex-tester dus ik kan het uitleggen en testen in dezelfde vergadering, en beiden leven in de bredere kit die ik in de Handleiding voor webontwikkelaars.
Is het privé en werkt het offline?
Ja tegen beide, en om dezelfde reden De volledige uitsplitsing wordt berekend in JavaScript binnenin uw browser Het patroon wordt nooit naar een server verzonden, er wordt niets meer gelogd, en zodra de pagina is geladen blijft de tool werken met uw verbinding uitgeschakeld U kunt dit bevestigen door het netwerk tabblad te openen of door offline te gaan en te kijken naar het blijven functioneren.
Dit is meer van belang dan het lijkt voor reguliere expressies specifiek Patronen worden vaak geschreven om gevoelige formaten te matchen: interne identifiers, API-sleutelvormen, lay-outs van accountnummers of de structuur van privégegevens Een daarvan in een tool aan de serverzijde plakken betekent een beschrijving van uw gegevensformaat aan een derde partij geven Door de analyseclientzijde te behouden blijft het patroon op uw machine staan, wat hetzelfde principe is dat op de eerste plaats staat van privacy achter elke tool op Toolz.dev, en een principe waar ik vollediger over schreef in de Gids voor gegevensprivacy.
FAQ
Hoe begrijp ik een complexe reguliere expressie?
Plak het patroon in de uitleg en lees de uitsplitsing per token, die elke constructie in gewoon Engels beschrijft in de volgorde waarin de engine deze toepast. Geneste groepen zijn ingesprongen zodat je de structuur kunt zien. Dit verandert mentaal simuleren van de engine in het eenvoudig lezen van een gelabelde lijst, wat sneller en veel minder foutgevoelig is.
Wat is het verschil tussen een regex-uitlegger en een regex-tester?
Een regex-uitlegger beschrijft wat een patroon betekent zonder enige testinvoer, terwijl een regex-tester het patroon tegen voorbeeldtekst uitvoert en laat zien wat het overeenkomt Gebruik de uitleg om een onbekend patroon te begrijpen of te documenteren, gebruik vervolgens de tester om te bevestigen dat het zich gedraagt zoals verwacht tegen echte gegevens Ze beantwoorden verschillende vragen en werken goed als een paar.
Welke regex-smaak beschrijft de uitlegger?
Het beschrijft JavaScript (ECMAScript) reguliere expressies, de smaak die wordt gebruikt door browsers en Node.js. De meeste syntaxis, inclusief tekenklassen, kwantoren, groepen en ankers, wordt gedeeld met PCRE, Python en Java, dus de kernuitleg is nauwkeurig in alle talen Smaakspecifieke functies zoals lookbehind en syntaxis met benoemde groepen kunnen verschillen, dus verifieer deze in uw doeltaal.
Wat is het verschil tussen een hebzuchtige en een luie quantifier?
Een hebzuchtige kwantor zoals + of * komt zoveel mogelijk overeen met tekst voordat hij teruggaat, terwijl een luie kwantor, hetzelfde symbool gevolgd door ? zoals +? of *?, komt zo min mogelijk overeen. De uitlegger labelt luie kwantoren expliciet, omdat het verschil verandert welke tekst een patroon vastlegt zonder elders enig zichtbaar teken te veranderen.
Kan de uitlegger blik en blik achter?
Ja. Positief en negatief vooruitkijkend, geschreven (?=...) en (?!...), en positief en negatief kijkachter, geschreven (?<=...) en (?<!...), zijn elk gelabeld met wat ze beweren en zijn ingesprongen zoals andere groepen. Omstreken controleren of tekst wel of niet op een positie verschijnt zonder deze in de wedstrijd op te nemen, wat de beschrijvingen expliciet maken.
Waarom zegt de uitlegger dat mijn patroon ongeldig is?
Het patroon wordt gecompileerd met de echte RegExp-engine voordat het wordt uitgelegd, dus een onevenwichtige haak of haakje, een ongeldige ontsnapping of een onbekende vlag wordt gerapporteerd met de engine's exacte foutmelding Het gemelde probleem oplossen, meestal een ontbrekend sluithaakje of haakje, en de uitsplitsing verschijnt.
Is het veilig om een regex te plakken die overeenkomt met privégegevens?
Ja. Het patroon wordt volledig geanalyseerd in JavaScript in uw browser. Het wordt nooit naar een server verzonden, nooit gelogd, en de tool werkt met uitgeschakelde verbinding zodra de pagina is geladen. U kunt veilig patronen uitleggen vanaf privécodebases of codebases die overeenkomen met persoonlijke of eigen formaten.
Hoe is dit anders dan een regex builder?
Een regex builder helpt je een nieuw patroon te construeren op basis van componenten en sjablonen wanneer je helemaal opnieuw begint, terwijl de uitleg een patroon beschrijft dat je al hebt. De twee zijn complementair: bouw een patroon op met de Regex Builder, begrijp een bestaand patroon met de uitleg en bevestig dit tegen echte invoer met de Regex Tester.
Lees je eigen patronen met de gratis Regex-uitlegger. Het breekt een reguliere expressie op token af in gewoon Engels, volledig in uw browser, zonder dat er iets is geüpload.
