Guia rápido de Regex gratuito

Uma breve história da linguagem de padrões

As expressões regulares começaram como um pedaço de ciência da computação teórica. Stephen Kleene definiu «conjuntos regulares» num artigo de 1956 sobre redes neuronais; Ken Thompson colocou-as no Unix em 1968 com o grep. A biblioteca regex open-source de Henry Spencer (meados dos anos 1980) tornou-se a base de muitas implementações posteriores. Larry Wall estendeu a sintaxe dramaticamente em Perl, e as suas «expressões regulares compatíveis com Perl» (PCRE) tornaram-se o padrão de facto que a maioria das linguagens modernas seguiu. Hoje há várias variantes regex próximas mas subtilmente diferentes, e um padrão que funciona num motor nem sempre funciona identicamente noutro.

O motor onde o seu padrão vive

A mesma sintaxe pode significar coisas diferentes em motores diferentes. As grandes famílias:

• POSIX BRE (Basic Regular Expressions), usada pelo modo predefinido do grep, pelo sed. Muitos metacaracteres precisam de escape com barra invertida: (, ), {, }, +, ?, | são literais a menos que escapados.
• POSIX ERE (Extended Regular Expressions), usada pelo egrep, awk. Os metacaracteres acima funcionam sem escapar.
• PCRE (Perl-Compatible Regular Expressions), estende o ERE com lookarounds, atomic groups, capturas com nome e backreferences. Usada pelo PHP e pela maioria das linguagens modernas. As classes abreviadas derivadas do Perl \d / \w / \s são comuns ao PCRE, JavaScript, .NET, Java e Python.
• JavaScript RegExp, próxima do PCRE mas com diferenças notáveis. O ES2018 adicionou lookbehinds, grupos de captura com nome, a flag dotall s e os Unicode property escapes via a flag u. A flag v para notação de conjuntos chegou no ES2024.
• re do Python e regex do Python, o re está na biblioteca padrão; o módulo de terceiros regex adiciona funcionalidades Unicode-aware, lookbehinds de largura variável e outras melhorias estilo PCRE.
• RE2 (a biblioteca da Google, usada em Go), garante tempo linear mas não suporta backreferences nem lookarounds. O compromisso: desempenho previsível, menos funcionalidades.

O testador interactivo desta cábula corre em JavaScript, por isso o padrão é avaliado pelo motor JS do navegador. Padrões que funcionam aqui podem comportar-se de forma diferente em Python ou PHP. A maioria das diferenças está em funcionalidades avançadas (lookbehinds, Unicode property escapes, backreferences) e não na sintaxe básica.

Os blocos de construção centrais

Quase todo padrão regex é construído a partir destes elementos:

• Literais, correspondem a si próprios. cat corresponde à substring «cat».
• Âncoras, ^ (início da string / linha), $ (fim), \b (fronteira de palavra), \B (não-fronteira de palavra).
• Classes de caractere, [abc] corresponde a a, b ou c. [^abc] nega. [a-z] é um intervalo. Abreviaturas: \d (dígito), \w (caractere de palavra: letra, dígito, underscore), \s (espaço em branco), e versões em maiúsculas para negação (\D, \W, \S).
• Quantificadores, ? (0 ou 1), * (0 ou mais), + (1 ou mais), {n}, {n,}, {n,m}. Gananciosos por padrão (correspondem a tanto quanto possível); adicione ? para preguiçoso: *?, +?, ??.
• Grupos, (...) capturador, (?:...) não-capturador, (?<name>...) com nome (PCRE / JS / Python).
• Alternância, cat|dog corresponde a qualquer um.
• Lookarounds, (?=...) lookahead positivo, (?!...) lookahead negativo, (?<=...) lookbehind positivo, (?<!...) lookbehind negativo. Correspondem sem consumir.
• Backreferences, \1, \2 (numeradas), \k<name> (com nome). Correspondem ao mesmo texto que a captura correspondente apanhou.
• Flags, g (global), i (insensível a maiúsculas), m (multilinha: ^ e $ correspondem a fronteiras de linha), s (dotall: . também corresponde a quebras de linha), u (Unicode), y (sticky em JS).

