Biblioteca de padrões Regex

Sobre esta biblioteca

É uma coleção organizada e pesquisável de mais de 60 padrões de expressão regular comumente usados, agrupados por categoria. Cada padrão inclui uma descrição, a expressão em si e exemplos de correspondências. Clique em um padrão para copiá-lo, ou use o painel de teste rápido para validar um texto contra ele diretamente nesta página.

Tudo é executado no seu navegador · nenhum padrão ou texto de teste é enviado a lugar nenhum. Use estes padrões em JavaScript, Python, PHP, Java, Go ou qualquer linguagem que suporte expressões regulares. Para testes mais avançados com flags e grupos de captura, experimente nosso Testador e depurador de Regex.

De onde vêm as expressões regulares

A ideia matemática de «conjunto regular» foi formalizada por Stephen Cole Kleene em 1951 no memorando de pesquisa da RAND Representation of Events in Nerve Nets and Finite Automata. O operador * nesta página ainda é chamado estrela de Kleene em sua homenagem. Ken Thompson transformou a teoria em algoritmo em seu artigo de junho de 1968 na Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, e entregou a primeira implementação de regex no editor QED na Bell Labs. Em 1973, o mesmo motor alimentava ed, depois grep (a expansão literal é «globally search for regular expression and print»), sed e awk. O Perl (1987) de Larry Wall e especialmente o Perl 5 (1994) adicionaram grupos nomeados, lookaround, quantificadores não-gananciosos e manipulação Unicode que se tornaram o dialeto de facto conhecido como PCRE, portado para C como biblioteca por Philip Hazel em 1997.

Variantes de motor e o que muda entre elas

Um padrão que roda limpamente em JavaScript pode falhar silenciosamente em Go e ser rejeitado totalmente em POSIX. As cinco variantes que um desenvolvedor provavelmente encontrará:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): o dialeto de grep, sed e awk em um Unix padrão. Sem lookaround, sem grupos nomeados, sem escapes de propriedade Unicode. BRE adicionalmente exige escapar (, ), {, } e |.
• PCRE2 (Philip Hazel, 1997, versão maior atual 10.x): o dialeto mais completo em recursos. Lookaround, grupos nomeados (?<name>...), grupos atômicos, quantificadores possessivos, recursão. Usado pelo PHP preg_*, Apache, nginx, R.
• Regex ECMAScript (ECMA-262, seção regex 22.2): o dialeto JavaScript. ES2018 adicionou grupos nomeados, lookbehind e os flags s (dotAll) e u (Unicode). ES2022 adicionou o flag d para índices de correspondência. ES2024 adicionou o flag v com classes de notação de conjunto.
• Python re: próximo de PCRE, mas usa (?P<name>...) para grupos nomeados (PEP 433) e um modo verboso diferente re.X. O módulo de terceiros mais novo regex adiciona padrões recursivos e semântica POSIX de correspondência mais longa.
• RE2 (Russ Cox, 2010): o motor por trás do regexp de Go e da crate regex de Rust. Sem lookaround, sem retrorreferências, sem quantificadores possessivos, propositalmente. O trade-off: tempo linear garantido, sem retrocesso catastrófico. Se um padrão desta biblioteca usar (?=...) ou \1, ele não compilará em Go.

Retrocesso catastrófico e ReDoS

A maioria dos motores regex em linguagens principais (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) são motores de retrocesso. Quando um padrão com quantificadores aninhados como (a+)+ encontra uma entrada que quase coincide, o motor pode tentar um número exponencial de caminhos alternativos antes de desistir. Isso é retrocesso catastrófico, e é a base da classe de ataque ReDoS (Regular expression Denial of Service) catalogada pela OWASP.

Stack Overflow, 20 de julho de 2016: um padrão projetado para aparar espaços em branco no início e fim, aplicado a um corpo de pergunta contendo 20 000 caracteres de espaço consecutivos, levou 11 minutos de CPU por requisição e deixou o site inacessível por 34 minutos. O post-mortem no blog oficial Stack Status recomendou substituir as regex de aparamento pelo trim nativo de string.

Cloudflare, 2 de julho de 2019: uma regra WAF contendo o padrão de quantificador aninhado .*(?:.*=.*) foi implantada globalmente e consumiu 100% da CPU em cada servidor edge por 27 minutos, deixando offline grandes porções da internet pública. O post-mortem da Cloudflare em seu blog creditou a mudança para a crate regex de Rust (um motor baseado em RE2, tempo linear) por evitar a recorrência.

As lições defensivas: evitar quantificadores aninhados ((a+)+, (a*)*, (a|aa)+); evitar aparamentos estilo \s+$ em entradas controladas pelo atacante; preferir grupos atômicos (?>...) ou quantificadores possessivos a++ em PCRE; e para serviços de alto rendimento, considerar um motor baseado em RE2.

Email, URL, telefone, data, cartão de crédito: quando não usar regex

Email. A gramática completa da RFC 5322 (outubro de 2008) se compila em uma regex de aproximadamente 3 000 caracteres. A especificação HTML5 do W3C para validação de <input type="email"> usa uma regex muito mais curta «isso-parece-um-email» que é o ponto de partida certo para indicações do lado cliente. RFC 6531 (fevereiro de 2012) permite endereços não-ASCII como 用户@example.com, que uma regex apenas ASCII rejeitará incorretamente. O consenso da indústria desde a RFC 6532: não valide emails com regex, envie um email de verificação em vez disso.

