Sådan Tester Du Et Regulært Udtryk Online (Med Rigtige Eksempler)
For at teste et regulært udtryk skriver du mønsteret mellem to skråstreger, slår de flag til, du har brug for, og kører det mod en rigtig teststreng med både gyldige og ugyldige eksempler. Tjek derefter to ting, før mønsteret får lov at rejse ind i din kode: at de rigtige stykker tekst bliver markeret som match, og at eventuelle fangede grupper indeholder præcis det, du regnede med.
Mønster, flag og fangstgrupper
Et regex-mønster skrives mellem / /, ligesom /^\d{4}-\d{2}-\d{2}$/. Alt mellem skråstregerne er selve søgemønsteret; det, der kommer efter den sidste skråstreg, er flagene.
Fire flag dækker langt de fleste behov:
- g (global): find hvert match i teksten i stedet for kun det første. Uden g stopper motoren, så snart den har fundet én træffer.
- i (case-insensitive): ignorer forskellen på store og små bogstaver, så
Regexogregexbegge matcher. - m (multiline): lad
^og$matche starten og slutningen af hver linje i en tekst med flere linjer, i stedet for kun starten og slutningen af hele strengen. - s (dotAll): lad punktummet
.også matche linjeskift, hvilket det normalt ikke gør.
Parenteser () opretter en fangstgruppe: den del af matchet, der ligger inde i parenteserne, gemmes for sig selv, så du kan hente den ud bagefter, uden at skulle parse hele træfferstrengen manuelt igen. Navngivne grupper som (?<year>\d{4}) gør det samme, men giver gruppen et navn i stedet for kun et nummer, hvilket gør koden, der læser resultatet, lettere at forstå senere.
Fire mønstre, gennemgået i praksis
De fire mønstre herunder dækker de opgaver, du reelt støder på i daglig kode: validere et input-format, plukke en værdi ud af en større tekst, eller begge dele på én gang. Læg mærke til, hvordan hvert mønster bruger ankre, tegnklasser og fangstgrupper forskelligt, alt efter om formålet er at godkende hele strengen eller kun at finde bidder af den.
| Mønster | Flag | Matcher | Matcher ikke | Fanger |
|---|---|---|---|---|
^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$ | ingen | [email protected] | jane@example (mangler topdomæne) | ingen |
#([0-9a-fA-F]{6}|[0-9a-fA-F]{3}) | g | #2F7BFF, #fff | #12G456 (G er ikke hex) | Gruppe 1: 2F7BFF |
\/(\w+)\/(\w[\w-]*) | g | /users/123, /products/abc-456 | /users (mangler andet segment) | Gruppe 1: ressourcetype, Gruppe 2: id |
^\d{4}-\d{2}-\d{2}$ | ingen | 2026-07-11 | 07/11/2026 (forkert format) | ingen |
Tag rute-mønsteret først: \/(\w+)\/(\w[\w-]*). Det starter med \/, en escaped skråstreg, fordi en uescaped / ellers ville blive læst som mønsterets afgrænser. Derefter kommer (\w+), en fangstgruppe, der samler en eller flere ord-tegn (bogstaver, tal, underscore) sammen, det bliver ressourcetypen: users, products, hvad du nu har af segmenter i din routing. Så følger endnu en \/, og til sidst (\w[\w-]*), en anden gruppe, der kræver mindst ét ord-tegn efterfulgt af vilkårligt mange ord-tegn eller bindestreger, det er id-delen, og det er derfor den godtager både 123 og abc-456. Sæt g-flaget til, og kør mønsteret mod en liste af API-stier, og du får en fuld rute-validator uden at skrive en eneste linje parsing-kode: hvert match giver dig Gruppe 1 (ressourcetype) og Gruppe 2 (id) klar til brug, og enhver linje, der ikke matcher, springer stille over, hvilket i sig selv fortæller dig, at den sti er ugyldig.
Hex-farve-mønsteret, #([0-9a-fA-F]{6}|[0-9a-fA-F]{3}), viser noget andet: hvorfor g-flaget rent faktisk ændrer resultatet, ikke bare hvor mange gange det kører. Mønsteret starter med et bogstaveligt #, derefter en gruppe med to alternativer adskilt af |: enten præcis seks hex-cifre ([0-9a-fA-F]{6}) eller præcis tre ([0-9a-fA-F]{3}). Uden g-flaget stopper regex-motoren efter det allerførste #-match, den støder på, i en hel CSS-fil med snesevis af farvekoder får du kun én. Med g slået til fortsætter den efter hvert match og finder samtlige forekomster, #2F7BFF, #fff, #0B1220, hver eneste én, med Gruppe 1 for hver af dem indeholdende netop hex-cifrene uden #-tegnet foran. Det er nøjagtig den arbejdsgang, du vil bruge til at trække alle brand-farver ud af et stylesheet i én kørsel, i stedet for at skrive en løkke, der kalder regex-motoren igen og igen.
Prøv selv
Skriv dit eget mønster og din egen teststreng herunder, og se matchene blive markeret live.
Almindelige fejl og specialtilfælde
At glemme g-flaget. Uden det stopper regex’en efter det første match, hvilket i stilhed ødelægger alt, der forventer alle forekomster, som en “erstat alle”-funktion, der kun rammer den første forekomst og lader resten af teksten stå urørt.
Det uescapede punktum. Et uescapet . matcher ethvert tegn, ikke et bogstaveligt punktum. 192.168.1.1 som mønster matcher derfor også 192X168X1X1, fordi hvert punktum bare betyder “et vilkårligt tegn her”. Brug \. for et bogstaveligt punktum, hver eneste gang du reelt mener et punktum og ikke en jokertegn-plads.
Grådige versus dovne kvantorer. .* tager så meget som muligt, det kaldes grådigt, hvilket kan strække sig langt ud over det tiltænkte sted. Prøv at matche et HTML-tag med <.*>, og den grådige version matcher fra det allerførste < til det allersidste > i hele blokken, i stedet for ét enkelt tag. .*? (dovent) stopper ved det tidligst mulige punkt i stedet, og giver dig kun det ene tag, du ledte efter. Forskellen mærkes først for alvor, når teststrengen indeholder mere end ét tag, for på en enkelt kort linje ser de to varianter ofte ens ud.
Manglende ankre. Uden ^ og $ kan et mønster matche som delstreng hvor som helst i teksten. Et “validerings”-mønster uden ankre kan derfor godkende en streng, der blot indeholder en gyldig del et sted i midten, og lade ugyldigt input omkring den slippe igennem uopdaget. ^ og $ tvinger hele strengen til at matche fra start til slut, ikke bare et udsnit af den. Det er præcis derfor e-mail- og dato-mønstrene i tabellen ovenfor begge er ankret i begge ender: de skal godkende hele feltet, ikke bare finde en gyldig bid inden i det.
Ofte stillede spørgsmål
Hvad er den reelle forskel mellem at bruge g-flaget og at udelade det? Uden g returnerer regex-motoren kun det første match, den finder, og stopper der, selv hvis teksten indeholder flere forekomster af mønsteret. Med g fortsætter den gennem hele strengen og samler samtlige matches op. Forskellen bliver tydelig, så snart du arbejder med en tekst, der reelt indeholder mere end én træffer, som en liste af e-mailadresser eller en fil fuld af farvekoder.
Hvordan matcher jeg et bogstaveligt specialtegn som et punktum, dollartegn eller parentes?
Sæt en backslash foran det: \. for et punktum, \$ for et dollartegn, \( og \) for parenteser. Uden backslashen bliver tegnet tolket som en del af regex-syntaksen (punktum betyder “et vilkårligt tegn”, dollartegn betyder “slutningen af strengen”, parenteser opretter en gruppe), i stedet for det bogstavelige tegn, du faktisk ville matche.
Hvad er en ikke-fangende gruppe, (?:...), og hvornår har jeg brug for én i stedet for en almindelig (...)-gruppe?
En ikke-fangende gruppe grupperer en del af mønsteret, så du eksempelvis kan anvende en kvantor eller et alternativ (|) på hele delen, uden at gruppen samtidig gemmes som en nummereret fangst i resultatet. Det er nyttigt, når mønsteret har brug for grupperingens struktur, men koden bagefter kun skal bruge de rigtige fangstgrupper, du selv definerer med (...): uden ikke-fangende grupper skubber hver ekstra (...) gruppenumrene op ad, og et mønster med flere strukturelle grupper end fangstgrupper bliver hurtigt forvirrende at læse resultater fra. Tommelfingerreglen er enkel: brug (?:...) hver gang du grupperer af syntaktiske årsager, og gem de nummererede parenteser til de værdier, du faktisk vil hente ud bagefter.
Sender dette værktøj mit mønster eller min testtekst nogen steder hen? Nej. Alt kører i browseren via den indbyggede JavaScript RegExp-motor, og der bliver ikke sendt noget til en server, hverken mønsteret, teststrengen eller resultaterne.