Padrões que valem a pena memorizar

Um punhado de padrões aparece com tanta frequência que vale a pena tê-los na cabeça:

Uma nota sobre regex de email: a validação completa RFC 5322 precisa de uma regex monstro de 6 000 caracteres. A forma simples acima aceita 99% dos endereços de email reais e não rejeita nenhum legítimo; em produção, envie um email de confirmação em vez de tentar validar perfeitamente a sintaxe.

Ganancioso vs preguiçoso: uma surpresa comum

Por padrão, os quantificadores são gananciosos: correspondem a tanto quanto possível enquanto ainda permitem que o padrão global corresponda. Por isso <.+> contra <a>text</a> corresponde à coisa toda, não apenas a <a>, porque .+ agarra tudo o que pode. Para corresponder à menor string possível, anexe ? ao quantificador: <.+?> corresponde a <a> e depois a </a> separadamente. A escolha ganancioso/preguiçoso é uma das fontes mais comuns de bugs «porque é que a minha regex não corresponde ao que eu esperava».

Backtracking catastrófico e ReDoS

Alguns padrões regex podem demorar tempo exponencial a falhar em certos inputs, uma classe de vulnerabilidade de negação-de-serviço chamada ReDoS (Regular Expression Denial of Service). Os culpados clássicos são quantificadores aninhados como (a+)+ ou (a|aa)+ aplicados a uma longa sequência de as seguida de um caractere não-correspondente. O motor tenta cada forma possível de dividir a string antes de desistir, e o número de formas é exponencial.

Incidentes do mundo real: a queda da Cloudflare em 2019 foi disparada por uma regex implantada numa regra WAF que entrou em backtracking catastrófico em certos inputs. O Stack Overflow teve um incidente semelhante em Julho de 2016: uma regex de post-trim (^[\s‌]+|[\s‌]+$) bateu em backtracking exponencial num único comentário que continha cerca de 20 000 caracteres consecutivos de espaço em branco e derrubou o site durante 34 minutos. Hábitos defensivos: evite quantificadores aninhados, prefira atomic groups ((?>...)) onde estejam suportados, e considere usar RE2 / motores de tempo linear para input não confiável.

Particularidades por linguagem que vale a pena conhecer

• JavaScript: as barras invertidas precisam de escape duplo em literais de string ("\\d") mas não em literais regex (/\d/). Use a forma literal regex sempre que possível.
• Python: use strings cruas (r"\d+") para evitar problemas de barra invertida. O módulo re está na biblioteca padrão; regex no PyPI adiciona funcionalidades extra.
• Java: as barras invertidas precisam de escape quádruplo ("\\\\d" para \d) porque os literais de string Java usam \ como escape e o compilador regex vê depois \\d.
• Bash: a correspondência regex em [[ string =~ pattern ]] usa POSIX ERE. As regras de aspas são complicadas; consulte man bash.
• Go: usa RE2, por isso backreferences e lookarounds não estão disponíveis. Compromisso: garantia de tempo linear.

Quando NÃO usar regex

A famosa frase de Jamie Zawinski de 1997: «Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems.»

• Não faça parsing de HTML / XML com regex. Use um parser real (DOMParser nos navegadores, BeautifulSoup em Python, jsoup em Java, etc.). A estrutura aninhada do HTML está fundamentalmente além do que a regex consegue exprimir limpamente.
• Não faça parsing de JSON com regex. Use JSON.parse / parsers JSON da biblioteca padrão.
• Não valide emails estritamente com regex. Envie um email de confirmação; é o único teste fiável.
• Não escreva um parser CSV como uma regex. Campos entre aspas com vírgulas embutidas, aspas escapadas e valores multilinha rapidamente ultrapassam o que a regex trata limpamente.
• Não tente fazer match de parênteses equilibrados. A regex padrão não consegue (é uma linguagem livre de contexto); alguns motores PCRE têm funcionalidades de recursão que fazem batota, mas um parser real é mais limpo.

