Angular.js: E-Mail-Validator ist falsch

Ja, du hast recht, es sieht so aus, als ob EMAIL_REGEX falsch ist.

Laut http://dev.w3.org/html5/markup/input.email.html können wir verwenden

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

und das sieht so aus, als ob es besser funktionieren sollte, da die . nach den @

Ich werde versuchen, einen kurzen Patch dafür einzureichen.

... eigentlich ist das etwas komplizierter als ich dachte, das könnte etwas mehr Arbeit kosten. Es sieht so aus, als würde es auch reguläre Ausdrücke akzeptieren, die ebenfalls mit einem Punkt beginnen. Ich denke, hier gibt es ein bisschen Arbeit zu erledigen.

Wenn Sie dies vor mir lösen können, können Sie gerne eine Pull-Anfrage einreichen

Danke für den Fehlerbericht. In der Docs-Demo werden Sie diesen Fix erst bemerken, wenn 1.2.10 gelöscht wird, da das 1.2.9-Winkelskript ständig geladen wird. Aber in ein paar Tagen sollte dies in der Doc-Demo behandelt werden (es sei denn, das Commit wird zurückgesetzt, was O_O passieren kann).

Großartig, 10x!

Am Mittwoch, 22. Januar 2014, um 05:32 Uhr schrieb Caitlin Potter [email protected] :

Danke für den Fehlerbericht. In der Docs-Demo werden Sie dieses Update nicht bemerken
bis 1.2.10 fällt, weil es das 1.2.9-Winkelskript ständig lädt.
Aber in ein paar Tagen sollten Sie dies in der Doc-Demo sehen

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich auf Gi tHubhttps an: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

Was war mein Gesichtsausdruck, als ich bemerkte, dass " dummy @ ferferfe " (ohne Domain) als gültige Mail angesehen wird;)

@ mica16 aber dummy@ferferfe ist eine gültige E-Mail-Adresse. Domains müssen keine Erweiterung haben, denken Sie nur an localhost .

@Zequez richtig, aber wer zum Teufel verwendet eine localhost-Adresse für eine Website-Registrierung im Beispiel?

@mbeckenbach Verwendung
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
Nicht ideal, funktioniert aber.

@mbeckenbach ja, stimmt. Beachten Sie jedoch, dass ein Domainname ohne Punkte eine gültige Domain ist. Dass Sie mit ICANN keine Domain bei THEM registrieren können, bedeutet nicht, dass der Domainname ungültig ist.

6 @ 6 ist keine E-Mail-Adresse. Die Tatsache, dass es sich unter bestimmten Umständen um eine ordnungsgemäße E-Mail-Adresse handeln könnte, sollte uns meiner Meinung nach nicht dazu veranlassen, dies zuzulassen. Die Wahrscheinlichkeit, dass ein Fehler über dieses zulässige Muster durchkommt, ist um Größenordnungen höher als die Wahrscheinlichkeit, dass wir jemanden mit einer solchen E-Mail-Adresse ausschließen.

+1 für Jeff

@jeffmcmahan Es tut mir leid, aber es klingt so, als ob Sie ein Problem bei der IETF oder der WHATWG einreichen sollten. Sobald sich die Definition einer E-Mail-Adresse geändert hat, sollte sie in Angular geändert werden. Wir müssen jedoch die Anweisungen in den RFCs und WHATWG-Empfehlungen befolgen.

Wenn Sie jetzt etwas strenger sein möchten, können Sie auch einen Mustervalidator hinzufügen, das wäre in Ordnung.

@caitp Du bist der Boss.

Wie wäre es, EMAIL_REGEXP konfigurierbar zu machen? Unsere serverseitige Validierung ist strenger als die eckige. Insbesondere ist es beispielsweise erforderlich, dass der Teil vor dem @ -Zeichen nicht länger als 63 Zeichen ist. Jetzt müssen wir eine benutzerdefinierte Direktive für alle E-Mail-Eingaben erstellen oder daran denken, das ng-Muster zu jeder E-Mail-Eingabe hinzuzufügen.

