Libreria di modelli Regex

Informazioni su questa libreria

È una collezione organizzata e ricercabile di più di 60 motivi di espressione regolare comunemente usati, ordinati per categoria. Ogni motivo include una descrizione, l'espressione stessa ed esempi di corrispondenze. Clicca su un motivo per copiarlo, o usa il pannello di test rapido per validare un testo contro di esso direttamente su questa pagina.

Tutto viene eseguito nel tuo browser · nessun motivo né testo di test viene inviato altrove. Usa questi motivi in JavaScript, Python, PHP, Java, Go o qualsiasi linguaggio che supporti le espressioni regolari. Per test più avanzati con flag e gruppi di cattura, prova il nostro Tester e debugger Regex.

Da dove vengono le espressioni regolari

L'idea matematica di «insieme regolare» è stata formalizzata da Stephen Cole Kleene nel 1951 nel memorandum di ricerca RAND Representation of Events in Nerve Nets and Finite Automata. L'operatore * su questa pagina si chiama ancora stella di Kleene in suo onore. Ken Thompson ha trasformato la teoria in algoritmo nel suo articolo del giugno 1968 in Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, e ha consegnato la prima implementazione regex nell'editor QED ai Bell Labs. Nel 1973 lo stesso motore alimentava ed, poi grep (l'espansione letterale è «globally search for regular expression and print»), sed e awk. Il Perl di Larry Wall (1987) e specialmente Perl 5 (1994) hanno aggiunto gruppi nominati, lookaround, quantificatori non avidi e gestione Unicode che sono diventati il dialetto de facto noto come PCRE, portato in C come libreria da Philip Hazel nel 1997.

Varianti di motore e cosa cambia tra di esse

Un pattern che gira pulito in JavaScript può fallire silenziosamente in Go e essere rifiutato del tutto in POSIX. Le cinque varianti che uno sviluppatore è più probabile incontrare:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): il dialetto di grep, sed e awk su un Unix di base. Nessun lookaround, nessun gruppo nominato, nessun escape di proprietà Unicode. BRE richiede inoltre l'escape di (, ), {, } e |.
• PCRE2 (Philip Hazel, 1997, versione principale attuale 10.x): il dialetto più ricco di funzionalità. Lookaround, gruppi nominati (?<name>...), gruppi atomici, quantificatori possessivi, ricorsione. Usato da PHP preg_*, Apache, nginx, R.
• Regex ECMAScript (ECMA-262, sezione regex 22.2): il dialetto JavaScript. ES2018 ha aggiunto gruppi nominati, lookbehind e i flag s (dotAll) e u (Unicode). ES2022 ha aggiunto il flag d per gli indici di corrispondenza. ES2024 ha aggiunto il flag v con classi in notazione di insieme.
• Python re: vicino a PCRE, ma usa (?P<name>...) per i gruppi nominati (PEP 433) e una diversa modalità verbose re.X. Il nuovo modulo di terze parti regex aggiunge pattern ricorsivi e semantica POSIX di corrispondenza più lunga.
• RE2 (Russ Cox, 2010): il motore dietro regexp di Go e la crate regex di Rust. Nessun lookaround, nessuna retroreferenza, nessun quantificatore possessivo, di proposito. Il compromesso: tempo lineare garantito, nessun backtracking catastrofico. Se un pattern di questa libreria usa (?=...) o \1, non si compilerà in Go.

Backtracking catastrofico e ReDoS

La maggior parte dei motori regex nei linguaggi principali (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) sono motori a backtracking. Quando un pattern con quantificatori annidati come (a+)+ incontra un input che quasi corrisponde, il motore può provare un numero esponenziale di percorsi alternativi prima di arrendersi. Questo è backtracking catastrofico, ed è la base della classe di attacco ReDoS (Regular expression Denial of Service) catalogata da OWASP.

Stack Overflow, 20 luglio 2016: un pattern progettato per ritagliare gli spazi bianchi all'inizio e alla fine, applicato a un corpo di domanda contenente 20 000 caratteri di spazio bianco consecutivi, ha richiesto 11 minuti di CPU per richiesta e ha reso il sito non rispondente per 34 minuti. Il post-mortem sul blog ufficiale Stack Status ha raccomandato di sostituire le regex di trim con il trim nativo della stringa.

Cloudflare, 2 luglio 2019: una regola WAF contenente il pattern con quantificatori annidati .*(?:.*=.*) è stata distribuita globalmente e ha consumato il 100 % della CPU su ogni server edge per 27 minuti, mettendo offline grandi porzioni di internet pubblico. Il post-mortem di Cloudflare sul loro blog ha accreditato il passaggio alla crate regex di Rust (un motore basato su RE2, tempo lineare) per aver impedito la ricorrenza.

Le lezioni difensive: evitare quantificatori annidati ((a+)+, (a*)*, (a|aa)+); evitare trim in stile \s+$ su input controllati dall'attaccante; preferire gruppi atomici (?>...) o quantificatori possessivi a++ in PCRE; e per servizi ad alto throughput considerare un motore basato su RE2.

Email, URL, telefono, data, carta di credito: quando non usare regex

Email. La grammatica completa di RFC 5322 (ottobre 2008) si compila in una regex di circa 3 000 caratteri. La specifica HTML5 del W3C per la validazione di <input type="email"> usa una regex molto più breve «sembra-plausibilmente-un-email» che è il giusto punto di partenza per i suggerimenti lato client. RFC 6531 (febbraio 2012) consente indirizzi non-ASCII come 用户@example.com, che una regex solo ASCII rifiuterà erroneamente. Il consenso dell'industria dal RFC 6532: non validare email con regex, inviare invece un'email di verifica.

