Como testar expressões regulares online

Expressões regulares são uma das ferramentas mais poderosas em programação, e uma das mais frustrantes de dominar. Um testador de regex permite que voce construa e depure padrões interativamente em vez de executar seu código, verificar a saída e adivinhar o que deu errado. O loop de feedback cai de minutos por iteração para segundos.

Por que usar um testador de regex

Escrever regex no seu editor de código significa que voce só ve erros em tempo de execução. Um testador mostra:

• Destaque de correspondencia ao vivo: ver exatamente quais partes do seu texto correspondem enquanto voce digita o padrão
• Grupos de captura: ver o que cada grupo captura sem escrever saída de depuração
• Detalhes da correspondencia: posições exatas, comprimentos e conteúdo de cada correspondencia
• Visualização de substituição: ver o resultado de localizar-e-substituir antes de se comprometer com ele

Como testar regex online

1. Digite seu padrão: digite o regex no campo de padrão. Alterne flags (g para global, i para insensível a maiúsculas, m para multilinha) conforme necessário.
2. Cole seu texto de teste: digite o texto contra o qual voce deseja corresponder. As correspondencias destacam em tempo real.
3. Veja resultados: veja todas as correspondencias com grupos de captura listados abaixo. Use o campo "Substituir por" para testar substituições.

Uma breve história das expressões regulares

Expressões regulares foram formalizadas pelo matemático Stephen Kleene em 1951 como uma notação para "eventos regulares" em seu trabalho sobre redes neurais. Elas saltaram da teoria para o uso prático quando Ken Thompson as implementou no editor de texto QED na Bell Labs em 1968, depois no editor ed (1969), e finalmente no utilitário grep (1973), cujo nome vem de "global / regular expression / print."

Perl, introduzido por Larry Wall em 1987, expandiu significativamente a sintaxe regex: quantificadores não-gulosos, lookahead, grupos nomeados, atalhos de classe de caracteres como \d e \w. A biblioteca Perl-Compatible Regular Expressions (PCRE), lançada em 1997, tornou-se o padrão de fato para a maioria das linguagens modernas.

Hoje, praticamente toda linguagem de programação tem suporte regex embutido, embora a sintaxe varie ligeiramente. O motor JavaScript (V8 no Chrome, SpiderMonkey no Firefox) é altamente otimizado e alimenta a maioria dos testadores regex online. PHP, Python (módulo re), e Java (java.util.regex) usam sintaxe intimamente relacionada mas não identica. Saber para qual sabor voce está escrevendo importa para recursos avançados.

Padrões regex comuns que vale a pena conhecer

Endereço de e-mail (básico):

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

URL:

https?://[^\s]+

Número de telefone (US):

\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}

Data (AAAA-MM-DD):

\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])

Endereço IP (IPv4):

\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b

Código de cor hex:

#(?:[0-9a-fA-F]{3}){1,2}\b

Slug (identificador seguro para URL):

^[a-z0-9]+(?:-[a-z0-9]+)*$

String com espaços aparados:

^\s*(.*?)\s*$

Diferenças de sabor entre linguagens

A sintaxe regex é principalmente portátil mas tem armadilhas:

• JavaScript: lookbehinds adicionados em ES2018 ((?<=...), (?<!...)), suportado em Chrome 62+, Firefox 78+, Safari 16.4+. Grupos nomeados via (?<nome>...).
• Python: o módulo re suporta quase todos os recursos Perl; o pacote de terceiros regex adiciona ainda mais (lookbehind de comprimento variável, correspondencia difusa).
• Java: \b para limite de palavra funciona igual; grupos nomeados usam (?<nome>...). Padrão Pattern.compile + matcher.
• PHP: a família preg_match usa PCRE sob o capo. Padrões requerem delimitadores: /padrão/flags.
• Go: usa sintaxe RE2 (sem referencias para trás, sem lookaround) para desempenho linear garantido. Alguns padrões que funcionam em JS/PCRE falham em Go.
• Rust: o crate regex usa RE2 por padrão; o crate fancy-regex adiciona lookaround.

Quando voce escreve um regex em um testador (quase sempre sabor JavaScript), confirme que a linguagem alvo suporta todos os recursos que voce usou antes de se comprometer com ele.

Armadilhas comuns