Sie können ng-pattern zusätzlich zu type = email, @rjokelai verwenden. Außerdem erleichtert die Änderung der Validierungspipeline von

"Wenn Sie jetzt etwas strenger sein möchten, können Sie auch einen Mustervalidator hinzufügen, das wäre in Ordnung."

Wie wäre es mit dem Standard-Validator, der nur normale E-Mails mit einem Punkt akzeptiert, und wenn jemand in der winzigen Minderheit weniger streng sein möchte, kann er seinen eigenen Validator erstellen. Warum sollte die überwiegende Mehrheit der Entwickler ihr eigenes Muster erstellen müssen, damit die winzige Minderheit dies nicht muss? Das ist alberner Standardpurismus

Da dies im Grunde eine Polyfüllung für die Validierung von HTML5-Einschränkungen ist, ist dies der Grund. Nächste Woche werden wir hoffentlich eine Funktion ausliefern, die das Anpassen erheblich vereinfacht

Sind E-Mails ohne Domain-Zone gültig? Ich teste ein einfaches Eingabefeld mit type = "email" und Angular validiert

Oh, es gibt bereits ein geschlossenes Problem - https://github.com/angular/angular.js/issues/9463

Sind E-Mails ohne Domain-Zone gültig? Ich teste ein einfaches Eingabefeld mit type = "email" und Angular validiert die E-Mail von foo @ bar erfolgreich. (Angular v1.3.0)

Es handelt sich um gültige E-Mails gemäß Spezifikation. Diese Frage wurde in diesem Issue-Tracker so oft beantwortet, dass eine E-Mail ohne TLD nichts Ungültiges enthält.

Verwenden Sie einen benutzerdefinierten Validator, um die gewünschten TLDs zu benötigen

@caitp , mir ist klar, dass wir Sie darüber belästigt haben, aber ich denke, es könnte hilfreich sein, wenn Sie erklären, warum die Einhaltung der Spezifikation unerlässlich ist. Wir alle wissen , dass ein vernünftiger und kompetenter Entwickler nicht davon ausgehen wird, dass der E-Mail-Validator

Weil es wirklich komisch sein wird, wenn Ihr Browser sagt, dass es gültig ist und eckig sagt, dass es nicht gültig ist

Sie suchen nicht nach einer E-Mail-Validierung, sondern nach einer Mustervalidierung zusätzlich zur E-Mail-Validierung. Sie möchten gültige E-Mail-Adressen (von Angular behandelt), die einem bestimmten Muster entsprechen (enthält eine TLD).

1. Wäre es seltsam, wenn Sie eine Musterüberprüfung hinzufügen und dann "Ihr Browser sagt, dass es gültig ist und [A] ngular sagt, dass es nicht gültig ist"? Warum sollte es also seltsam sein, wenn diese Mustervalidierung eingebaut wäre?
2. Wir sind uns alle bewusst, dass das, was in dem Anwendungsfall, an dem wir interessiert sind, als gültige E-Mail gilt, enger ist als die Spezifikation.

Ich möchte nur wissen, warum Angular nicht den Anwendungsfall bedienen sollte, an dem ich interessiert bin, da dies der allgemeine Fall ist.

Warum wäre es also seltsam, wenn diese Mustervalidierung eingebaut wäre?

Tatsächlich erhalten Sie das gleiche Verhalten vom Browser. http://jsfiddle.net/t6rdmngo/ Wenn Sie dies in einem modernen Browser ausführen, können Sie das Top-Formular aufgrund einer Musterinkongruenz nicht senden, wenn Sie keine TLD einschließen.

In der Winkelversion erhalten Sie das gleiche Verhalten. Das ist gut. Das wollen wir. Identisches Verhalten zwischen dem nativen Verhalten und dem Framework-Verhalten. Das Framework sollte keine Meinungsverschiedenheiten mit der Plattform haben

Jetzt habe ich es verstanden. Danke, dass du dich mit mir abgefunden hast!

Sie können dies schnell beheben, indem Sie ng-pattern

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

Wenn Sie das letzte * in der Regex in + ändern, funktioniert es wie erwartet

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

/^[a-zA-Z0-9 -zA-Z0-9 -] +) + $ /