URL. RFC 3986 (gennaio 2005) è la spec di sintassi generica URI, ma il WHATWG URL Living Standard diverge deliberatamente da essa per corrispondere a ciò che i browser accettano realmente. Usa new URL("...") in JavaScript o urllib.parse in Python invece di una regex per qualsiasi cosa oltre a un controllo visivo rapido.

Numeri di telefono. La Raccomandazione E.164 dell'ITU-T (revisione attuale novembre 2010) consente fino a 15 cifre con un prefisso + opzionale, ma le regole specifiche per paese variano enormemente. La libreria open source di Google libphonenumber codifica le regole per paese per ogni territorio ed è l'unico validatore affidabile inter-paese.

Date. Una regex come ^\d{4}-\d{2}-\d{2}$ corrisponde al formato di calendario ISO 8601-1:2019, ma accetta anche 2026-02-31. La validità della data richiede logica di calendario, non corrispondenza di pattern; usa Date.parse() o una libreria di date.

Carte di credito. Una regex può corrispondere alla lunghezza delle cifre e al prefisso IIN (Visa inizia con 4, Mastercard con 51-55 o 2221-2720, Amex con 34 o 37) ma non può verificare il checksum Luhn (Hans Peter Luhn, IBM, brevetto US 2 950 048 concesso ad agosto 1960). Luhn richiede una somma cifra per cifra modulo 10.

Modi comuni in cui gli sviluppatori usano questa libreria

• Suggerimenti di modulo lato client, con la comprensione che una corrispondenza regex è un suggerimento, non una validazione finale.
• Estrazione di log, tirando timestamp, IP, codici di errore e URL dai log dell'applicazione in una pipeline.
• Pulizia dati una tantum: normalizzare gli spazi, rimuovere i tag HTML, convertire tra formati di data, slugificare titoli.
• Trova-e-sostituisci nell'editor in VS Code, Sublime, vim, IntelliJ dove la variante regex è vicina a PCRE.
• Pattern di corrispondenza router e URL in Express, Flask, FastAPI, Rails.
• Regole WAF e rilevamento intrusioni, con estrema cautela su ReDoS come dimostrato dall'incidente Cloudflare 2019.
• Test rapido di stringhe nel pannello di test in fondo alla pagina, prima di impegnare il pattern al codice.

Errori comuni

• Dimenticare le ancore. Senza ^ e $ (o \A e \z in PCRE), una regex di validazione corrisponde se il pattern appare ovunque nella stringa. /\d{4}/ corrisponde a «year 2026 was good», che non è quasi mai ciò che si vuole.
• Fidarsi di .* su più cose. <a href=".*"> sull'input <a href="a"><a href="b"> cattura attraverso entrambi i tag perché .* è avido. Usa .*? per lazy, o meglio, parsifica con un parser reale.
• Supporre che il punto corrisponda alle nuove righe. Per impostazione predefinita . corrisponde a tutto eccetto i terminatori di riga. Usa il flag s (dotAll) in JS, o re.DOTALL in Python, o il modificatore inline (?s) in PCRE.
• Supporre che \w includa lettere non ASCII. In modalità ASCII, \w è [a-zA-Z0-9_]. Aggiungi il flag u in JS (ES2018+) e usa \p{L} per qualsiasi lettera Unicode; in Python aggiungi re.UNICODE (predefinito in Python 3).
• Retroreferenze in Go. regexp di Go è RE2 e rifiuta \1 in fase di compilazione. L'errore «error parsing regexp: invalid escape sequence: \1» significa che il pattern deve essere suddiviso in un approccio non-regex.
• Analizzare HTML con regex. Notoriamente impraticabile: HTML non è un linguaggio regolare. Usa un parser DOM (il DOMParser integrato del browser, cheerio, BeautifulSoup, lxml).

Altre domande frequenti

Perché alcuni pattern usano (?:...) invece di (...)?

(?:...) è un gruppo non catturante: raggruppa per ripetizione o alternanza ma non alloca uno slot di retroreferenza. È più veloce ed evita di inquinare $1, $2 nell'array dei risultati. Usa (...) quando devi estrarre il testo catturato; usa (?:...) per il solo raggruppamento.

Quali sono i flag regex più comuni?

i insensibile alle maiuscole, g globale (trova tutto, comportamento specifico JS), m multiriga (in modo che ^ e $ corrispondano ai confini di riga), s dotAll (in modo che . corrisponda alle nuove righe, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v classi di notazione di insieme (ES2024+). Combinali come /pattern/gimsu.

Come faccio corrispondere un carattere speciale letterale?

Esciscapelo con una barra rovesciata. I metacaratteri regex che richiedono escape per una corrispondenza letterale sono: . ^ $ * + ? ( ) [ ] { } | \ /. All'interno di una classe di caratteri [...] l'insieme dei caratteri speciali è più piccolo: solo ] \ ^ - necessitano di escape, a seconda della posizione.

Posso usare i pattern di questa libreria negli script shell?

Sì, con riserve. grep usa POSIX BRE per impostazione predefinita; grep -E usa ERE; grep -P usa PCRE sui sistemi dove libpcre è collegata (GNU grep, macOS grep con Homebrew). I pattern che usano lookaround, gruppi nominati o escape Unicode necessitano di grep -P o ripgrep (che usa il motore RE2-based di Rust e rifiuta lookaround).

Questi pattern vengono inviati a un server?

No. Ogni regex su questa pagina, ogni ricerca che digiti e ogni stringa che testi nel pannello di test rapido viene elaborata nel motore JavaScript del tuo browser. Nessuna chiamata di rete viene effettuata. I dati di pattern stessi sono consegnati come file JSON statico nel bundle della pagina. Apri la scheda Rete in DevTools per verificare.