Tester e debugger Regex

Riferimento rapido

Informazioni sulle espressioni regolari

Le espressioni regolari (regex) sono pattern utilizzati per abbinare combinazioni di caratteri in stringhe. Sono uno strumento essenziale nella programmazione, nell'elaborazione del testo, nella validazione dei dati e nelle operazioni di ricerca. Ogni linguaggio di programmazione principale supporta regex · JavaScript, Python, Java, PHP, Ruby, Go e altri.

Questo tester utilizza il motore RegExp integrato di JavaScript, che supporta la sintassi regex ECMAScript inclusi lookahead, character class, quantificatori e i flag g, i, m e s. Le corrispondenze vengono evidenziate in tempo reale mentre digiti, e i capture group vengono visualizzati nel pannello dei dettagli delle corrispondenze.

Usi comuni

• Validare indirizzi email, numeri di telefono e input dei moduli
• Estrarre dati da file di log, CSV o HTML
• Trovare e sostituire pattern di testo negli editor di codice
• Analizzare URL, percorsi di file e testo strutturato
• Scrivere selettori di web scraping e filtri di ricerca

Domande frequenti

Cosa fanno i flag g, i, m e s?

g (global) trova tutte le corrispondenze invece di fermarsi alla prima. i (case insensitive) ignora maiuscole e minuscole. m (multiline) fa sì che ^ e $ corrispondano all'inizio/fine di ogni riga. s (dotAll) fa sì che . corrisponda anche ai caratteri di ritorno a capo.

Questo regex funzionerà in Python / Java / PHP?

La maggior parte della sintassi regex è condivisa tra i linguaggi. Tuttavia, ci sono differenze · per esempio, JavaScript non supporta i lookbehind in tutti i browser (anche se quelli moderni sì), e Python usa una sintassi diversa per i named group. Per i pattern di base, ciò che funziona qui funzionerà ovunque.

I miei dati di test vengono inviati da qualche parte?

No. Tutta la corrispondenza regex avviene localmente nel tuo browser utilizzando il motore RegExp nativo di JavaScript. Nulla viene inviato ad alcun server.

Cos'è un regex tester?

Un regex tester è un editor interattivo che esegue un'espressione regolare contro una stringa di esempio e ti mostra esattamente cosa ha trovato corrispondenza, cosa no e cosa contengono i gruppi di cattura. Il tester ti permette di iterare velocemente: digita il pattern, vedi gli evidenziatori, regola, ripeti. Sostituisce il loop lento di modificare il codice sorgente, eseguire uno script e leggere l'output della console.

Le espressioni regolari stesse sono una sintassi di pattern inventata da Stephen Cole Kleene nel 1956 per descrivere insiemi di stringhe. Le moderne implementazioni regex (PCRE, RegExp di JavaScript, re di Python, System.Text.RegularExpressions di .NET, java.util.regex di Java) condividono la maggior parte della loro sintassi ma differiscono in casi limite come lookbehind, gruppi nominati, gestione Unicode e comportamento dei quantificatori.

Questo tester usa il motore RegExp nativo JavaScript del tuo browser, che implementa regex ECMAScript 2024 incluse tutte le flag standard (g, i, m, s, u, y, d) e i moderni lookbehind. L'output è esattamente quello che il tuo codice front-end vedrà al runtime, il che rende il tester particolarmente utile quando si fa debug della validazione client-side, dei selettori di scraping o delle trasformazioni replace-with-callback.

Cosa c'è dentro il tester

La riga superiore contiene l'input del pattern fiancheggiato da barre, seguito da pulsanti toggle per le quattro flag più usate (g, i, m, s). Un pulsante Patterns apre una libreria di snippet regex comuni (email, URL, telefono, data) che puoi cliccare per riempire il campo pattern. Dietro le quinte l'input è debounced così riscrivere non fa thrash al matcher.

Sotto il pattern, la textarea Test String è dove incolli il testo di esempio. Le corrispondenze sono evidenziate con uno sfondo giallo nel pannello Highlighted Matches che si aggiorna mentre digiti. Il campo Replace with accetta una stringa di sostituzione con backreference ($1, $2, ecc.) e mostra il testo risultante dal vivo, perfetto per testare le trasformazioni di sostituzione stringhe prima di incollarle nel tuo codice.

