Angular.js: le validateur d'e-mail est faux

Oui, vous avez raison, il semble que EMAIL_REGEX a tort.

Selon http://dev.w3.org/html5/markup/input.email.html , nous pouvons utiliser

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

et il semble que cela devrait mieux fonctionner car il ne faut pas inclure le . après le @

Je vais essayer de soumettre un patch rapide pour cela.

... en fait, c'est un peu plus compliqué que je ne le pensais, cela pourrait demander un peu plus de travail. Il semble qu'il accepte également les expressions rationnelles qui commencent également par un point. Il y a donc un peu de travail à faire ici, je suppose.

Si vous pouvez résoudre ce problème avant moi, n'hésitez pas à soumettre une demande de tirage

Merci pour le rapport de bogue. Sur la démo de la documentation, vous ne remarquerez pas ce correctif tant que la version 1.2.10 ne sera pas supprimée, car elle charge le script angulaire 1.2.9 tout le temps. Mais dans quelques jours, vous devriez voir cela abordé dans la démo de doc (à moins que le commit ne soit annulé, ce qui pourrait arriver O_O)

Génial, 10x!

Le mercredi 22 janvier 2014 à 5 h 32, Caitlin Potter [email protected] a écrit :

Merci pour le rapport de bogue. Sur la démo de la documentation, vous ne remarquerez pas ce correctif
jusqu'à ce que 1.2.10 tombe, car il charge le script angulaire 1.2.9 tout le temps.
Mais dans quelques jours, vous devriez voir cela abordé sur la démo de doc

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

Quelle a été mon expression faciale lorsque j'ai remarqué que " dummy @ ferferfe " (sans aucun domaine) est considéré comme un e-mail valide;)

@ mica16 mais dummy@ferferfe est une adresse e-mail valide. Les domaines n'ont pas besoin d'avoir une extension, pensez simplement à localhost .

@Zequez correct, mais qui diable utilise une adresse d'hôte local pour l'enregistrement d'un site Web par exemple?

@mbeckenbach Utilisation
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
Pas idéal mais fonctionne.

@mbeckenbach ouais, c'est vrai. Mais considérez qu'un nom de domaine sans points est un domaine valide. Le fait que l'ICANN ne vous laisse pas enregistrer un domaine avec eux ne signifie pas que le nom de domaine est invalide.

6 @ 6 n'est pas une adresse e-mail. Le fait qu'il puisse s'agir d'une adresse e-mail appropriée dans une circonstance particulière ne devrait pas, à mon avis, nous conduire à le permettre. Les chances d'une erreur de passer via ce modèle permissif sont des ordres de grandeur plus élevés que les chances d'exclure quelqu'un avec une telle adresse e-mail.

+1 pour Jeff

@jeffmcmahan Je suis désolé mais il semble que vous devriez

Maintenant, si vous voulez être un peu plus strict, vous pouvez également ajouter un validateur de modèle, ce serait très bien.

@caitp Vous êtes le patron.

Que diriez-vous de rendre EMAIL_REGEXP configurable? Notre validation côté serveur est plus stricte que celle angularjs. Plus précisément, il exige, par exemple, que la partie précédant le signe @ ne dépasse pas 63 caractères. Nous devons maintenant créer une directive personnalisée pour toutes les entrées d'e-mail ou n'oubliez pas d'ajouter le ng-pattern à chaque entrée d'e-mail.

vous pouvez utiliser ng-pattern en plus de type = email, @rjokelai - aussi, la modification du pipeline de validation de

"Maintenant, si vous voulez être un peu plus strict, vous pouvez également ajouter un validateur de modèle, ce serait très bien."

Que diriez-vous du validateur par défaut n'accepte que les e-mails normaux avec un point, et si quelqu'un dans la petite minorité veut être moins strict, il peut créer son propre validateur. Pourquoi la grande majorité des développeurs devrait-elle avoir besoin de créer son propre modèle pour que la petite minorité ne soit pas obligée de le faire? C'est le purisme des normes idiotes

car il s'agit essentiellement d'un polyfill pour la validation des contraintes html5, c'est pourquoi. Nous espérons que la semaine prochaine, nous publierons une fonctionnalité qui facilitera grandement la personnalisation.

Les e-mails sans zone de domaine sont-ils valides? Je teste un champ de saisie simple avec type = "email" et Angular valide _foo @ bar_ email avec succès. (Angulaire v1.3.0)

Oh, il y a déjà un problème fermé - https://github.com/angular/angular.js/issues/9463

Les e-mails sans zone de domaine sont-ils valides? Je teste un champ de saisie simple avec type = "email" et Angular valide avec succès l'email foo @ bar . (Angulaire v1.3.0)

Ce sont des e-mails valides, selon les spécifications. Cette question a reçu une réponse tant de fois sur ce suivi des problèmes, il n'y a rien d'invalide dans un e-mail sans TLD.

Utilisez un validateur personnalisé pour exiger les TLD spécifiques que vous souhaitez

@caitp , je me rends compte que nous vous avons harcelé à ce sujet, mais je pense que cela pourrait être utile si vous expliquiez pourquoi il est impératif de respecter les spécifications. Nous reconnaissons tous qu'un développeur raisonnable et compétent ne supposera pas que le validateur d'e-mail autorise _0 @ 0_. C'est-à-dire que cela va être utilisé pour la situation d'enregistrement du formulaire standard, et cela va causer des problèmes dans de nombreuses situations de ce genre. Et on nous dit que l'importance de respecter les spécifications l'emporte sur ces problèmes. D'accord --- cool. Mais pourquoi?

Parce que ça va être vraiment bizarre quand votre navigateur dit qu'il est valide et angulaire dit que ce n'est pas le cas

Vous ne recherchez pas une validation par e-mail, vous recherchez une validation de modèle en plus de la validation par e-mail --- vous voulez des adresses e-mail valides (gérées par angulaire) qui correspondent à un modèle spécifique (contient un TLD)

1. Serait-ce bizarre lorsque vous ajoutez une validation de modèle et ensuite "votre navigateur dit que c'est valide et [Un] ngular dit que non"? Non. Alors pourquoi serait-il étrange si cette validation de modèle était intégrée?
2. Nous sommes tous conscients que ce qui passe pour un e-mail valide dans le cas d'utilisation qui nous intéresse est plus restreint que la spécification.

_Je veux juste savoir pourquoi Angular ne devrait pas servir le cas d'utilisation qui m'intéresse, puisque c'est le cas général._

Alors pourquoi serait-il étrange si cette validation de modèle était intégrée?

En fait, vous obtenez le même comportement du navigateur. http://jsfiddle.net/t6rdmngo/ Si vous exécutez ceci dans un navigateur moderne, vous ne pourrez pas soumettre le formulaire supérieur en raison d'une incompatibilité de modèle si vous n'incluez pas de TLD.

Dans la version angulaire, vous obtenez le même comportement. C'est bon. C'est ce que nous voulons. Comportement identique entre le comportement natif et le comportement du framework. Le cadre ne devrait pas avoir de désaccord avec la plateforme

Maintenant je comprends. Merci de m'avoir supporté!

Vous pouvez rapidement résoudre ce problème en utilisant ng-pattern

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

Si vous changez le dernier * en + dans l'expression régulière, cela fonctionne comme prévu

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

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