Testador e depurador de Regex

Teste expressões regulares com destaque em tempo real e grupos de captura.

Nenhum dado sai do seu dispositivo

Correspondências destacadas

Detalhes da correspondência

0 matches

Referência Rápida

.Qualquer caractere exceto nova linha \dDígito (0-9) \wCaractere de palavra (a-z, A-Z, 0-9, _) \sEspaço em branco (espaço, tab, nova linha) ^Início da string (ou linha com flag m) $Fim da string (ou linha com flag m) *0 ou mais do anterior +1 ou mais do anterior ?0 ou 1 do anterior {n,m}Entre n e m do anterior [abc]Classe de caracteres: a, b ou c [^abc]Não a, b ou c (abc)Grupo de captura (?:abc)Grupo não capturante a|ba ou b \bLimite de palavra (?=abc)Lookahead positivo (?!abc)Lookahead negativo

Sobre Expressões Regulares

Expressões regulares (regex) são padrões usados para encontrar combinações de caracteres em strings. São uma ferramenta essencial em programação, processamento de texto, validação de dados e operações de busca. Todas as principais linguagens de programação suportam regex · JavaScript, Python, Java, PHP, Ruby, Go e mais.

Este testador usa o mecanismo RegExp nativo do JavaScript, que suporta a sintaxe regex ECMAScript, incluindo lookaheads, classes de caracteres, quantificadores e as flags g, i, m e s. As correspondências são destacadas em tempo real conforme você digita, e os grupos de captura são exibidos no painel de detalhes.

Usos Comuns

Perguntas Frequentes

O que as flags g, i, m e s fazem?

g (global) encontra todas as correspondências em vez de parar na primeira. i (insensível) ignora maiúsculas e minúsculas. m (multiline) faz ^ e $ corresponderem ao início/fim de cada linha. s (dotAll) faz . corresponder também a caracteres de nova linha.

Este regex funcionará em Python / Java / PHP?

A maior parte da sintaxe regex é compartilhada entre linguagens. No entanto, existem diferenças · por exemplo, o JavaScript não suporta lookbehinds em todos os navegadores (embora os modernos suportem), e o Python usa uma sintaxe diferente para grupos nomeados. Para padrões básicos, o que funciona aqui funciona em qualquer lugar.

Meus dados de teste são enviados para algum lugar?

Não. Toda a correspondência regex acontece localmente no seu navegador usando o mecanismo RegExp nativo do JavaScript. Nada é enviado a nenhum servidor.

O que é um testador de regex?

Um testador de regex é um editor interativo que executa uma expressão regular contra uma string de amostra e mostra exatamente o que correspondeu, o que não correspondeu, e o que os grupos de captura contêm. O testador permite iterar rapidamente: digite o padrão, veja os destaques, ajuste, repita. Ele substitui o ciclo lento de editar código-fonte, executar um script e ler a saída do console.

As expressões regulares em si são uma sintaxe de padrão inventada por Stephen Cole Kleene em 1956 para descrever conjuntos de strings. Implementações modernas de regex (PCRE, RegExp do JavaScript, re do Python, System.Text.RegularExpressions do .NET, java.util.regex do Java) compartilham a maior parte de sua sintaxe mas diferem em casos limítrofes como lookbehinds, grupos nomeados, tratamento de Unicode e comportamento de quantificadores.

Este testador usa o motor nativo JavaScript RegExp do seu navegador, que implementa regex ECMAScript 2024 incluindo todas as flags padrão (g, i, m, s, u, y, d) e os lookbehinds modernos. A saída é exatamente o que seu código front-end verá em tempo de execução, o que torna o testador especialmente útil ao depurar validação do lado do cliente, seletores de scraping, ou transformações replace-with-callback.

O que há dentro do testador

A linha superior contém a entrada do padrão flanqueada por barras, seguida pelos botões de alternância para as quatro flags mais usadas (g, i, m, s). Um botão Padrões abre uma biblioteca de trechos comuns de regex (email, URL, telefone, data) que você pode clicar para preencher o campo do padrão. Por trás dos panos, a entrada é debounced para que redigitar não sobrecarregue o matcher.

Abaixo do padrão, a área de texto String de Teste é onde você cola o texto de amostra. As correspondências são destacadas com fundo amarelo no painel Correspondências Destacadas que atualiza enquanto você digita. O campo Substituir por aceita uma string de substituição com retrocessos ($1, $2, etc.) e mostra o texto resultante ao vivo, perfeito para testar transformações de substituição de string antes de colá-las em seu código.

