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
| Segmento | Padrão | O 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:
- Aplique uma verificação basica de formato (regex ou
type="email") para capturar erros de digitação obvios. - Envie um email de confirmação com um token de tempo limitado.
- 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.