So überprüfen Sie eine E-Mail-Adresse in JavaScript


4375

Gibt es einen regulären Ausdruck zum Überprüfen einer E-Mail-Adresse in JavaScript?



60
Bitte machen Sie das richtig, zu viele Websites mögen meine E-Mail-Adresse "firstName@secondName.name" nicht, nicht alle Top-Level-Domains beenden sie mit 2 oder 3 Buchstaben.
Ian Ringrose

41
Jegliche Unterstützung für die Verwendung von Regex-Prüfungen für E-Mails, gegen die ich zu 100% bin. Ich habe es satt zu erfahren, dass meine E-Mail-Adresse "foo+bar@gmail.com" ungültig ist. Am besten bitten Sie den Benutzer, seine E-Mail-Adresse zweimal einzugeben. Wenn Sie einen Regex-Prüfer verwenden MÜSSEN, teilen Sie dem Benutzer mit, dass seine E-Mail-Adresse nicht gültig zu sein scheint, und fragen Sie ihn, ob er sicher ist, dass er sie eingegeben hat Recht. Gehen Sie sogar so weit, darauf hinzuweisen, WAS bei der Regexp-Prüfung nicht ausgecheckt wurde, aber hindern Sie sie NICHT daran, das Formular einzureichen.
Soundfx4

17
@ Soundfx4: Dies sollte DIE Antwort sein und als solche akzeptiert werden. Das Testen der Richtigkeit einer Adresse ist eine dumme Sache - der beste Weg, um Kunden zu frustrieren. Ich bitte die Adresse eingegeben zweimal und Hinweis werden , dass es einige mögliche Probleme (fehlende @, ;cometc.) und lassen den Benutzer zu korrigieren , wenn sie wollen (und akzeptieren , was sie mir schicken)
WoJ

4
Ich stimme der Antwort von WoJ voll und ganz zu. Das Format einer gültigen E-Mail-Adresse ist viel zu komplex, um mit einem einfachen regulären Ausdruck überprüft zu werden. Der einzige Weg, um sicherzugehen, dass die Adresse gültig ist, besteht darin, sie auszuprobieren.
Nicole

Antworten:


4942

Die Verwendung regulärer Ausdrücke ist wahrscheinlich der beste Weg. Sie können hier eine Reihe von Tests sehen (aus Chrom )

function validateEmail(email) {
    const re = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
    return re.test(String(email).toLowerCase());
}

Hier ist das Beispiel eines regulären Ausdrucks, der Unicode akzeptiert:

const re = /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;

Beachten Sie jedoch, dass Sie sich nicht nur auf die JavaScript-Validierung verlassen sollten. JavaScript kann einfach deaktiviert werden. Dies sollte auch auf der Serverseite überprüft werden.

Hier ist ein Beispiel für das oben Genannte in Aktion:

function validateEmail(email) {
  const re = /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  return re.test(email);
}

function validate() {
  const $result = $("#result");
  const email = $("#email").val();
  $result.text("");

  if (validateEmail(email)) {
    $result.text(email + " is valid :)");
    $result.css("color", "green");
  } else {
    $result.text(email + " is not valid :(");
    $result.css("color", "red");
  }
  return false;
}

$("#validate").on("click", validate);
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<form>
  <p>Enter an email address:</p>
  <input id='email'>
  <button type='submit' id='validate'>Validate!</button>
</form>

<h2 id='result'></h2>


575
Diese Regex eliminiert gültige, in Gebrauch befindliche E-Mails. Verwende nicht. Google für "RFC822" oder "RFC2822", um eine korrekte Regex zu erhalten.
Randal Schwartz

42
Dies akzeptiert nicht einmal die Beispiele in RFC 822. In einigen einfachen Fällen stimmt es nicht mit a \ @ b @ c.com, a(b)@c.com überein. Weitere Informationen finden Sie im RFC. Hier ist ein regulärer Ausdruck, der keine gültigen Adressen [^ @] + @ [^ @] + \. [^ @] + Zurückweist und vor häufigen Fehlern schützt.
Vroo

126
@GoodPerson Ich habe gerade versucht, n @ ai eine E-Mail zu senden, um ihm / ihr mitzuteilen, dass sie eine coole E-Mail-Adresse haben. Aber leider ließ mich Google Mail nicht. Ich vermute, wer auch immer größere Probleme mit der Kommunikation mit anderen per E-Mail hat als nur die Javascript-Validierung meiner Website! Aber danke, dass Sie sich der Herausforderung gestellt haben.
Ben Roberts

26
Dies ist eine Lösung, die für die meisten englischen Muttersprachler gut zu sein scheint, aber den Türkei-Test nicht besteht (siehe Joel Spolsky). Die meisten Unicode-Buchstaben sind zulässig, und beispielsweise in Argentinien sind Adressen wie "ñoñó1234@server.com" völlig normal. joelonsoftware.com/articles/Unicode.html
Oligofren

139
Sie können E-Mail-Adressen nicht überprüfen. Der einzige, der eine E-Mail-Adresse validieren kann, ist der Anbieter der E-Mail-Adresse. In dieser Antwort heißt es beispielsweise, dass diese E-Mail-Adressen %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comalle gültig sind, Google Mail jedoch niemals eine dieser E-Mail-Adressen zulässt. Sie sollten dies tun, indem Sie die E-Mail-Adresse akzeptieren und eine E-Mail-Nachricht an diese E-Mail-Adresse mit einem Code / Link senden, den der Benutzer besuchen muss, um die Gültigkeit zu bestätigen.
Kevin Fegan

829

Ich habe Jaymons Antwort für Leute, die eine wirklich einfache Validierung wünschen, leicht modifiziert in Form von:

anystring@anystring.anystring

Der reguläre Ausdruck:

/\S+@\S+\.\S+/

Beispiel für eine JavaScript-Funktion:

function validateEmail(email) 
    {
        var re = /\S+@\S+\.\S+/;
        return re.test(email);
    }
    
console.log(validateEmail('anystring@anystring.anystring'));


69
Sie können etwas 20-mal so lang implementieren, das für einige Benutzer Probleme verursachen und möglicherweise in Zukunft nicht mehr gültig ist, oder Sie können die Version von ImmortalFirefly herunterladen, um sicherzustellen, dass sie sich zumindest bemühen, es real aussehen zu lassen. Abhängig von Ihrer Anwendung kann es wahrscheinlicher sein, dass jemand verrückt wird, weil Sie seine unkonventionelle E-Mail nicht akzeptieren, als jemand, der Probleme verursacht, indem er nicht wirklich vorhandene E-Mail-Adressen eingibt (was er sowieso durch Eingabe tun kann eine 100% gültige RFC2822-E-Mail-Adresse, die jedoch einen nicht registrierten Benutzernamen oder eine nicht registrierte Domain verwendet). Upvoted!
user83358

82
@ImmortalFirefly, der von Ihnen angegebene reguläre Ausdruck stimmt tatsächlich überein name@again@example.com. Versuchen Sie, Ihre Zeile in eine JavaScript-Konsole einzufügen. Ich glaube, Ihre Absicht war es, nur den gesamten Text abzugleichen, was den Anfang von Text '^' und das Ende von Text '$' Operatoren erfordern würde. Die, die ich benutze, ist/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
Basierend auf dieser Validierung ist diese E-Mail gültig: check @ this..com
Ehsan

4
Hm. Wikipedia sagt, dass dies "very.unusual.@.unusual.com"@example.comeine gültige E-Mail-Adresse ist. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. Hoppla.
Bacon Bits

3
Erlaubt das nicht auch @@@.@? : D
hfossli

762

Der Vollständigkeit halber haben Sie hier einen weiteren RFC 2822-kompatiblen regulären Ausdruck

Der offizielle Standard ist als RFC 2822 bekannt . Es beschreibt die Syntax, die gültige E-Mail-Adressen einhalten müssen. Sie können ( aber Sie sollten nicht - lesen Sie weiter ) implementieren es mit diesem regulären Ausdruck:

(?:[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])+)\])

(...) Wir erhalten eine praktischere Implementierung von RFC 2822, wenn wir die Syntax in doppelten Anführungszeichen und eckigen Klammern weglassen. Es entspricht immer noch 99,99% aller E-Mail-Adressen, die heute tatsächlich verwendet werden.

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

Eine weitere Änderung, die Sie vornehmen können, besteht darin, eine aus zwei Buchstaben bestehende Ländercode-Top-Level-Domain und nur bestimmte generische Top-Level-Domains zuzulassen. Diese Regex filtert Dummy-E-Mail-Adressen wieasdf@adsf.adsf . Sie müssen es aktualisieren, wenn neue Top-Level-Domains hinzugefügt werden .

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b

Selbst wenn offizielle Standards eingehalten werden, müssen noch Kompromisse geschlossen werden. Kopieren Sie reguläre Ausdrücke nicht blind aus Online-Bibliotheken oder Diskussionsforen. Testen Sie sie immer an Ihren eigenen Daten und mit Ihren eigenen Anwendungen.

Hervorhebung von mir