A lista Detalhes da Correspondência mostra cada correspondência com seu índice baseado em zero na fonte, a substring correspondida e cada grupo de captura. Um cartão Referência Rápida na parte inferior recapitula a sintaxe para classes de caracteres, quantificadores, âncoras e lookarounds, para que você não precise mudar de contexto para uma aba de documentação para o básico.

História e contexto

Stephen Cole Kleene define eventos regulares (1956)

O matemático Stephen Cole Kleene publicou o artigo Representation of Events in Nerve Nets and Finite Automata em 1956, introduzindo o que ele chamava de eventos regulares: padrões que descrevem conjuntos de strings aceitos por um autômato finito. A estrela de Kleene (o operador *) leva o nome dele. Sua notação algébrica é o ancestral direto de toda sintaxe de regex em uso hoje.

Ken Thompson lança grep (1968)

Ken Thompson na Bell Labs implementou um motor regex em 1968 dentro do editor QED e novamente no grep (1973), o utilitário Unix cujo nome vem do comando QED g/regular-expression/p. O motor baseado em NFA de Thompson rodava em tempo linear por caractere, uma garantia que os motores de retrocesso depois perderam ao adicionar recursos como retrocessos.

Perl 5 introduz regex estendida (1994)

Larry Wall lançou Perl 5 em 1994 com um sabor de regex que adicionou lookaheads, lookbehinds, capturas nomeadas (mais tarde), modificadores inline e retrocessos. A regex do Perl 5 se tornou tão dominante que outras linguagens copiaram sua sintaxe. Philip Hazel criou o PCRE (Perl Compatible Regular Expressions) em 1997 como biblioteca C, e o PCRE hoje alimenta regex em PHP, Apache, NGINX e muitas outras ferramentas.

JavaScript lança RegExp (1995, formalizado 1999)

O JavaScript 1.0 de Brendan Eich em 1995 lançou com um objeto RegExp modelado no Perl 5. A edição 3 do ECMAScript (1999) formalizou a sintaxe. Edições subsequentes adicionaram a flag Unicode u (ES2015), flag sticky y (ES2015), grupos nomeados (ES2018), lookbehinds (ES2018) e flag de índices d (ES2022). Os navegadores acompanharam ao longo do tempo, e os motores modernos (V8, SpiderMonkey, JavaScriptCore) implementam a especificação ES2024 completa.

ReDoS, negação de serviço por regex (2003 em diante)

Pesquisadores notaram que motores regex com retrocesso podem demorar tempo exponencial em certas entradas, uma classe de vulnerabilidade chamada ReDoS (Regular expression Denial of Service). Uma queda da Cloudflare em 2019 foi rastreada a uma regex com retrocesso catastrófico. Ferramentas como rxxr e node-re2 surgiram para detectar ou contornar o problema, e os motores começaram a impor orçamentos de tempo em correspondências de longa duração.

Escapes de propriedade Unicode chegam ao ECMAScript (2018)

ES2018 adicionou escapes de propriedade Unicode como \p{Script=Latin} ou \p{Letter}, que permitem corresponder por categoria Unicode sem enumerar pontos de código. Combinado com a flag u, regex agora pode distinguir emoji de letras, scripts uns dos outros, e tratar corretamente pares substitutos. Isso faz a regex JavaScript finalmente adequada para correspondência de texto internacional, um problema que a sintaxe antiga apenas ASCII não conseguia resolver.

Fluxos de trabalho práticos

Validação de email

Solte uma amostra de emails válidos e inválidos na área de teste, digite sua regex candidata (um ponto de partida comum é ^[^@\s]+@[^@\s]+\.[^@\s]+$), e ajuste até que os emails válidos sejam destacados e os inválidos não. Esteja ciente de que a especificação completa de email RFC 5321 é tão complexa que a regex perfeita de email tem centenas de caracteres. Uma regex pragmática pega erros de digitação; a validação final deve fazer ida e volta através de SMTP real.

Análise e extração de URL

Cole uma página de HTML ou texto puro e escreva uma regex para extrair URLs. Um padrão inicial como https?:\/\/\S+ pega a maioria dos casos. Para código de produção, prefira o construtor URL (new URL(string)) que lida com cada caso limítrofe; regex é melhor para extrações pontuais rápidas ou análise de logs.

Scraping de arquivos de log