La lista Match Details mostra ogni corrispondenza con il suo indice a base zero nella sorgente, la sottostringa corrispondente e ogni gruppo di cattura. Una card Quick Reference in fondo riassume la sintassi per classi di caratteri, quantificatori, ancore e lookaround, così non devi cambiare contesto a una scheda di documentazione per le basi.

Storia e contesto

Stephen Cole Kleene definisce eventi regolari (1956)

Il matematico Stephen Cole Kleene pubblicò il paper Representation of Events in Nerve Nets and Finite Automata nel 1956, introducendo quelli che chiamò eventi regolari: pattern che descrivono insiemi di stringhe accettati da un automa finito. La stella di Kleene (l'operatore *) porta il suo nome. La sua notazione algebrica è l'antenato diretto di ogni sintassi regex in uso oggi.

Ken Thompson spedisce grep (1968)

Ken Thompson dei Bell Labs implementò un motore regex nel 1968 dentro l'editor QED e di nuovo in grep (1973), l'utility Unix il cui nome viene dal comando QED g/regular-expression/p. Il motore basato su NFA di Thompson girava in tempo lineare per carattere, una garanzia che i motori con backtracking persero più tardi quando aggiunsero funzionalità come le backreference.

Perl 5 introduce regex estesi (1994)

Larry Wall rilasciò Perl 5 nel 1994 con un sapore regex che aggiunse lookahead, lookbehind, cattura nominate (più tardi), modificatori inline e backreference. La regex Perl 5 divenne così dominante che altri linguaggi copiarono la sua sintassi. Philip Hazel creò PCRE (Perl Compatible Regular Expressions) nel 1997 come libreria C, e PCRE oggi alimenta regex in PHP, Apache, NGINX e molti altri strumenti.

JavaScript spedisce RegExp (1995, formalizzato nel 1999)

JavaScript 1.0 di Brendan Eich nel 1995 spedì con un oggetto RegExp modellato su Perl 5. L'edizione 3 di ECMAScript (1999) formalizzò la sintassi. Le edizioni successive aggiunsero la flag Unicode u (ES2015), la flag sticky y (ES2015), gruppi nominati (ES2018), lookbehind (ES2018) e flag indices d (ES2022). I browser raggiunsero nel tempo, e i motori moderni (V8, SpiderMonkey, JavaScriptCore) implementano la spec ES2024 completa.

ReDoS, regex denial of service (2003 in poi)

I ricercatori notarono che i motori regex con backtracking possono impiegare tempo esponenziale su certi input, una classe di vulnerabilità chiamata ReDoS (Regular expression Denial of Service). Un'interruzione di Cloudflare del 2019 fu tracciata a una regex con backtracking catastrofico. Strumenti come rxxr e node-re2 emersero per rilevare o aggirare il problema, e i motori iniziarono a far rispettare budget di tempo sulle corrispondenze a lunga esecuzione.

Le proprietà Unicode arrivano in ECMAScript (2018)

ES2018 aggiunse escape di proprietà Unicode come \p{Script=Latin} o \p{Letter}, che ti permettono di matchare per categoria Unicode senza enumerare code point. Combinati con la flag u, le regex possono ora distinguere emoji da lettere, script l'uno dall'altro e gestire correttamente le coppie surrogate. Questo rende le regex JavaScript finalmente adatte al matching di testo internazionale, un problema che la vecchia sintassi solo-ASCII non poteva risolvere.

Flussi di lavoro pratici

Validazione email

Rilascia un campione di email valide e non valide nell'area di test, digita la tua regex candidata (un punto di partenza comune è ^[^@\s]+@[^@\s]+\.[^@\s]+$) e ritocca finché le email valide non si evidenziano e quelle non valide no. Sii consapevole che la spec email RFC 5321 completa è così complessa che la regex email perfetta è lunga centinaia di caratteri. Una regex pragmatica cattura i refusi; la validazione finale dovrebbe fare un round-trip attraverso SMTP reale.

Parsing ed estrazione URL

Incolla una pagina di HTML o testo normale e scrivi una regex per estrarre URL. Un pattern di partenza come https?:\/\/\S+ cattura la maggior parte dei casi. Per codice di produzione, preferisci il costruttore URL (new URL(string)) che gestisce ogni caso limite; la regex è migliore per estrazioni veloci una tantum o analisi di log.

Scraping di file di log

I log di Apache e NGINX seguono un formato fisso. Incolla alcune righe di log, scrivi una regex con cattura nominate ((?\S+) (?\S+ \S+) \"(?[^"]+)\" ...), e hai un parser pronto da alimentare in un analizzatore di log strutturato. Testa su un campione dei tuoi log reali prima del deploy.