URL. A RFC 3986 (janeiro de 2005) é a spec de sintaxe genérica de URI, mas o WHATWG URL Living Standard diverge deliberadamente dela para coincidir com o que os navegadores realmente aceitam. Use new URL("...") em JavaScript ou urllib.parse em Python em vez de uma regex para qualquer coisa além de uma verificação visual rápida.

Números de telefone. A Recomendação E.164 da UIT-T (revisão atual novembro de 2010) permite até 15 dígitos com um prefixo + opcional, mas as regras específicas de país variam enormemente. A biblioteca de código aberto do Google libphonenumber codifica as regras por país para cada território e é o único validador confiável entre países.

Datas. Uma regex como ^\d{4}-\d{2}-\d{2}$ corresponde ao formato de calendário ISO 8601-1:2019, mas também aceita 2026-02-31. A validade de data requer lógica de calendário, não correspondência de padrão; use Date.parse() ou uma biblioteca de datas.

Cartões de crédito. Uma regex pode corresponder ao comprimento dos dígitos e ao prefixo IIN (Visa começa com 4, Mastercard com 51-55 ou 2221-2720, Amex com 34 ou 37) mas não pode verificar a soma de verificação Luhn (Hans Peter Luhn, IBM, patente EUA 2 950 048 concedida em agosto de 1960). Luhn requer uma soma dígito por dígito módulo 10.

Maneiras comuns que os desenvolvedores usam esta biblioteca

• Indicações de formulário do lado cliente, com o entendimento de que um acerto de regex é uma indicação, não uma validação final.
• Extração de logs, puxando timestamps, IPs, códigos de erro e URLs dos logs de aplicação para um pipeline.
• Limpeza de dados pontual: normalizar espaços, remover tags HTML, converter entre formatos de data, slugificar títulos.
• Localizar-substituir no editor no VS Code, Sublime, vim, IntelliJ onde a variante regex é próxima de PCRE.
• Padrões de correspondência de router e URL em Express, Flask, FastAPI, Rails.
• Regras de WAF e detecção de intrusão, com extremo cuidado com ReDoS como o incidente da Cloudflare em 2019 demonstrou.
• Teste rápido de string no painel de teste no rodapé da página, antes de comprometer o padrão ao código.

Erros comuns

• Esquecer as âncoras. Sem ^ e $ (ou \A e \z em PCRE), uma regex de validação corresponde se o padrão aparecer em qualquer lugar da string. /\d{4}/ corresponde a «year 2026 was good», que quase nunca é o que se quer.
• Confiar em .* através de várias coisas. <a href=".*"> sobre a entrada <a href="a"><a href="b"> captura através de ambas as tags porque .* é ganancioso. Use .*? para preguiçoso, ou melhor, parse com um parser real.
• Supor que o ponto corresponde a quebras de linha. Por padrão . corresponde a tudo exceto terminadores de linha. Use o flag s (dotAll) em JS, ou re.DOTALL em Python, ou o modificador inline (?s) em PCRE.
• Supor que \w inclui letras não-ASCII. Em modo ASCII, \w é [a-zA-Z0-9_]. Adicione o flag u em JS (ES2018+) e use \p{L} para qualquer letra Unicode; em Python adicione re.UNICODE (padrão em Python 3).
• Retrorreferências em Go. O regexp de Go é RE2 e rejeita \1 em tempo de compilação. O erro «error parsing regexp: invalid escape sequence: \1» significa que o padrão precisa ser dividido em uma abordagem não regex.
• Fazer parse de HTML com regex. Notoriamente inviável: HTML não é uma linguagem regular. Use um parser DOM (o DOMParser integrado do navegador, cheerio, BeautifulSoup, lxml).

Mais perguntas frequentes

Por que alguns padrões usam (?:...) em vez de (...)?

(?:...) é um grupo não capturante: agrupa para repetição ou alternância mas não aloca um slot de retrorreferência. É mais rápido e evita poluir $1, $2 no array de resultados. Use (...) quando precisar extrair o texto capturado; use (?:...) apenas para agrupar.

Quais são os flags regex mais comuns?

i insensível a maiúsculas, g global (encontrar todos, comportamento específico JS), m multilinha (para que ^ e $ correspondam a limites de linha), s dotAll (para que . corresponda a quebras de linha, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v classes de notação de conjunto (ES2024+). Combine como /pattern/gimsu.

Como faço correspondência com um caractere especial literal?

Escape-o com uma barra invertida. Os metacaracteres regex que precisam de escape para correspondência literal são: . ^ $ * + ? ( ) [ ] { } | \ /. Dentro de uma classe de caracteres [...] o conjunto de caracteres especiais é menor: apenas ] \ ^ - precisam de escape, dependendo da posição.

Posso usar os padrões desta biblioteca em scripts shell?

Sim, com ressalvas. grep usa POSIX BRE por padrão; grep -E usa ERE; grep -P usa PCRE em sistemas onde libpcre está ligada (GNU grep, macOS grep com Homebrew). Padrões usando lookaround, grupos nomeados ou escapes Unicode requerem grep -P ou ripgrep (que usa o motor RE2-based de Rust e rejeita lookaround).

Esses padrões são enviados a um servidor?

Não. Cada regex desta página, cada busca que você digita e cada string que testa no painel de teste rápido é processada no motor JavaScript do seu navegador. Nenhuma chamada de rede é feita. Os próprios dados de padrão são entregues como um arquivo JSON estático no bundle da página. Abra a aba Rede no DevTools para verificar.