Logs Apache e NGINX seguem um formato fixo. Cole algumas linhas de log, escreva uma regex com capturas nomeadas ((?\S+) (?\S+ \S+) "(?[^"]+)" ...), e você tem um analisador pronto para alimentar um analisador de logs estruturados. Teste em uma amostra de seus logs reais antes de implantar.

Buscar e substituir em editores de código

VSCode, Sublime Text, IDEs JetBrains e vim todos aceitam regex em seus diálogos de buscar-substituir. Itere o padrão aqui primeiro, com o destacador ao vivo mostrando exatamente o que corresponde, depois cole a regex no diálogo do editor. Poupe-se da dor de erros em uma base de código de 5.000 linhas.

Scraping web de nomes de classes CSS

Quando você precisa extrair dados de HTML sem um analisador (um script único, não para produção), uma regex como class="([^"]+)" extrai atributos de classe. Para qualquer coisa além de exploração rápida, mude para uma biblioteca DOM adequada; HTML não é uma linguagem regular e a regex perde casos limítrofes.

Validar strings de versão semântica

Semver segue ^\d+\.\d+\.\d+(-[\w.]+)?(\+[\w.]+)?$. Solte uma lista de versões (1.0.0, 1.2.3-beta.1+build.456) na área de teste para verificar se a regex pega corretamente metadados de pré-lançamento e build. Isso é útil ao validar dependências em scripts de CI.

Armadilhas comuns

Quantificadores gananciosos vs preguiçosos

Por padrão *, + e ? são gananciosos: eles correspondem tanto quanto possível, depois retrocedem se o resto da regex falhar. As versões preguiçosas *?, +?, ?? correspondem tão pouco quanto possível. O exemplo clássico é <.*> em texto que corresponde à string inteira, enquanto <.*?> corresponde apenas a e separadamente. Escolha o certo para evitar surpresas de super-correspondência.

Retrocesso catastrófico (ReDoS)

Quantificadores aninhados como (a+)+ ou (.*)* em uma longa entrada não-correspondente podem demorar tempo exponencial enquanto o motor tenta cada combinação. A aba do navegador pode congelar ou travar. Evite grupos de quantificadores sobrepostos, prefira grupos atômicos (?>...) onde suportados, ou pré-valide o comprimento da entrada. A biblioteca npm safe-regex sinaliza padrões arriscados automaticamente.

Caracteres especiais precisam de escape

Caracteres com significado especial em regex (. * + ? ^ $ ( ) [ ] { } | \) devem ser escapados com uma barra invertida para corresponder literalmente. Então \. corresponde a um ponto, enquanto . corresponde a qualquer caractere. Esquecer de escapar é a causa mais comum de falsos positivos ao validar IPs, extensões de arquivo, ou números de versão com pontos.

Âncoras e flag multilinha

Sem a flag m, ^ e $ correspondem apenas ao início e fim de toda a string. Com m, eles correspondem ao início e fim de cada linha. Se sua regex funciona em linhas únicas mas falha em entrada multilinha, alterne m. Inversamente, se corresponder demais em entrada multilinha, remova m.

Diferenças de sintaxe entre motores

Este testador usa regex JavaScript. O re do Python usa (?P) para capturas nomeadas em vez de (?), .NET permite retrocessos \k diferentemente, e PCRE tem recursos como sub-padrões recursivos (?R) que JavaScript não tem. Se seu alvo final é Python ou Java, valide nesses motores também antes de enviar.

Unicode sem a flag u

Sem a flag u, regex JavaScript trata pares substitutos (emoji, suplemento CJK) como duas unidades de código separadas. \u{1F600} (emoji rosto sorridente) não funciona sem u. Com a flag u, a regex se torna consciente de Unicode, escapes de propriedade como \p{Letter} se tornam disponíveis, e o tratamento de pares substitutos é correto. Sempre defina u ao corresponder texto internacional.

Privacidade e tratamento de dados

Toda regex é compilada e executada pelo motor RegExp do seu navegador. Não enviamos seu padrão, sua string de teste ou seu modelo de substituição para nenhum servidor. O matcher roda localmente, os destaques são renderizados localmente, e a lista de detalhes de correspondência é computada localmente. Não há análises vinculadas ao conteúdo de suas entradas.

Uma vez carregada a página, o testador funciona offline. Você pode desconectar da rede, colar linhas de log sensíveis ou PII, e executar padrões contra eles sem que nada saia do seu dispositivo. Isso torna a ferramenta segura para testar regex contra dados de produção sem enviá-los por um serviço de terceiros.