Trova e sostituisci negli editor di codice

VSCode, Sublime Text, gli IDE JetBrains e vim tutti accettano regex nelle loro finestre find-replace. Itera prima sul pattern qui, con l'evidenziatore live che mostra esattamente cosa corrisponde, poi incolla la regex nella finestra dell'editor. Risparmiati il dolore di errori su un codebase di 5.000 righe.

Web scraping di nomi di classi CSS

Quando hai bisogno di estrarre dati da HTML senza un parser (uno script una tantum, non produzione), una regex come class="([^"]+)" estrae gli attributi class. Per qualsiasi cosa oltre un'esplorazione veloce, passa a una libreria DOM appropriata; HTML non è un linguaggio regolare e la regex perde casi limite.

Validare stringhe di semantic version

Semver segue ^\d+\.\d+\.\d+(-[\w.]+)?(\+[\w.]+)?$. Rilascia una lista di versioni (1.0.0, 1.2.3-beta.1+build.456) nell'area di test per controllare che la regex catturi correttamente pre-release e metadati di build. Questo è utile quando validi le dipendenze negli script CI.

Trappole comuni

Quantificatori greedy vs lazy

Per default *, + e ? sono greedy: matchano il più possibile, poi fanno backtracking se il resto della regex fallisce. Le versioni lazy *?, +?, ?? matchano il meno possibile. L'esempio classico è <.*> su text che matcha l'intera stringa, mentre <.*?> matcha solo e separatamente. Scegli quello giusto per evitare sorprese di over-matching.

Backtracking catastrofico (ReDoS)

Quantificatori annidati come (a+)+ o (.*)* su un lungo input che non matcha possono impiegare tempo esponenziale mentre il motore prova ogni combinazione. La scheda del browser può congelarsi o crashare. Evita gruppi di quantificatori sovrapposti, preferisci gruppi atomici (?>...) dove supportati, o pre-valida la lunghezza dell'input. La libreria npm safe-regex flagga automaticamente i pattern rischiosi.

I caratteri speciali necessitano di escape

I caratteri con significato speciale in regex (. * + ? ^ $ ( ) [ ] { } | \) devono essere preceduti da backslash per matchare letteralmente. Quindi \. matcha un punto, mentre . matcha qualsiasi carattere. Dimenticare di fare escape è la causa più comune di falsi positivi quando si validano IP, estensioni di file o numeri di versione puntati.

Ancore e flag multiline

Senza la flag m, ^ e $ matchano solo l'inizio e la fine dell'intera stringa. Con m, matchano l'inizio e la fine di ogni riga. Se la tua regex funziona su singole righe ma fallisce su input multi-riga, attiva m. Viceversa, se matcha troppo su input multi-riga, rimuovi m.

Differenze di sintassi tra motori

Questo tester usa regex JavaScript. Il re di Python usa (?P) per cattura nominate invece di (?), .NET permette le backreference \k diversamente, e PCRE ha funzionalità come i sottopattern ricorsivi (?R) che JavaScript non ha. Se il tuo target finale è Python o Java, valida anche su quei motori prima di spedire.

Unicode senza la flag u

Senza la flag u, le regex JavaScript trattano le coppie surrogate (emoji, supplementi CJK) come due code unit separate. \u{1F600} (emoji faccia sorridente) non funziona senza u. Con la flag u, la regex diventa Unicode-aware, gli escape di proprietà come \p{Letter} diventano disponibili, e la gestione delle coppie surrogate è corretta. Imposta sempre u quando matchi testo internazionale.

Privacy e gestione dei dati

Ogni regex viene compilata ed eseguita dal motore RegExp del tuo browser. Non inviamo il tuo pattern, la tua stringa di test o il tuo template di sostituzione a nessun server. Il matcher gira localmente, gli evidenziatori sono renderizzati localmente, e la lista Match Details è calcolata localmente. Non ci sono analytics legate al contenuto dei tuoi input.

Una volta caricata la pagina, il tester funziona offline. Puoi disconnetterti dalla rete, incollare righe di log sensibili o PII, ed eseguire pattern contro di esse senza che alcun dato lasci il tuo dispositivo. Questo rende lo strumento sicuro per testare regex contro dati di produzione senza inviarli attraverso un servizio di terze parti.

Quando non usare una regex

Parsare HTML o XML

