Angular.js: validador de email está errado

Sim, você está certo, parece que EMAIL_REGEX está errado.

De acordo com http://dev.w3.org/html5/markup/input.email.html , podemos usar

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

e parece que deve funcionar melhor por não incluir o . após o @

Vou tentar enviar um patch rápido para isso.

... na verdade, isso é um pouco mais complicado do que eu pensei que seria, isso pode dar um pouco mais de trabalho. Parece que também aceitará expressões regulares que começam com um ponto. Portanto, há um pouco de trabalho a fazer aqui, eu acho.

Se você puder resolver isso antes de mim, sinta-se à vontade para enviar uma solicitação de pull

Obrigado pelo relatório do bug. Na demonstração do docs, você não notará essa correção até o 1.2.10 cair, porque ele carrega o script angular 1.2.9 o tempo todo. Mas em alguns dias você deverá ver isso resolvido na demonstração do documento (a menos que o commit seja revertido, o que pode acontecer O_O)

Ótimo, 10x!

Na quarta-feira, 22 de janeiro de 2014 às 5h32, Caitlin Potter [email protected] :

Obrigado pelo relatório do bug. Na demonstração de documentos, você não notará essa correção
até 1.2.10 cai, porque carrega o script do angular 1.2.9 o tempo todo.
Mas em alguns dias você verá isso abordado na demonstração do documento

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

Qual era a minha expressão facial quando percebi que " dummy @ ferferfe " (sem nenhum domínio) é considerado um e-mail válido;)

@ mica16 mas dummy@ferferfe é um endereço de e-mail válido. Os domínios não precisam ter uma extensão, pense apenas em localhost .

@Zequez correto, mas quem diabos usa um endereço de host local para o registro de um site, por exemplo?

@mbeckenbach Use
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
Não é ideal, mas funciona.

@mbeckenbach sim, é verdade. Mas considere que um nome de domínio sem pontos é um domínio válido. O fato de ICANN não permitir que você registre um domínio com ELES não significa que o nome do domínio seja inválido.

6 @ 6 não é um endereço de e-mail. O fato de que poderia ser um endereço de e-mail adequado em uma circunstância especial não deveria, em minha opinião, nos levar a permiti-lo. As chances de um erro passar por esse padrão permissivo são ordens de magnitude maiores do que as chances de excluirmos alguém com esse endereço de e-mail.

+1 para Jeff

@jeffmcmahan Sinto muito, mas parece que você deve registrar um problema com o IETF ou o WHATWG. Uma vez que a definição da aparência de um endereço de e-mail muda, ele deve ser alterado no Angular, mas realmente precisamos seguir o que está descrito nas recomendações de RFCs e WHATWG.

Agora, se você quiser ser um pouco mais rígido, também pode adicionar um validador de padrão, isso seria ótimo.

@caitp Você é o chefe.

Que tal tornar o EMAIL_REGEXP configurável? Nossa validação do lado do servidor é mais rigorosa do que a do angularjs. Especificamente, ele requer, por exemplo, que a parte antes do sinal @ não tenha mais do que 63 caracteres. Agora temos que criar uma diretiva personalizada para todas as entradas de email ou lembrar de adicionar o padrão ng a cada entrada de email.

você pode usar o ng-pattern além de type = email, @rjokelai - além disso, a alteração do pipeline de validação de @matsko tornará mais fácil adicionar validação de email personalizada

"Agora, se você quiser ser um pouco mais rígido, também pode adicionar um validador de padrão, isso seria ótimo."

que tal o validador padrão aceitar apenas e-mails normais com um ponto, e se alguém em uma pequena minoria quiser ser menos estrito, ele pode fazer seu próprio validador. Por que a grande maioria dos desenvolvedores precisa criar seu próprio padrão apenas para que a pequena minoria não o faça? Isso é purismo de padrões bobo

porque este é basicamente um polyfill para validação de restrição html5, é por isso. Na próxima semana, esperamos enviar um recurso que tornará a personalização muito mais fácil

Os emails sem zona de domínio são válidos? Estou testando um campo de entrada simples com type = "email" e o Angular valida _foo @ bar_ email com sucesso. (Angular v1.3.0)

Oh, já existe um problema encerrado - https://github.com/angular/angular.js/issues/9463

Os emails sem zona de domínio são válidos? Estou testando um campo de entrada simples com type = "email" e o Angular valida o email foo @ bar com sucesso. (Angular v1.3.0)

Eles são emails válidos, por especificação. Esta pergunta foi respondida tantas vezes neste rastreador de problemas que não há nada de inválido em um e-mail sem um TLD.

Use um validador personalizado para exigir os TLDs específicos que você deseja

@caitp , sei que estamos discutindo com você sobre isso, mas acho que poderia ser útil se você explicasse por que manter as especificações é fundamental. Todos nós reconhecemos que um desenvolvedor razoável e competente não presumirá que o validador de e-mail permite _0 @ 0_. Ou seja, ele será usado para a situação de registro de formulário padrão e causará problemas em muitas dessas situações. E somos informados de que a importância de manter as especificações supera esses problemas. OK fixe. Mas por que?

Porque vai ser muito estranho quando o seu navegador diz que é válido e angular diz que não é

Você não está procurando a validação de e-mail, você está procurando a validação de padrão além da validação de e-mail --- você quer endereços de e-mail válidos (gerenciados pelo angular) que correspondem a um padrão específico (contém um TLD)

1. Seria estranho quando você adicionasse validação de padrão e "seu navegador dissesse que é válido e [A] ngular dissesse que não"? Não. Então, por que seria estranho se essa validação de padrão fosse incorporada?
2. Estamos todos cientes de que o que passa por um e-mail válido no caso de uso no qual estamos interessados ​​é mais restrito do que a especificação.

_Eu só quero saber por que o Angular não deve servir ao caso de uso no qual estou interessado, já que é o caso geral._

Então, por que seria estranho se essa validação de padrão fosse incorporada?

Na verdade, você obtém o mesmo comportamento do navegador. http://jsfiddle.net/t6rdmngo/ Se você executar isso em um navegador moderno, não poderá enviar o formulário principal devido a uma incompatibilidade de padrão se não incluir um TLD.

Na versão angular, você obtém o mesmo comportamento. Isso é bom. Isto é o que queremos. Comportamento idêntico entre o comportamento nativo e o comportamento do framework. O framework não deve ter divergências com a plataforma

Agora eu entendi. Obrigado por me aturar!

Você pode corrigir isso rapidamente usando ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Se você alterar o último * para + no regex, ele funcionará conforme o esperado

http://w3c.github.io/html-reference/input.email.html

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