84
NB: " Heute tatsächlich verwendet " war möglicherweise gültig, als der Code geschrieben wurde, und zwar bereits 200x. Der Code wird wahrscheinlich über dieses Jahr hinaus weiter verwendet. (Wenn ich einen Cent für jedes "meh, niemand würde jemals eine TLD mit 4 + Buchstaben verwenden, außer den spezifischen", die ich reparieren musste, könnte ich den Kupfer- und Nickelmarkt der Welt
erobern

7
Für die praktische Implementierung von RFC 2822 sollte die Endung geringfügig geändert werden, um Einzelzeichen-Domänenerweiterungen zu verhindern. / [a-z0-9! # $% & '* + \ / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_{|} ~ -] +) * @ (?: [a-z0-9] (?: [a-z0-9 -] * [a-z0-9])? \.) + [a-z0-9] [a-z0-9 -] * [a-z0-9] /
wird Farrell

5
Außerdem sollte der erste Teil (?: [Az mit einem Großbuchstaben A sein, um falsche Negative zu vermeiden, wenn ein Benutzer seine E-Mail-Adresse großschreibt.
Don Rolling

9
@ DonRolling Tu das nicht. Das bedeutet nicht nur "A bis Z, a bis z", sondern auch "[\] ^ _` ", weil diese zwischen " Z "und" a "liegen. Verwenden Sie \woder besser nur die E-Mail-Adresse in Kleinbuchstaben, bevor Sie etwas damit tun, da dies sowieso die Konvention ist.
Kirb

5
"Sie müssen es aktualisieren, wenn neue Top-Level-Domains hinzugefügt werden." Nun, dazu soviel - es gibt über 1500 anerkannte TLDs.
Nathan Osman

377

Wow, hier gibt es viel Komplexität. Wenn Sie nur die offensichtlichsten Syntaxfehler abfangen möchten, würde ich Folgendes tun:

^\S+@\S+$

Es fängt normalerweise die offensichtlichsten Fehler ab, die der Benutzer macht, und stellt sicher, dass das Formular größtenteils richtig ist, worum es bei der JavaScript-Validierung geht.


70
+1 Da das Senden von E-Mails und das Sehen, was passiert, der einzig sichere Weg ist, eine E-Mail-Adresse zu validieren, müssen Sie nicht mehr als eine einfache Regex-Übereinstimmung durchführen.
kommradHomer

20
Sie können es immer noch einfach halten, aber etwas mehr tun, um sicherzustellen, dass es ein "" hat. Irgendwo nach dem @, gefolgt von nur Zahlen oder Ziffern, sind Dinge wie ich hier, ich hier und ich hier nicht gültig ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin

14
Ich denke, E-Mail-Adressen können Leerzeichen enthalten. Es ist wahrscheinlich besser zu verwenden.+@.+
Sam

11
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð") true
Gtournie

110
@gtournie Niemand kümmert sich. Niemand wird , dass ein E - Mail - Feld eingeben durch Zufall , und das ist alles , Front-End - Validierung ist für: Um die Menschen zu verhindern , dass versehentlich die falsche Menge an Informationen eingeben, wie ihr Namen, in einem E - Mail - Feld.
Meagar

330

Es gibt etwas, das Sie verstehen müssen, sobald Sie sich entscheiden, einen regulären Ausdruck zum Validieren von E-Mails zu verwenden: Es ist wahrscheinlich keine gute Idee . Sobald Sie sich damit abgefunden haben, gibt es viele Implementierungen, die Sie auf halbem Weg dorthin bringen können. Dieser Artikel fasst sie gut zusammen.

Kurz gesagt, die einzige Möglichkeit, absolut sicher zu sein, dass der Benutzer tatsächlich eine E-Mail eingegeben hat, besteht darin, tatsächlich eine E-Mail zu senden und zu sehen, was passiert. Davon abgesehen ist alles nur eine Vermutung.


112
-1 Warum sollte ich meine Zeit damit verbringen, eine E-Mail-Adresse zu überprüfen, die nicht einmal die Regex-Kontrolle besteht?
kommradHomer

63
@kommradHomer - Eine "Regex-ungültige" Adresse ist fast immer gültig, da jeder Regex, den Sie zur Validierung einer E-Mail-Adresse verwenden, mit ziemlicher Sicherheit falsch ist und gültige E-Mail-Adressen ausschließt. Eine E-Mail-Adresse ist name_part@domain_partund praktisch alles, einschließlich einer @, ist im name_part gültig. Die Adresse foo@bar@machine.subdomain.example.museumist legal, muss jedoch als maskiert werden foo\@bar@machine..... Sobald die E-Mail die Domain erreicht hat, z. B. 'example.com', kann diese Domain die Mail "lokal" weiterleiten, sodass "seltsame" Benutzernamen und Hostnamen existieren können.
Stephen P

6
Der zweite reguläre Ausdruck in der Antwort des Reisenden in stackoverflow.com/a/1373724/69697 ist praktisch und sollte fast keine falschen Negative enthalten. Ich stimme @kommradHomer hier zu - warum eine E-Mail senden, wenn Sie nicht müssen? Ich kann reflexive Abneigung gegen unverständliche reguläre Ausdrücke und den Wunsch verstehen, Code einfach zu halten, aber dies sind ein paar Codezeilen, die Ihrem Server viel Ärger ersparen können, indem sie Elemente, die definitiv ungültig sind, sofort aussortieren. Ein regulärer Ausdruck allein ist nicht hilfreich, dient jedoch als gute Ergänzung zur serverseitigen Validierung.
Ben Regenspan

6
@dmur Ich gebe zu, dass "fast immer gültig" es wahrscheinlich überbewertet, aber ich habe meine (vollkommen gültigen und funktionierenden) E-Mail-Adressen viel zu oft von Websites abgelehnt bekommen, nur weil ich eine .usDomain habe oder weil ich eine +links von verwendet habe Die @- viele Orte haben diese ungeheuren Fehler behoben, aber der lokale Teil (links von @) kann alles sein, was der Domaininhaber will. -> "foo@bar.com"@example.com <- ist eine gültige E-Mail-Adresse.
Stephen P

8
@kommradHomer "Eine Regex-ungültige Adresse ist% 100 eine ungültige Adresse." Es tut mir leid ... Entschuldigung? Wissen Sie, wie oft mir gesagt wurde, dass foo+bar@gmail.com KEINE gültige E-Mail ist, obwohl sie tatsächlich gültig ist?! Ihre Logik ist EXTREM fehlerhaft. Ich habe Formulare mit E-Mails als solche gesendet: Dies ist eine falsche E-Mail, aber sie wird Ihre dumme Adresse überschreiten. DAS PASSIERT DEN REGEX-Check ... aber es ist KEINE gültige E-Mail (obwohl es technisch gesehen so ist, aber ich verspreche Ihnen, dass es nicht existiert ... kratzt sich am Kinn ). Wie viele gesagt haben, ist es eine
schlechte Idee

211

HTML5 selbst verfügt über eine E-Mail-Validierung. Wenn Ihr Browser HTML5 unterstützt, können Sie den folgenden Code verwenden.

<form><input type="email" placeholder="me@example.com" required>
    <input type="submit">
</form>

jsFiddle Link

Aus der HTML5-Spezifikation :

Eine gültige E-Mail-Adresse ist eine Zeichenfolge, die der emailProduktion des folgenden ABNF entspricht, dessen Zeichensatz Unicode ist.

email   = 1*( atext / "." ) "@" label *( "." label )
label   = let-dig [ [ ldh-str ] let-dig ]  ; limited to a length of 63 characters by RFC 1034 section 3.5
atext   = < as defined in RFC 5322 section 3.2.3 >
let-dig = < as defined in RFC 1034 section 3.5 >
ldh-str = < as defined in RFC 1034 section 3.5 >

Diese Anforderung stellt eine vorsätzliche Verletzung von RFC 5322 dar, das eine Syntax für E-Mail-Adressen definiert, die gleichzeitig zu streng (vor dem Zeichen "@"), zu vage (nach dem Zeichen "@") und zu lasch (Kommentare zulassen) ist , Leerzeichen und zitierte Zeichenfolgen auf eine Weise, die den meisten Benutzern unbekannt ist), um hier von praktischem Nutzen zu sein.

Der folgende JavaScript- und Perl-kompatible reguläre Ausdruck ist eine Implementierung der obigen Definition.

/^[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])?)*$/

29
Das ist gut, aber das Problem dabei ist, dass es sich in einem formTag befinden und von einer submitEingabe übermittelt werden muss , zu der nicht jeder den Luxus hat. Außerdem können Sie die Fehlermeldung nicht wirklich formatieren.
Jason

3
Ich habe unten eine Antwort hinzugefügt, die Sie vom Formular befreit und abschickt. Aber ja, die Browser wenden normalerweise auch nur eine Plausibilitätsprüfung an und keine vollständige RFC 822-Validierung.
Boldewyn

8
@ br1: Es ist nicht ungültig, nur weil keine "a" Toplevel-Domain existiert. Was ist, wenn Ihr Intranet eine Auflösung für eine IP hat?
fliegende Schafe

7
Der HTML5-E-Mail-Feldtyp akzeptiert E-Mails wie user @ email
Puce

1
Anmerkung von @ Puce: Die HTML 5-E-Mail-Eingabe akzeptiert, user@emailwährend dies bei PHPs beispielsweise filter_varnicht der Fall ist. Dies kann zu Problemen führen.
Texelate

136

Ich habe festgestellt, dass dies die beste Lösung ist:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

Es erlaubt die folgenden Formate:

1. Prettyandsimple@example.com
2. very.common@example.com
3. disposable.style.email.with+symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?^_`{}|~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. "" @ example.org (Leerzeichen zwischen den Anführungszeichen)
8. üñîçøðé@example.com (Unicode-Zeichen im lokalen Teil)
9. üñîçøðé@üñîçøðé.com (Unicode-Zeichen im Domain-Teil)
10. Pelé@example.com (lateinisch)
11. δοκιμή@παράδειγμα.δοκιμή (Griechisch)
12. 我 買 @ 屋企. 香港 (Chinesisch)
13. Japanese 斐 @ 黒 川. 日本 (Japanisch)
14. Cyrебурашка@ящик-с-апельсинами.рф (kyrillisch)

Es ist eindeutig vielseitig und erlaubt die wichtigsten internationalen Charaktere, während das grundlegende Format "any@anything.anything" durchgesetzt wird. Es werden Leerzeichen blockiert, die von RFC technisch zugelassen sind, aber sie sind so selten, dass ich das gerne mache.


9
Genau das mache ich. Alle diese "komplizierten" Antworten verursachen Probleme: Sie erlauben entweder keine Puny-Code-IDN oder verwenden einen festen Satz von TLDs oder beschränken den Benutzer unnötig darauf, keine Zeichen wie [@ çµ.ö in ihrem E-Mail-Präfix (vor @) zu verwenden. oder Domainname. JavaScript im Frontend (nicht für die Verwendung von Ursachen im Backend) reicht aus Sicherheitsgründen nicht für die Validierung aus. Warum also nicht einfach dem Benutzer helfen, grundlegende Tippfehler zu vermeiden? Grundlegende Tippfehler sind: TLD oder Benutzerpräfix (vor @) oder Domain-Teil vergessen oder @als .(oder umgekehrt) falsch eingeben . Natürlich müssen wir serverseitig viel restriktiver sein.
Hafenkranich

Aus seltsamen Gründen username@domain.comfunktioniert dieses Muster nicht
einstein

2
Laut Ihrer Regex ist "_.............. kamal@gmail.com" gültig, was nicht sein sollte!
Kamal Nayan

1
Hier ist die angegebene RegEx mit Beispielen, wenn Sie mit dieser Lösung basteln möchten: regex101.com/r/AzzGQU/2
Ryanm

7
Dieser reguläre Ausdruck ist korrekt. Wenn jemand seine E-Mail wie a@b@c@d.x.y.@.zdann eingibt, haben sie es vielleicht verdient, eine schlechte Zeit zu haben? : D
Corysimmons

94

In modernen Browsern können Sie mit reinem JavaScript und dem DOM auf der Antwort von @ Sushil aufbauen :

function validateEmail(value) {
  var input = document.createElement('input');

  input.type = 'email';
  input.required = true;
  input.value = value;

  return typeof input.checkValidity === 'function' ? input.checkValidity() : /\S+@\S+\.\S+/.test(value);
}

Ich habe ein Beispiel in der Geige http://jsfiddle.net/boldewyn/2b6d5/ zusammengestellt . In Kombination mit der Funktionserkennung und der Bare-Bones-Validierung von Squirtle's Answer befreit es Sie vom Massaker mit regulären Ausdrücken und belastet alte Browser nicht.


4
Dies ist eine clevere Idee, um das Problem anzugehen, aber es funktioniert nicht, da Browser ebenfalls eine beschissene Validierung haben. ZB .@avalidiert wie truein aktuellen Versionen von Chrome, Firefox und Safari.
Hank

13
@ HenryJackson Leider in diesem Fall ja. Dies liegt daran, dass es sich laut RFC um eine gültige E-Mail-Adresse handelt (denken Sie an Intranets). Browser würden gegrillt, wenn sie zu eng validieren und falsche Negative produzieren.
Boldewyn

3
Es wurde aktualisiert, um die Erkennung von Funktionen und die ordnungsgemäße Verschlechterung einzuschließen. Jetzt funktioniert es nicht mehr in neuen Browsern, sondern verwendet einen beliebigen regulären Ausdruck.
Ronny

Schöne Lösung. Leider ist dies nur für HTML5 +.
Edward Olamisan

3
Dies ist bei weitem die beste Lösung für die ursprüngliche Frage. Ja, es wird HTML5 verwendet, aber die meisten Anwendungen, die diese Genauigkeit erfordern, werden sich sicherlich bereits auf eine andere Weise auf HTML5 verlassen. Es ist für uns unmöglich, jemals festzustellen, ob die E-Mail-Adresse einer Person gültig ist, ohne dass sie ohnehin überprüft wird. Daher sollten wir wirklich nicht so viel Zeit oder Mühe in die Validierung investieren. Eine schnelle Überprüfung auf offensichtliche Syntax oder versuchte Ungezogenheit ist der ganze Aufwand, den wir aufwenden sollten.
Woody Payne

69

Dies ist die richtige RFC822-Version.

function checkEmail(emailAddress) {
  var sQtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]';
  var sDtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]';
  var sAtom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+';
  var sQuotedPair = '\\x5c[\\x00-\\x7f]';
  var sDomainLiteral = '\\x5b(' + sDtext + '|' + sQuotedPair + ')*\\x5d';
  var sQuotedString = '\\x22(' + sQtext + '|' + sQuotedPair + ')*\\x22';
  var sDomain_ref = sAtom;
  var sSubDomain = '(' + sDomain_ref + '|' + sDomainLiteral + ')';
  var sWord = '(' + sAtom + '|' + sQuotedString + ')';
  var sDomain = sSubDomain + '(\\x2e' + sSubDomain + ')*';
  var sLocalPart = sWord + '(\\x2e' + sWord + ')*';
  var sAddrSpec = sLocalPart + '\\x40' + sDomain; // complete RFC822 email address spec
  var sValidEmail = '^' + sAddrSpec + '$'; // as whole string

  var reValidEmail = new RegExp(sValidEmail);

  return reValidEmail.test(emailAddress);
}

IDN-Adressen werden nicht validiert (info@üpöü.com)
DAH

66

JavaScript kann einem regulären Ausdruck entsprechen:

emailAddress.match( / some_regex /);

Hier ist ein regulärer RFC22- Ausdruck für E-Mails:

^((?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*
"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|"((?=[\x01-\x
7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<
!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])
[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$

1
@Kato: Es werden einige inkompatible Erweiterungen verwendet, unter anderem (?>, um das Zurückverfolgen zu stoppen und (?<angle><)…(?(angle)>)das Bereitstellen einer längeren Erweiterung zu vermeiden |.
Ry-

60

Alle E-Mail-Adressen enthalten ein 'at'-Symbol (dh @). Testen Sie diese notwendige Bedingung:

email.indexOf("@") > 0

Kümmere dich nicht um etwas Komplizierteres. Selbst wenn Sie perfekt feststellen könnten, ob eine E-Mail RFC-syntaktisch gültig ist, würde dies Ihnen nicht sagen, ob sie der Person gehört, die sie bereitgestellt hat. Darauf kommt es wirklich an.

Um dies zu testen, senden Sie eine Validierungsnachricht.


3
Was ist, wenn es mehr als ein @ -Symbol gibt? andere eingeschränkte Symbole? Dieser Validierung kann nicht vertraut werden ...
eatmypants

56

Eine korrekte Validierung der E-Mail-Adresse in Übereinstimmung mit den RFCs kann mit einem regulären Einzeiler-Ausdruck nicht erreicht werden. Ein Artikel mit der besten Lösung, die ich in PHP gefunden habe, lautet: Was ist eine gültige E-Mail-Adresse? . Offensichtlich wurde es nach Java portiert. Ich denke, die Funktion ist zu komplex, um in JavaScript portiert und verwendet zu werden. JavaScript / node.js-Port: https://www.npmjs.com/package/email-addresses .

Es empfiehlt sich, Ihre Daten auf dem Client zu validieren, die Validierung auf dem Server jedoch noch einmal zu überprüfen. In diesem Sinne können Sie einfach überprüfen, ob eine Zeichenfolge wie eine gültige E-Mail-Adresse auf dem Client aussieht, und die strenge Überprüfung auf dem Server durchführen.

Hier ist die JavaScript-Funktion, mit der ich überprüfe, ob eine Zeichenfolge wie eine gültige E-Mail-Adresse aussieht:

function looksLikeMail(str) {
    var lastAtPos = str.lastIndexOf('@');
    var lastDotPos = str.lastIndexOf('.');
    return (lastAtPos < lastDotPos && lastAtPos > 0 && str.indexOf('@@') == -1 && lastDotPos > 2 && (str.length - lastDotPos) > 2);
}

Erläuterung:

  • lastAtPos < lastDotPos: Last @sollte vor last sein, .da @es nicht Teil des Servernamens sein kann (soweit ich weiß).

  • lastAtPos > 0: Vor dem letzten sollte etwas (der E-Mail-Benutzername) stehen @.

  • str.indexOf('@@') == -1: @@Die Adresse sollte keine enthalten . Selbst wenn es @als letztes Zeichen im E-Mail-Benutzernamen erscheint, muss es in Anführungszeichen gesetzt werden ", also zwischen diesem @und dem letzten @in der Adresse.

  • lastDotPos > 2: Es sollten zum Beispiel mindestens drei Zeichen vor dem letzten Punkt stehen a@b.com.

  • (str.length - lastDotPos) > 2: Nach dem letzten Punkt sollten genügend Zeichen stehen, um eine Domäne mit zwei Zeichen zu bilden. Ich bin mir nicht sicher, ob die Klammern notwendig sind.


Das fn sieht gut aus, aber ist es besser als der reguläre Ausdruck in der oberen Antwort?
Atul Goyal

4
Ich bezweifle das. Ich verwende es nur, um zu überprüfen, ob eine Zeichenfolge wie eine E-Mail aussieht, und um die Details dem serverseitigen Code zu überlassen.
Miloš Rašić

Es überprüft OK jede Zeichenfolge wie 'aaaa', dh ohne '@' und '.'
Gennady Shumakher

1
Es sollte nicht. lastIndexOf () sollte -1 zurückgeben, wenn die Nadel nicht gefunden wird.
Miloš Rašić

"Auch wenn es @als letztes Zeichen im E-Mail-Benutzernamen erscheint, muss es in Anführungszeichen gesetzt werden ", also zwischen diesem @und dem letzten @in der Adresse." Was ist mit "@@"@example.com?
Ry-

47

Dies wurde von http://codesnippets.joyent.com/posts/show/1917 gestohlen

email = $('email');
filter = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
if (filter.test(email.value)) {
  // Yay! valid
  return true;
}
else
  {return false;}

7
Dies filtert immer beliebte .museumund .travelDomains heraus (aufgrund von 4 .
Zeichen

4
Das Ändern von {2,4} in {2,6} ist kein Problem
Anton N

11
@Anton N: Es hat auch ungefähr eine Unmenge anderer Probleme; Das Finale {2,4}ist lediglich ein nützlicher Indikator dafür (wie in "Wenn Sie diesen Fehler sehen, sind andere wahrscheinlich in der Nähe"). Das grundlegendste ist das Fehlen +im lokalen Teil; Dieses Kommentarfeld ist zu klein, um auf alle oben begangenen Fehler hinzuweisen.
Piskvor verließ das Gebäude am

37
Warum kannst du es nicht einfach tun return filter.test(email.value);?
MT.

3
@AntonN: Jetzt haben wir TLDs mit mehr als 10 Zeichen ( xn--clchc0ea0b2g2a9gcd). Immer noch kein Problem?
Piskvor verließ das Gebäude am

42

Mach das:

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

Warum? Es basiert auf RFC 2822 , einem Standard, den ALLE E-Mail-Adressen einhalten MÜSSEN. Und ich bin mir nicht sicher, warum du dich mit etwas "Einfacherem" beschäftigen würdest ... du wirst es trotzdem kopieren und einfügen;)

Wenn ich E-Mail-Adressen in der Datenbank speichere, mache ich sie oft in Kleinbuchstaben und in der Praxis können reguläre Ausdrücke normalerweise ohne Berücksichtigung der Groß- und Kleinschreibung markiert werden. In diesen Fällen ist dies etwas kürzer:

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

Hier ist ein Beispiel für die Verwendung in JavaScript (mit dem Flag für Groß- und Kleinschreibung iam Ende).

var emailCheck=/^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$/i;
console.log( emailCheck.test('some.body@domain.co.uk') );

Hinweis :
Technisch gesehen können einige E-Mails Anführungszeichen im Abschnitt vor dem @Symbol mit Escape-Zeichen in den Anführungszeichen enthalten (sodass Ihr E-Mail-Benutzer unausstehlich sein und Dinge wie @und enthalten kann, "..."solange sie in Anführungszeichen geschrieben sind). Niemand tut dies jemals! Es ist veraltet. Es ist jedoch im wahren RFC 2822- Standard enthalten und wird hier weggelassen.

Weitere Informationen: http://www.regular-expressions.info/email.html


@Kondal Der Javascript-Code unterscheidet nicht zwischen Groß- und Kleinschreibung, da das /iFlag am Ende des regulären Ausdrucks angezeigt wird . Ich erwähne die Tatsache, dass es ein Vergleich sein muss, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird, aber ich werde das klarer machen.
Ryan Taylor

Arbeitete für mich als Zauber
Alex

40

Ich freue mich sehr darauf, dieses Problem zu lösen. Also habe ich den regulären Ausdruck für die E-Mail-Validierung oben geändert

  • Original
    /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

  • Geändert
    /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

um die Beispiele in der Wikipedia-E-Mail-Adresse zu übergeben .

Und Sie können das Ergebnis hier sehen .

Geben Sie hier die Bildbeschreibung ein


Dies scheint eine gute Lösung zu sein, es funktioniert auch mit neuen TLDs und 1-Brief-E-Mails
Mark Hughes

Warum john..doe@example.comsollte nicht richtig sein? Es ist ein gültiger Eckfall.
Valerio Bozz

24

Sie sollten keine regulären Ausdrücke verwenden, um eine Eingabezeichenfolge zu überprüfen und zu überprüfen, ob es sich um eine E-Mail handelt. Es ist zu kompliziert und würde nicht alle Fälle abdecken.

Da Sie jetzt nur 90% der Fälle abdecken können, schreiben Sie Folgendes:

function isPossiblyValidEmail(txt) {
   return txt.length > 5 && txt.indexOf('@')>0;
}

Sie können es verfeinern. Zum Beispiel ist 'aaa @' gültig. Aber insgesamt bekommt man das Wesentliche. Und lassen Sie sich nicht mitreißen ... Eine einfache 90% ige Lösung ist besser als eine 100% ige Lösung, die nicht funktioniert.

Die Welt braucht einfacheren Code ...


15
Dies ermöglicht die Eingabe so vieler ungültiger E-Mail-Adressen, dass es sich um nutzlose Ratschläge handelt.
Cazlab

3
Es muss nicht unmöglich sein, überhaupt zu debuggen. In diesem Thread gibt es viele gute Beispiele, die weiter validieren als "Hat es ein '@'? In Ihrem Beispiel kann" u @ "als gültige E-Mail-Adresse betrachtet werden. Bewerten Sie zumindest, ob es eine Domain oder etwas gibt, das Möglicherweise handelt es sich um eine Domain. Ihre ist ein Beispiel für das, was ich als "aggressiv faule Codierung" bezeichnen würde. Ich bin mir nicht sicher, warum Sie sie verteidigen, da dies bei weitem die am niedrigsten bewertete Antwort im Thread ist.
cazlab

3
@ Kazlab vielleicht hast du recht. Immerhin bin ich abgewählt worden. Anders als Sie denke ich nicht, dass einer der obigen Codes einfach zu debuggende Snippets zeigt. Zumindest mein "aggressiv fauler" Ansatz kann bei Bedarf verbessert werden.
Zo72

3
Wie unterscheidet sich das von der Verwendung von Regex? (.+)@(.*)macht das gleiche und kürzer.
Snostorm

4
+1 - Wenn das Ziel darin besteht, sicherzustellen, dass der Benutzer mindestens versucht hat, eine E-Mail-Adresse einzugeben, prüfen Sie, ob festgestellt werden kann, dass es sich bei der E-Mail-Adresse definitiv NICHT um eine E-Mail-Adresse handelt tolle Lösung. Ein gutes Beispiel wäre, wenn der Benutzername einer Person eine E-Mail-Adresse sein soll. Wenn der Benutzer 'sexy_chick_23' eingibt, kann dieser reguläre Ausdruck verwendet werden, um ihm mitzuteilen, dass eine E-Mail erwartet wird. Wenn etwas eingegeben wird, das wie eine E-Mail aussieht, dies aber nicht ist, erhält der Benutzer niemals die Bestätigungs-E-Mail und der Anmeldevorgang wird niemals validiert.
Chris Dutrow

23

Überprüfen Sie einfach, ob die eingegebene E-Mail-Adresse gültig ist oder nicht.

<input type="email"/>

Es ist nicht erforderlich, eine Funktion zur Validierung zu schreiben.


4
IE <10 unterstützt dies nicht und der Android-eigene Browser auch nicht.
Frank Conijn

7
Upvoting. IE <10 ist tot.
Michael Scheper

19

Es ist schwierig, einen E-Mail-Validator zu 100% korrekt zu machen. Die einzige Möglichkeit, dies zu korrigieren, besteht darin, eine Test-E-Mail an das Konto zu senden. Es gibt jedoch einige grundlegende Überprüfungen, mit denen Sie sicherstellen können, dass Sie etwas Vernünftiges erhalten.

Einige Dinge zu verbessern:

RegExpVersuchen Sie statt neu einfach, das regexpwie folgt zu schreiben :

if (reg.test(/@/))

Stellen Sie zweitens sicher, dass nach dem @Zeichen ein Punkt steht , und stellen Sie sicher, dass zwischen @s und Punkt Zeichen stehen .


19

So macht es der Node-Validator :

/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[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]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/

14

Verwenden Sie diesen Code in Ihrer Validierungsfunktion:

var emailID = document.forms["formName"]["form element id"].value;
atpos = emailID.indexOf("@");
dotpos = emailID.lastIndexOf(".");
if (atpos < 1 || ( dotpos - atpos < 2 ))
{
    alert("Please enter correct email ID")
    return false;
}

Andernfalls können Sie jQuery verwenden . Innerhalb Regeln definieren:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzist eine vollkommen gültige E-Mail, die von Ihrer Regex nicht erkannt wird.
Toto

3
Nein, ist es nicht. Das richtige E-Mail-Muster lautet "Something@something.something". Abc @ xyz stimmt nicht mit diesem Muster überein. Es ist also keine gültige Adresse.
Orchidee


5
Hast du die Wikipedia-Seite? Eine TLD ist ein gültiger Hostname. So abc@tldist eine gültige E-Mail-Adresse.
Toto

2
Die einzige Möglichkeit, eine E-Mail-Adresse zu überprüfen, besteht darin, eine E-Mail zu senden und auf die Antwort zu warten. Abgesehen davon finden Sie hier eine URL, unter der Sie testen können, ob Ihre Adresse RFC822-kompatibel ist: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Sie können sehen, dass abc @ xyz eine gültige Adresse für RFC822 ist.
Toto

14

Regex Update 2018! Versuche dies

let val = 'email@domain.com';
if(/^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val)) {
   console.log('passed');
}

Typoskript-Version abgeschlossen

//
export const emailValid = (val:string):boolean => /^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val);

Weitere Informationen https://git.io/vhEfc


Dies schlug für eine Standard-E-Mail@domain.com fehl
Ricks

1
@ RickS das stimmt einfach nicht. Bitte überprüfen Sie noch einmal
Malimo

13

Eine Lösung, die das Vorhandensein der TLD nicht überprüft, ist unvollständig.

Fast alle Antworten auf diese Fragen schlagen vor, Regex zur Validierung von E-Mail-Adressen zu verwenden. Ich denke, Regex ist nur für eine rudimentäre Validierung gut. Es scheint, dass die Überprüfung der Validierung von E-Mail-Adressen tatsächlich zwei separate Probleme darstellt:

1- Validierung des E-Mail-Formats: Stellen Sie sicher, dass die E-Mail dem Format und Muster der E-Mails in RFC 5322 entspricht und ob die TLD tatsächlich vorhanden ist. Eine Liste aller gültigen TLDs finden Sie hier .

Obwohl die Adresse example@example.cccden regulären Ausdruck übergibt, handelt es sich beispielsweise nicht um eine gültige E-Mail, da ccces sich bei IANA nicht um eine Top-Level-Domain handelt.

2- Sicherstellen , dass die E - Mail tatsächlich existiert: dies zu tun, ist die einzige Option ist den Benutzer eine E - Mail zu senden .


13

Regex zur Überprüfung der E-Mail-Adresse

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

Ich sehe Ihren regulären Ausdruck nicht in RFC5322: tools.ietf.org/html/rfc5322 - liegt ein Fehler vor?
Kamil Kiełczewski

"Bester Regex aller Zeiten"? Möglicherweise eine Erklärung hier?
Connectyourcharger

Warum hast du gesagt, dass dies die beste Lösung von allen ist? Kannst du bitte etwas mehr erklären?
Nancoder

Ich kann mich nicht erinnern, warum ich "bester Regex aller Zeiten" geschrieben habe. Sorry Leute, wenn dich das stört.
Prabhat Kasera

12

Hier ist eine sehr gute Diskussion über die Verwendung regulärer Ausdrücke zum Überprüfen von E-Mail-Adressen. " Vergleichen der E-Mail-Adresse zur Überprüfung regulärer Ausdrücke "

Hier ist der aktuelle Top-Ausdruck, der JavaScript-kompatibel ist, zu Referenzzwecken:

/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i

9
-1 Whitelisting lässt zu wünschen übrig - insbesondere haben Sie es verpasst .jobs. Darüber hinaus gibt es Live-IDNs (von denen die meisten, wie ich zugeben muss, erst nach Ihrem Posten offiziell genehmigt wurden - z. B. .中國im Juni 2010; die meisten sind jedoch seit Jahren in Arbeit).
Piskvor verließ das Gebäude am

2
-1 Verwenden Sie keine konstanten Top-Level-Domains. Es könnte immer (und es wird zum Beispiel 2013 sein) neues tld hinzugefügt werden.
Miho

Es gibt bestätigte 100 neue TLDs. Diese Antwort ist ungültig und sollte niemals verwendet werden.
Dean Meehan

Jep. Ich habe es 2011 gesagt, und ich werde es noch einmal sagen: Eine Whitelist mit "speziellen" Domains wird sich mit der Zeit nur verschlechtern, wenn mehr TLDs genehmigt werden. Es gibt mehr als 100 vollständig gültige TLDs, die nicht mit der obigen Whitelist übereinstimmen: en.wikipedia.org/wiki/List_of_Internet_top-level_domains
Piskvor verließ das Gebäude am

Es ist 2015. Dein Ausdruck ist nicht praktisch. Sie sollten diese Antwort notieren, aber Sie sind wahrscheinlich zu beschäftigt damit, alle Seiten zu reparieren, auf die Sie diesen Ausdruck setzen. Recht?
Eric Leroy


12

Im Gegensatz zu Squirtle gibt es hier eine komplexe Lösung, mit der E-Mails jedoch ordnungsgemäß validiert werden können:

function isEmail(email) { 
    return /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))$/i.test(email);
} 

Verwenden Sie wie folgt:

if (isEmail('youremail@yourdomain.com')){ console.log('This is email is valid'); }

10
Sie brauchen das nicht == trueauf Ihrem Beispiel.
Luke Alderton

11

Meine Kenntnisse über reguläre Ausdrücke sind nicht so gut. Deshalb überprüfe ich zuerst die allgemeine Syntax mit einem einfachen regulären Ausdruck und überprüfe anschließend spezifischere Optionen mit anderen Funktionen. Dies ist möglicherweise nicht die beste technische Lösung, aber auf diese Weise bin ich viel flexibler und schneller.

Die häufigsten Fehler, auf die ich gestoßen bin, sind Leerzeichen (insbesondere am Anfang und am Ende) und gelegentlich ein doppelter Punkt.

function check_email(val){
    if(!val.match(/\S+@\S+\.\S+/)){ // Jaymon's / Squirtle's solution
        // Do something
        return false;
    }
    if( val.indexOf(' ')!=-1 || val.indexOf('..')!=-1){
        // Do something
        return false;
    }
    return true;
}

check_email('check@thiscom'); // Returns false
check_email('check@this..com'); // Returns false
check_email(' check@this.com'); // Returns false
check_email('check@this.com'); // Returns true

10
<form name="validation" onSubmit="return checkbae()">
    Please input a valid email address:<br />

    <input type="text" size=18 name="emailcheck">
    <input type="submit" value="Submit">
</form>

<script language="JavaScript1.2">
    var testresults
    function checkemail(){
        var str = document.validation.emailcheck.value
        var filter = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i
        if (filter.test(str))
            testresults = true
        else {
            alert("Please input a valid email address!")
            testresults = false
        }
        return (testresults)
    }
</script>

<script>
    function checkbae(){
        if (document.layers || document.getElementById || document.all)
            return checkemail()
        else
            return true
    }
</script>

Vielleicht, wenn Sie eine Erklärung oder Beschreibung dazu hinzugefügt haben? Ich glaube nicht, dass Sie wirklich HTML zeigen müssen; Alles, was Menschen betrifft, ist das Javascript und der Regex. Wenn Sie Ihre Antwort nur auf das Jacascript reduzieren und dazu einen kleinen Klappentext hinzufügen, gebe ich Ihnen eine positive Bewertung.
bgmCoder

9

Ich habe nach einem Regex in JS gesucht, der alle Testfälle für E-Mail-Adressen besteht:

  • email@example.com Gültige E-Mail

  • firstname.lastname@example.com E-Mail enthält einen Punkt im Adressfeld

  • email@subdomain.example.com E-Mail enthält Punkt mit Subdomain

  • firstname+lastname@example.com Das Pluszeichen gilt als gültiges Zeichen

  • email@192.0.2.123 Domain ist gültige IP-Adresse

  • email@[192.0.2.123] Die eckige Klammer um die IP-Adresse gilt als gültig

  • “email”@example.com Zitate rund um E-Mail gelten als gültig

  • 1234567890@example.com Ziffern in der Adresse sind gültig

  • email@domain-one.example Ein Strich im Domainnamen ist gültig

  • _______@example.com Der Unterstrich im Adressfeld ist gültig

  • email@example.name .name ist ein gültiger Top Level Domain Name

  • email@example.co.jpPunkt im Top Level Domain Name wird ebenfalls als gültig angesehen (am co.jpBeispiel hier)

  • firstname-lastname@example.com Der Strich im Adressfeld ist gültig

Auf geht's :

http://regexr.com/3f07j

ODER Regex:

Regex = /(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@[*[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+]*/

8

Der reguläre Ausdruck, der von Microsoft in ASP.NET MVC bereitgestellt wird, lautet

/^[\w-]+(\.[\w-]+)*@([a-z0-9-]+(\.[a-z0-9-]+)*?\.[a-z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/

Was ich hier poste, falls es fehlerhaft ist - obwohl es immer perfekt für meine Bedürfnisse war.


1
Erlaubt keine + im Namensteil der E-Mail.
Paul Go
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.