HTML non è un linguaggio regolare. Non puoi parsare in modo affidabile tag annidati con regex; la famosa risposta su Stack Overflow su Zalgo e Cthulhu fa questo punto in modo colorito. Usa DOMParser o una libreria come cheerio (Node.js) o BeautifulSoup (Python) invece. La regex va bene per estrazioni una tantum ma si rompe su casi limite come tag self-closing, commenti, CDATA e input malformati.

Qualsiasi cosa veramente ricorsiva (JSON, codice sorgente, espressioni matematiche)

Parentesi graffe bilanciate, parentesi tonde bilanciate, chiamate di funzione annidate, precedenza aritmetica, tutto richiede una grammatica context-free, non una regolare. Usa un parser combinator (Parsimmon, nom) o un generatore (pegjs, antlr). La regex può matchare token di apertura o chiusura ma non può tracciare il bilanciamento.

Quando una semplice operazione su stringa basta

Se hai bisogno di controllare se una stringa inizia con prefix-, usa str.startsWith("prefix-"), non /^prefix-/. I metodi delle stringhe sono più veloci, più chiari e impossibili da sbagliare con i quantificatori. Riserva la regex per pattern che i metodi delle stringhe non possono esprimere.

Validazione di schema complessa

Validare che un documento JSON abbia una forma specifica (campi richiesti, tipi annidati, intervalli di valori) è fatto molto meglio con un validatore JSON Schema (ajv, zod, joi) che con una regex. La regex può controllare il formato ma non la struttura, e una regex che cerca di validare un documento JSON è un incubo di manutenzione.

Altre domande

Quando dovrei usare lookahead vs lookbehind?

Lookahead (?=...) asserisce che ciò che segue matcha senza consumarlo; lookbehind (?<=...) fa lo stesso per ciò che precede. Usa lookahead quando il contesto successivo determina se matchare, lookbehind quando il contesto precedente lo fa. JavaScript supporta entrambi dal 2018 (ES2018), e tutti i browser moderni lo fanno. Le versioni più vecchie di Safari prima della 16.4 mancavano del supporto lookbehind.

Lookbehind è supportato in tutti i browser?

Lookbehind (positivo e negativo) è supportato in Chrome dalla versione 62 (2017), Firefox dalla 78 (2020), Edge dalla 79 (2020) e Safari dalla 16.4 (2023). Se il tuo pubblico può usare Safari più vecchio, evita lookbehind o usa un polyfill con un pattern alternativo. Per Node.js, lookbehind è stato supportato dalla 10.0.

Cosa fa la flag Unicode (u)?

La flag u abilita la modalità Unicode: le coppie surrogate sono trattate come un singolo carattere, gli escape \u{...} funzionano, e gli escape di proprietà \p{...} diventano disponibili. Senza u, un'emoji come la faccia sorridente conta come due code unit e . matcha solo la prima metà. Imposta sempre u quando lavori con testo oltre l'ASCII.

Quanto è veloce il motore regex?

Il motore RegExp di V8 usa un'implementazione Irregexp che compila in codice nativo. Per pattern semplici matcha milioni di caratteri al secondo. Pattern patologici (quantificatori annidati su input avversario) possono esplodere a tempo esponenziale, motivo per cui ReDoS è un vero vettore di attacco. I motori moderni applicano euristiche per rilevare e abortire match runaway, ma dovresti comunque evitare pattern rischiosi.

Come differiscono le regex JavaScript e Python?

I gruppi nominati usano sintassi diversa (? in JS, ?P in Python). Python manca della flag y (sticky); JavaScript manca della modalità verbose di Python. Python supporta la ricorsione tramite il modulo regex di terze parti ma non il re built-in. La shorthand delle classi di caratteri differisce leggermente (\d significa [0-9] in entrambi, ma \w in Python include underscore in modalità Unicode mentre JS richiede la flag u per lo stesso comportamento).

Posso usare l'AI per generare regex invece?

Gli LLM sono bravi a proporre pattern regex iniziali ma di routine producono output sottilmente sbagliati (greedy dove serviva lazy, escape mancanti, flag sbagliate). Usa l'AI per le prime bozze, poi valida eseguendo la regex contro campioni reali in questo tester. Itera finché gli evidenziatori non corrispondono esattamente a ciò che ti aspetti. Il ciclo di feedback interattivo cattura gli errori degli LLM prima che arrivino in produzione.

Strumenti correlati