Padrão Regex de Email

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 alfanuméricos 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

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 mesma caixa de entrada que user@gmail.com, e muitos usuários confiam nisso 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 validar, 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])?)*$/

Isso 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 validaçã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 usuário 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 básica 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 tratado o endereço como verificado quando o usuário clicar no link.

Isso 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 Prática

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 validaçã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 mesmo formulario, o Codificador de URL pode ajudar a codificar com segurança os parametros de string de consulta que incluem endereços de email.