reconhecimento Regexp de endereço de email duro?
https://stackoverflow.com/questions/156430
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Recentemente, li em algum lugar que escrever um regexp para corresponder um endereço de e-mail, tendo em conta todas as variações e possibilidades do padrão é extremamente difícil e é significativamente mais complicado do que se poderia inicialmente assumir.
Alguém pode fornecer algumas informações a respeito de porque isso é?
Existem regexps conhecidos e comprovados que realmente fazer isso plenamente?
Quais são algumas boas alternativas ao uso de expressões regulares para correspondência de endereços de e-mail?
Solução
Para o formais especificação e-mail, sim, é tecnicamente impossível via Regex devido à recursividade de coisas como comentários (especialmente se você não remover os comentários de espaço em branco em primeiro lugar), ea vários formatos diferentes (um endereço de e-mail não é sempre someone@somewhere.tld). Você pode chegar perto (com alguns padrões enormes e incompreensíveis Regex), mas uma muito melhor maneira de verificar um e-mail é fazer o aperto de mão muito familiar:
- dizem-lhe o seu e-mail
- você enviar um e-mail um link confimation com um Guid
-
quando clicarem no link que você sabe que:
- o e-mail está correto
- existe
- que ele próprio
Muito melhor do que aceitar cegamente um endereço de e-mail.
Outras dicas
Há uma série de módulos Perl (por exemplo) que fazem isso. Não tente escrever a sua própria expressão regular para fazê-lo. Olhada
Mail::VRFY fará sintaxe e verificações de rede (faz e servidor SMTP algum lugar aceitar este endereço)
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address - um analisador recursiva descida endereço de e-mail
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address - baseada regexp validação de endereços, vale a pena olhar apenas para o regexp insano
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
existemferramentas similares para outros idiomas. regexp Insane abaixo ...
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
endereços de correio electrónico Validando não são realmente de qualquer maneira muito útil. Ele não vai pegar erros de digitação comuns ou endereços de email confeccionados, uma vez que estes tendem a olhar sintaticamente como endereços válidos.
Se você quer ter certeza de um endereço é válido, você não tem escolha a não ser enviar um email de confirmação.
Se você só quer ter certeza de que algo que o usuário entradas que se parece com um e-mail ao invés de apenas "asdf", em seguida, verificar se há um @. validação mais complexa realmente não fornecer qualquer benefício.
(Eu sei que este não responder às suas perguntas, mas acho que vale a pena mencionar qualquer maneira)
Eu já coligidos casos de teste de Cal Henderson, Dave Criança, Phil Haack, Doug Lovell e RFC 3696. 158 endereços de teste em todos.
Corri todos esses testes contra todos os validadores que eu poderia encontrar. A comparação é aqui: http://www.dominicsayers.com/isemail
Vou tentar manter esta página up-to-date como as pessoas a melhorar suas validadores. Graças a Cal, Dave e Phil pela sua ajuda e cooperação na elaboração destes testes e críticas construtivas de meu próprio validador .
As pessoas devem estar cientes da errata contra RFC 3696 em particular . Três dos exemplos canônicos estão em endereços inválidos fatos. E o comprimento máximo de um endereço é 254 ou 256 caracteres, não 320.
Não é tudo um absurdo embora como permitindo que personagens como '+' pode ser muito útil para os usuários o combate ao spam, por exemplo, myemail+sketchysite@gmail.com ( instantâneas endereços do Gmail descartáveis ??)
Somente quando um site aceita-lo embora.
Há uma gramática livre de contexto em BNF que descreve endereços de email válidos em RFC-2822 . É complexo. Por exemplo:
" @ "@example.com
é um endereço de email válido. Eu não sei de nenhum regexps que fazê-lo totalmente; os exemplos geralmente dadas requerem observações a ser desmontado primeiro. Eu escrevi um analisador descendente recursivo para fazê-lo completamente uma vez.
Se deve ou não aceitar formatos bizarros, incomuns endereço de e-mail depende, em minha opinião, no que se quer fazer com eles.
Se você estiver escrevendo um servidor de email, você tem que ser muito exata e dolorosamente correto no que você aceitar. A regex "insano" citado acima, portanto, adequado.
Para o resto de nós, porém, estamos principalmente apenas interessados ??em garantir que algo um usuário digita em um formulário web parece razoável e não ter algum tipo de injeção de SQL ou estouro de buffer na mesma.
Francamente, será que alguém realmente se importa em deixar alguém digitar um endereço de e-mail 200 caracteres com comentários, novas linhas, citações, espaços, parênteses ou outro jargão quando se inscrever para uma lista de discussão, newsletter, ou web site? A resposta adequada a esses palhaços é "voltar mais tarde quando você tem um endereço que parece username@domain.tld".
A validação eu faço consiste em garantir que há exatamente um '@'; que não há espaços, nulos ou novas linhas; que a parte à direita do '@' tem pelo menos um ponto (mas não dois pontos em uma linha); e que não há citações, parênteses, vírgulas, dois pontos, exclamações, ponto e vírgula, ou barras invertidas, os quais são mais propensos a ser tentativas de hackery do que partes de um endereço de e-mail real.
Sim, isso significa que eu estou rejeitando endereços válidos com que alguém poderia tentar registrar em meus sites - talvez eu "incorretamente" rejeitar como muitos como 0,001% dos endereços do mundo real! Eu posso viver com isso.
Citando e várias outras partes raramente usados, mas válidas do RFC tornar difícil. Eu não sei o suficiente sobre este tema ao comentário definitivamente, diferente de "é difícil" - mas, felizmente, noreferrer outros pessoas têm escrita sobre isso longamente.
Como a um regex válido para ele, o Perl Mail :: Rfc822 :: módulo Endereço contém uma expressão regular que aparentemente vai trabalhar - mas só se todos os comentários foram substituídas por espaços em branco já. (Comentários em um endereço de e-mail? Você ver porque é mais difícil do que se poderia esperar ...)
É claro, as expressões regulares simplificadas que abundam em outros lugares irá validar quase todos os endereços de e-mail que está realmente sendo usado ...
Alguns sabores de regex pode realmente corresponder colchetes aninhados (por exemplo, Perl aqueles compatíveis). Dito isto, eu vi um regex que as reivindicações para corresponder corretamente RFC 822 e foi duas páginas de texto sem qualquer espaço em branco. Portanto, a melhor maneira de detectar um endereço de email válido é enviar e-mail para ele e ver se funciona.
Apenas para adicionar um regex que é menos louco do que o listado por @mmaibaum:
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
Não é à prova de balas e, certamente, não cobre toda a especificação e-mail, mas faz um trabalho digno de cobrir a maioria dos requisitos básicos. Ainda melhor, é um pouco compreensível, e podem ser editados.
plagiou uma discussão em HouseOfFusion.com , um recurso de classe mundial ColdFusion.
Um fácil e boa maneira de verificar e-mail-endereços em Java é usar o EmailValidator do Apache Commons Validator biblioteca .
Eu sempre verificar um endereço de email em uma forma de entrada contra algo como isto antes de enviar um e-mail - mesmo se você só pegar alguns erros de digitação. Você provavelmente não quer escrever um scanner automatizado para "falha na entrega" mails de notificação. : -)
É muito difícil porque há um monte de coisas que podem ser válidos em um endereço de e-mail de acordo com o E-mail Spec, RFC 2822 . Coisas que você não vê normalmente tais como + são perfeitamente caracteres válidos para um endereço de e-mail .. de acordo com a especificação.
Há uma seção inteira dedicada aos endereços de e-mail em http://regexlib.com , que é um grande recurso. Eu sugiro que você determinar quais os critérios que importa para você e encontrar um que partidas. A maioria das pessoas realmente não precisa de suporte completo para todas as possibilidades permitidas pela especificação.
Se você está em execução no .NET Framework, apenas tentar instanciar um objeto MailAddress e pegar o FormatException se ele explode, ou puxando a Address se for bem sucedido. Sem entrar em qualquer bobagem sobre o desempenho de captura exceções (realmente, se este é apenas em um único formulário Web não vai fazer muita diferença), a classe MailAddress no framework .NET passa por uma análise bastante completa processo (que não usa um RegEx). Abra reflector e procurar MailAddress e MailBnfHelper.ReadMailAddress() para ver todas as coisas extravagantes que faz. Alguém mais esperto do que eu passei muito tempo a construir esse analisador na Microsoft, eu vou usá-lo quando eu realmente enviar um e-mail para esse endereço, então eu poderia muito bem usá-lo para validar o endereço de entrada também.
Muitos tentaram, e muitos vêm perto. Você pode querer ler o artigo wikipedia , e alguns outros .
Especificamente, você vai querer se lembrar que muitos sites e servidores de e-mail têm de validação descontraído de endereços de e-mail, de modo essencialmente eles não implementar totalmente o padrão. É bom o suficiente para e-mail para trabalhar o tempo todo embora.
Tente esta:
"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"
Tenha um olhar aqui para os detalhes.
No entanto, em vez de implementar o padrão RFC822, talvez seria melhor olhar para ele a partir de outro ponto de vista. Realmente não importa o que a norma diz que se os servidores de correio não espelhar o padrão. Então, eu diria que seria melhor para imitar o que os servidores mais populares de correio fazer ao validar endereços de email.
Esta classe de Java tem um validador nele: http://www.leshazlewood.com/?p=23
Esta é escrito pelo criador do Shiro (formalmente Ki, formalmente JSecurity)
Os prós e contras de testar para o e-mail validade endereço:
Existem dois tipos de expressões regulares que validam e-mails:
- aqueles que são muito solto.
-
aqueles que são muito rigorosos.
Não é possível para uma expressão regular para corresponder a todos os endereços de e-mail válido e nenhum endereço de e-mail que não são válidas porque algumas cordas pode parecer endereços de email válidos, mas não realmente ir para a caixa de entrada de ninguém. A única maneira de teste para ver se um e-mail é realmente válida é enviar um e-mail para o endereço de e veja se você obter algum tipo de resposta. Com isso em mente, expressões regulares que são demasiado rigorosa a correspondência e-mails realmente não parecem ter muito de um propósito.
Eu acho que a maioria das pessoas que pedem um e-mail regex está procurando a primeira opção, expressões regulares que são muito solto. Eles querem testar uma string e ver se ele se parece com um e-mail, se não é, definitivamente, um e-mail, então eles podem dizer para o usuário: "Ei, você tem que colocar um e-mail aqui e este é definitivamente não um endereço de e-mail. talvez você não percebeu que este campo é para um e-mail ou talvez há um erro de digitação".
Se um usuário coloca em uma string que se parece muito com um e-mail válido, mas na verdade não é um, então isso é um problema que deve ser tratado por uma parte diferente da aplicação.
Alguém pode fornecer algumas informações a respeito de porque isso é?
Sim, é um padrão extremamente complicado que permite que um monte de coisas que ninguém usa realmente hoje. :)
Existem regexps conhecidos e comprovados que realmente fazer isso plenamente?
Aqui é uma tentativa de analisar todo o padrão totalmente ...
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
Quais são algumas boas alternativas ao uso de expressões regulares para correspondência de endereços de e-mail?
Usando um quadro existente para ele em qualquer linguagem que você está usando eu acho? Embora aqueles provavelmente usará regexp internamente. É uma cadeia complexa. Regexps são projetados para analisar strings complexas, de modo que realmente é sua melhor escolha.
Editar : Gostaria de acrescentar que o regexp I ligada à era apenas por diversão. Eu não endossa usando uma expressão regular complexa como essa - algumas pessoas dizem que "se a sua expressão regular é mais do que uma linha, é a garantia de ter um bug em algum lugar". I ligado a ela para ilustrar o quão complexo o padrão é.
Adicionando a resposta Wayne s, há também uma seção sobre www.regular-expressions.info dedicada ao e-mail, com algumas amostras.
Você pode sempre questão de saber se vale a pena ou se, de fato, qualquer menos do que-100% regexp -covering contribui apenas para uma falsa sensação de segurança.
No final, realmente enviar o e-mail é o que irá fornecer a validação final real. (-Você vai descobrir se o seu servidor de correio tem bugs; -)
Para a integralidade deste post, também para PHP não é uma linguagem de built-in função para validar e-mails.
Para PHP Use o bom filter_var com o tipo de validação de email específico:)
expressões regulares de e-mail Não mais insanas em php: D
var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));
