Regex Tester

Padrão Regex de Email: Validação de Endereços de Email

Padrão regex para válidação de email com casos de teste. Abrange conformidade com RFC 5322, erros comuns é por que o regex só não e suficiente.

100% no navegador. Seus dados nunca saem do seu computador.

//gm
4 correspondências
user@example.com alice.chen@company.co.uk bob+tag@gmail.com invalid@ @missing-local.com no-at-sign.com user@.com test@sub.domain.example.org
Detalhes da Correspondência

Ferramentas Relacionadas

Padrão Regex de Email

O padrão acima corresponde a grande maioria dos endereços de email do mundo real. Ele exige uma parte local não vazia usando caracteres alfanumericos e ._%+-, depois um @, depois um domınio com pelo menos um ponto, depois um TLD de duas ou mais letras. Linhas que correspondem: user@example.com, alice.chen@company.co.uk, bob+tag@gmail.com. Linhas que não correspondem: invalid@, @missing-local.com, no-at-sign.com, user@.com.

Detalhamento do Padrão

SegmentoPadrãoO que corresponde
Ancora de inıcio^Inıcio de cada linha (com flag m)
Parte local[a-zA-Z0-9._%+\-]+Letras, dıgitos e ._%+- — um ou mais
Arroba@@ literal
Rotulos de domınio[a-zA-Z0-9.\-]+Nome de domınio, permitindo pontos e hıfens
Ponto antes do TLD\.Ponto literal
TLD[a-zA-Z]{2,}Duas ou mais letras (cobre .io, .museum, .co.uk segundo rótulo)
Ancora de fim$Final de cada linha (com flag m)

Erros Comuns em Regex de Email

Não permitir + na parte local é o problema mais frequente. Gmail e muitos outros provedores direcionam user+tag@gmail.com para a mêsma caixa de entrada que user@gmail.com, e muitos usuarios confiam nissó para filtragem. Um padrão como [a-zA-Z0-9._%-]+ rejeita silenciosamente esses endereços.

Não permitir TLDs de varios nıveis é o segundo erro mais comum. Um padrão terminado em \.[a-zA-Z]{2,3} rejeita alice@company.co.uk porque ve .co como o TLD.

Não ancorar o padrão com ^ e $ significa que uma string como isto não é um email mas contem um@example.com correspondera ao fragmento incorporado. Ao válidar, sempre ancore a string ou linha completa.

O Padrão de Email HTML5

Os navegadores aplicam seu proprio padrão a <input type="email">. O padrão real usado pela especificação HTML5 e:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Issó permite caracteres como !#$%&'* na parte local, que são válidos segundo RFC 5321 mas quase nunca vistos na prática. Usar type="email" fornece esta válidação gratuitamente em navegadores compatıveis.

O que o Regex Não Pode Dizer

Um regex pode confirmar que o endereço parece um email. Não pode dizer se o domınio tem registros MX funcionais, se a caixa de entrada existe ou se o usuario controla o endereço. A abordagem padrão para qualquer fluxo que dependa de um endereço de email real e:

  1. Aplique uma verificação basica de formato (regex ou type="email") para capturar erros de digitação obvios.
  2. Envie um email de confirmação com um token de tempo limitado.
  3. So traté o endereço como verificado quando o usuario clicar no link.

Issó cobre os casos que o regex perde completamente, incluindo domınios digitados errado (gmial.com) e endereços que parecem válidos mas pertencem a outra pessoa.

Recomendação Pratica

Para a maioria dos aplicativos, use o padrão nesta página (ou o type="email" do HTML5) para capturar erros obvios de entrada, depois verifique a propriedade com um email de confirmação. Recorra a uma biblioteca de válidação apenas se precisar lidar com endereços internacionais, analisar cabeçalhos de email brutos ou aplicar regras mais rigorosas que o padrão padrão oferece.

Se você trabalha com URLs como parte do mêsmo formulario, o Codificador de URL pode ajudar a codificar com segurança os parametros de string de consulta que incluem endereços de email.