In Perl, l'analisi lessicale (lexing) e il parsing delle stringhe sono spesso utilizzati per elaborare modelli testuali complessi. Molti compiti (come l'analisi delle parentesi annidate, delle virgolette, delle query SQL) non possono essere risolti con semplici espressioni regolari a causa della loro natura lineare. In questi casi si utilizzano moduli che implementano le basi del parsing, come Text::Balanced.
Text::Balanced è progettato per estrarre parentesi bilanciate, virgolette abbinate e altre strutture annidate. Funziona dove le espressioni regolari sono impotenti (ad esempio, l'analisi delle costruzioni annidate { ... { ... } ... }). Tra le alternative ci sono i moduli Parse::RecDescent, codice personalizzato basato su stack e ricorsione, e parser di terze parti.
Esempio di utilizzo di Text::Balanced e confronto con regexp:
use Text::Balanced 'extract_bracketed'; my $data = 'foo({bar(baz)},qux)'; my ($extracted, $remainder) = extract_bracketed($data, '()'); print $extracted; # Stamperà: ({bar(baz)},qux)
Un'espressione regolare non sarà in grado di analizzare correttamente le parentesi annidate:
$data =~ /(\(.*\))/; # catturerà solo la prima e l'ultima parentesi, ignorando l'annidamento
È possibile utilizzare normali espressioni regolari Perl per estrarre correttamente parentesi bilanciate in stringhe di qualsiasi livello di annidamento?
Risposta: No, le espressioni regolari Perl non possono gestire schemi ricorsivi (eccetto PCRE, ma non il Perl standard). Per compiti simili è necessario utilizzare un parser (Text::Balanced, parser basato su stack, Parse::RecDescent). Tentare di risolvere il problema con una regex porterà a errori nella sintassi annidata.
Esempio:
# NON funzionerà per foo({bar(baz)},qux) my ($br) = $data =~ /(\(.*\))/;
Storia
Nel progetto ci sono stati tentativi di analizzare JSON manualmente usando espressioni regolari. Lo sviluppatore si aspettava che l'espressione
(\{.*\})trovasse il frammento necessario, ma su dati reali con oggetti annidati, il parser selezionava un confine errato, portando a perdita di dati ed errori nell'elaborazione dei parametri di input.
Storia
Nel log XML degli eventi era necessario estrarre il contenuto di un tag con potenziali tag annidati. Una comprensione insufficiente dei principi di ricorsione nel lexing ha portato a un'analisi errata degli eventi e all'ignoranza degli elementi annidati, causando la perdita di parte delle informazioni.
Storia
Errore durante l'analisi di una query SQL nel script di migrazione: casi eccezionali come le sottoquery tra parentesi rotonde non sono stati in grado di essere analizzati. Le espressioni regolari "si rompevano" già a livello di stringhe annidate semplici, portando alla formazione di query SQL incorrecte.