GeradoresOnline
Dev Tools

Testador de Regex

Teste expressões regulares (JavaScript) contra um texto, com destaque das correspondências.

Documentação técnica

Testador de Regex: por que a mesma expressão pode se comportar diferente em cada linguagem

Regex não é um padrão único e universal — existem várias implementações ("flavors") com diferenças reais de comportamento: PCRE (usada em PHP, e a base de muitas outras implementações), o motor nativo do JavaScript, POSIX (usado em ferramentas Unix como grep e sed), e outras variações específicas de linguagem. A sintaxe básica (classes de caracteres, quantificadores, grupos) é amplamente compartilhada, mas recursos mais avançados — lookbehind, nomeação de grupos, modificadores de flag — variam em suporte e sintaxe exata entre elas. Uma regex testada e funcionando neste testador (que roda regex JavaScript, no seu navegador) não tem garantia absoluta de se comportar identicamente se usada num backend PHP ou Python, especialmente em recursos mais avançados.

Backtracking catastrófico: quando uma regex "trava" o sistema

Certos padrões de regex — tipicamente envolvendo quantificadores aninhados que podem casar a mesma parte da string de múltiplas formas (como (a+)+b aplicado a uma string longa de "a"s sem "b" no final) — fazem o motor de regex explorar exponencialmente mais combinações de backtracking conforme a entrada cresce. Isso não é uma falha rara: é uma classe conhecida de vulnerabilidade, chamada ReDoS (Regular Expression Denial of Service), onde uma entrada cuidadosamente construída (ou mesmo acidental) faz uma validação de formulário aparentemente inofensiva travar o processo do servidor por segundos ou minutos, consumindo CPU de forma desproporcional a qualquer requisição normal.

Testar contra casos que deveriam falhar, não só os que deveriam passar

Uma regex de validação bem testada precisa de casos negativos deliberados — entradas que deveriam ser rejeitadas — tanto quanto positivos. É comum uma regex de e-mail, por exemplo, aceitar corretamente endereços válidos mas também aceitar strings claramente inválidas (por excesso de permissividade) ou rejeitar endereços válidos mas incomuns (por excesso de rigidez) — testar só com o "caminho feliz" esconde ambos os tipos de erro até a expressão encontrar um caso real em produção.

Gostou das ferramentas? Ajude a manter o site no ar: apoiar via Pix · Sobre · Contato · Política de Privacidade