Erros comuns

1. Esquecer-se de escapar caracteres especiais. ., *, ?, +, (, ), [, ], {, }, \, ^, $, |, / têm todos significados especiais. Para fazer match deles literalmente, prefixe com barra invertida.
2. Quantificadores gananciosos a consumir demais. Adicione ? para matching preguiçoso quando quiser a menor correspondência possível.
3. Esquecer-se da flag global e perguntar-se porque só aparece a primeira correspondência. O String.prototype.match() do JavaScript devolve apenas a primeira correspondência sem a flag g.
4. Backtracking catastrófico em inputs longos. Quantificadores aninhados como (a+)+ podem prender em certos inputs. Teste com casos limite.
5. Assumir que a mesma regex se comporta da mesma forma em todas as linguagens. Lookbehinds, escapes Unicode e atalhos de classe de caractere variam todos.
6. Tentar validar emails estritamente demais. A regex tecnicamente correcta RFC 5322 é impossível de manter; uma regex simples mais email-de-confirmação-no-registo é o padrão que funciona.
7. Usar regex em HTML, JSON ou CSV. Use um parser próprio; o tempo que poupa à partida vai perder em bugs.

Mais perguntas frequentes

Por que é que o meu padrão funciona aqui mas falha no meu código?

A causa mais comum são as diferenças entre motores. O RegExp do JavaScript não suporta algumas funcionalidades que o PCRE suporta (e vice-versa). Armadilhas comuns: lookbehinds adicionados tarde ao JS (ES2018), a sintaxe de grupos com nome difere ligeiramente, os Unicode property escapes precisam da flag u, e classes de caractere POSIX como [[:alpha:]] estão maioritariamente ausentes do JS. Teste no motor onde vai fazer deploy.

Há uma forma «global» de fazer match através de múltiplas linhas?

Duas flags trabalham juntas. A flag m (multilinha) faz com que ^ e $ correspondam ao início e fim de cada linha em vez de à string inteira. A flag s (dotall) faz com que . corresponda também a caracteres de nova linha. Combinada com g para global, pode escrever padrões que abrangem várias linhas e encontram cada correspondência: /^foo.+$/gms.

Os meus padrões e texto de teste são enviados para algum sítio?

Não. A correspondência de padrões usa o motor RegExp JavaScript embutido no navegador; nada é enviado para qualquer servidor. Isto importa quando está a testar padrões contra dados reais de logs de produção, respostas de API internas ou conteúdo sensível.

Devo aprender lookbehinds?

Úteis mas não essenciais. Os lookbehinds permitem-lhe fazer match de texto precedido por algo sem incluir esse «algo» na correspondência. Exemplo: (?<=\$)\d+ corresponde a dígitos depois de um cifrão sem consumir o cifrão. São suportados em PCRE, JavaScript moderno (ES2018+) e no módulo regex do Python. Se está a escrever padrões portáveis, verifique primeiro o motor de destino.

Por que usar (?:...) em vez de (...)?

Os grupos não-capturadores ((?:...)) são ligeiramente mais rápidos, não ocupam slot no array de capturas e mantêm os seus resultados de match limpos. Use-os sempre que precise de agrupamento para alternância ou quantificação mas não precise de extrair o texto correspondente. (http|https):// cria uma captura que pode não precisar; (?:http|https):// não cria.

Qual é a forma certa de fazer match de caracteres Unicode?

Em JavaScript, adicione a flag u e use Unicode property escapes: /\p{Letter}+/gu corresponde a sequências de letras em qualquer escrita. Sem a flag u, \w só corresponde a caracteres de palavra ASCII. O módulo re do Python é Unicode-aware por defeito em Python 3. O Java precisa de Pattern.UNICODE_CHARACTER_CLASS. A maioria dos motores tem alguma forma de ser Unicode-aware; consulte os docs do seu.