• Backtracking catastrófico: padrões como (a+)+b contra aaaaaaaaaaaaaaaaaaaaaaaac podem levar tempo exponencial. O motor regex tenta cada agrupamento possível. Use quantificadores possessivos ((a++)+) ou grupos atomicos (?>a+)+ para prevenir isso. RE2 e Go regex são imunes por design.
• Quantificadores gulosos vs preguiçosos: a.*b corresponde tanto quanto possível (guloso); a.*?b corresponde tão pouco quanto possível (preguiçoso). Confundir um com o outro é a fonte #1 de "meu regex corresponde demais."
• Ancoras no modo multilinha: ^ e $ correspondem ao início/fim da string por padrão. Com a flag m, eles correspondem ao início/fim de cada linha. Esquecer isso dá resultados incompletos.
• Caracteres especiais em classes de caracteres: dentro de [...], a maioria dos caracteres especiais perde seu significado. [.] corresponde a um ponto literal. Mas ], \ e ^ (no início) ainda precisam ser escapados.
• Unicode e \w: \w é [A-Za-z0-9_] na maioria dos sabores, então NÃO corresponde a letras acentuadas como é ou scripts não latinos. Use \p{L} (escape de propriedade Unicode) ou passe a flag u em JS.
• Esquecer a flag global: sem g, métodos como String.matchAll() lançam, e .replace() só substitui a primeira correspondencia. O testador usa global por padrão, mas seu código real pode não usar.
• Ancorar validação de entrada completa: ^foo$ garante que toda a entrada seja "foo." Sem as ancoras, foo corresponde em qualquer lugar da string, o que é um risco de segurança em validação de entrada.

Quando NÃO usar regex

Regex é a ferramenta errada para alguns trabalhos:

• Analisar HTML ou XML: estruturas aninhadas, atributos e espaços arbitrários tornam regex impraticável. Use um analisador apropriado (DOMParser, BeautifulSoup, lxml).
• Analisar JSON: mesma razão. Use JSON.parse() ou equivalente.
• Analisar código fonte: analisadores AST (Acorn, Esprima, AST-grep) entendem sintaxe. Regex só ve texto.
• Validação de e-mail: o regex de e-mail válido RFC 5322 tem mais de 6.000 caracteres. Para validação real, envie um e-mail de confirmação em vez disso.
• Regras de força de senha: padrões regex complexos para "deve conter maiúscula, minúscula, dígito, caractere especial" são difíceis de manter. Componha múltiplas verificações simples em vez disso.

Se voce se encontrar escrevendo um regex de mais de 100 caracteres com múltiplos grupos aninhados, voce provavelmente está resolvendo o problema errado.

Dicas para escrever melhor regex

• Comece simples: faça um padrão básico funcionar primeiro, depois adicione complexidade. Tentar escrever o regex perfeito de uma vez raramente funciona.
• Use a flag global (g): sem ela, o testador para na primeira correspondencia. Com g, voce ve todas as correspondencias no texto.
• Teste casos extremos: seu regex pode corresponder aos casos óbvios mas falhar em strings vazias, caracteres especiais ou condições limite. Adicione esses ao seu texto de teste.
• Escape caracteres especiais: caracteres como ., *, +, ?, (, ), [, ], {, }, \, ^, $ e | tem significado especial em regex. Para corresponde-los literalmente, prefixe com uma barra invertida.
• Use grupos não-capturantes: se voce precisa de parenteses para agrupamento mas não precisa da captura, use (?:...) em vez de (...). Isso mantém seus resultados de correspondencia mais limpos.
• Comente padrões complexos: a maioria dos sabores suporta a flag x (modo estendido), que permite espaços em branco e # comentários dentro do padrão. Use-o para regex com mais de 50 caracteres.
• Salve seus testes: um regex que funciona no seu texto de teste hoje deve funcionar em entradas similares para sempre. Salve os casos de teste ao lado do regex no seu código-fonte como documentação.

Privacidade e dados de teste confidenciais

O testador regex roda inteiramente no seu navegador usando o motor RegExp nativo do JavaScript. O padrão que voce escreve, o texto de teste que voce cola e as correspondencias que voce ve permanecem todos no seu dispositivo. Nada é carregado, registrado ou analisado por qualquer servidor.

Isso importa porque o texto de teste regex frequentemente contém informações sensíveis: amostras de log de produção (com IDs de usuário reais, endereços IP, tokens de sessão), listas de e-mail puxadas de um CRM, dados de cliente formatados de maneiras incomuns. Testadores regex em nuvem roteiam tudo isso através de seus servidores, às vezes salvando para fins de "melhoria." Um testador baseado em navegador tem zero exposição para qualquer um deles.