Quando não usar uma regex

Analisar HTML ou XML

HTML não é uma linguagem regular. Você não pode analisar de forma confiável tags aninhadas com regex; a famosa resposta do Stack Overflow sobre Zalgo e Cthulhu faz esse ponto coloridamente. Use DOMParser ou uma biblioteca como cheerio (Node.js) ou BeautifulSoup (Python) em vez disso. Regex está bem para extrações pontuais mas quebra em casos limítrofes como tags auto-fechantes, comentários, CDATA, e entrada malformada.

Qualquer coisa verdadeiramente recursiva (JSON, código-fonte, expressões matemáticas)

Chaves balanceadas, parênteses balanceados, chamadas de função aninhadas, precedência aritmética, todas requerem uma gramática livre de contexto, não uma regular. Use um combinador de parsers (Parsimmon, nom) ou um gerador (pegjs, antlr). Regex pode corresponder a tokens de abertura ou fechamento mas não pode rastrear balanceamento.

Quando uma operação de string simples é suficiente

Se você precisa verificar se uma string começa com prefix-, use str.startsWith("prefix-"), não /^prefix-/. Métodos de string são mais rápidos, mais claros, e impossíveis de errar com quantificadores. Reserve regex para padrões que métodos de string não podem expressar.

Validação de schema complexo

Validar que um documento JSON tem uma forma específica (campos obrigatórios, tipos aninhados, faixas de valores) é muito melhor feito com um validador JSON Schema (ajv, zod, joi) do que com uma regex. Regex pode verificar formato mas não estrutura, e uma regex que tenta validar um documento JSON é um pesadelo de manutenção.

Mais perguntas

Quando devo usar lookahead vs lookbehind?

Lookahead (?=...) afirma que o que segue corresponde sem consumi-lo; lookbehind (?<=...) faz o mesmo para o que precede. Use lookahead quando o contexto final determina se deve corresponder, lookbehind quando o contexto inicial determina. JavaScript suporta ambos desde 2018 (ES2018), e todos os navegadores modernos o fazem. Versões mais antigas do Safari antes de 16.4 careciam de suporte a lookbehind.

Lookbehind é suportado em todos os navegadores?

Lookbehind (positivo e negativo) é suportado no Chrome desde a versão 62 (2017), Firefox desde 78 (2020), Edge desde 79 (2020), e Safari desde 16.4 (2023). Se seu público pode usar Safari mais antigo, evite lookbehind ou faça polyfill com um padrão alternativo. Para Node.js, lookbehind tem sido suportado desde 10.0.

O que a flag Unicode (u) faz?

A flag u habilita o modo Unicode: pares substitutos são tratados como um único caractere, escapes \u{...} funcionam, e escapes de propriedade \p{...} se tornam disponíveis. Sem u, um emoji como rosto sorridente conta como duas unidades de código e . corresponde apenas à primeira metade. Sempre defina u ao trabalhar com texto além do ASCII.

Quão rápido é o motor de regex?

O motor RegExp do V8 usa uma implementação Irregexp que compila para código nativo. Para padrões simples ele corresponde a milhões de caracteres por segundo. Padrões patológicos (quantificadores aninhados em entrada adversarial) podem explodir para tempo exponencial, que é por isso que ReDoS é um vetor de ataque real. Motores modernos aplicam heurísticas para detectar e abortar correspondências descontroladas, mas você ainda deve evitar padrões arriscados.

Como regex JavaScript e Python diferem?

Grupos nomeados usam sintaxe diferente (? em JS, ?P em Python). Python carece da flag y (sticky); JavaScript carece do modo verbose do Python. Python suporta recursão via o módulo regex de terceiros mas não re embutido. Taquigrafia de classe de caractere difere ligeiramente (\d significa [0-9] em ambos, mas \w em Python inclui sublinhados em modo Unicode enquanto JS requer a flag u para o mesmo comportamento).

Posso usar IA para gerar regex em vez disso?

LLMs são bons em propor padrões regex iniciais mas rotineiramente produzem saída sutilmente errada (ganancioso onde preguiçoso era necessário, escapes faltando, flags erradas). Use IA para rascunhos iniciais, depois valide executando a regex contra amostras reais neste testador. Itere até que os destaques correspondam exatamente ao que você espera. O loop de feedback interativo pega os erros do LLM antes que cheguem à produção.

Ferramentas relacionadas