Wie kann ich testen, ob eine Zeichenfolge eine E-Mail-Adresse für mein Webformular zu sein scheint? [closed]

Lesezeit: 10 Minuten

Ich möchte überprüfen, ob die Benutzereingabe eine E-Mail-Adresse in JavaScript ist, bevor ich sie an einen Server sende oder versuche, eine E-Mail an sie zu senden, um die grundlegendsten Tippfehler zu vermeiden. Wie könnte ich das erreichen?

  • @Alex Der Grund, warum ich diesen Kommentar hinzugefügt habe, ist, dass die vorgeschlagene Regex in der akzeptierten Antwort keine bestehenden Live-E-Mail-Adressen zulässt, was ein schlechter Start für einen Kunden ist, und das wirklich große Problem ist, dass selbst wenn die Adresse akzeptiert wurde, dies immer noch nicht der Fall ist sagen, ob es funktioniert. Die einzige Möglichkeit, zuverlässig zu überprüfen, ob eine bereitgestellte E-Mail eine funktionierende gültige E-Mail ist, besteht darin, eine E-Mail mit einem Bestätigungslink zu senden. Wenn Ihr Anwendungsfall also keine Verifizierung der E-Mail erfordert, führen Sie einfach einen minimalen Test für @ durch, andernfalls verwenden Sie eine Verifizierungs-E-Mail. Regex bietet nur eine schlechte Benutzererfahrung.

    – David Martensson

    3. Mai 2021 um 14:56 Uhr

  • @David Mårtensson Ich habe deinen Gedanken ein + hinzugefügt. Ich denke jedoch, dass eine Verifizierungs-E-Mail-Link-Sache auch eine schlechte Benutzererfahrung sein kann. Einer, der dazu führen kann, dass Sie einen Kunden verlieren.

    – mikael1000

    3. Juni 2021 um 10:22 Uhr


  • @mikael1000 Sicher, aber was ist der Zweck einer Regex-Validierung, wenn Sie sowieso nicht wissen, ob es sich um eine gültige E-Mail handelt. Wenn Sie den Kunden nicht mit einem Validierungslink aufdrängen wollen, führen Sie einfach die einfachste Validierung bei durch und belassen es dabei. Es wird sichergestellt, dass der Kunde zumindest etwas hinzugefügt hat, das eine E-Mail sein könnte, alles andere ist meistens eine Verschwendung von Code, bis Sie zur tatsächlichen Validierung kommen. Sie können möglicherweise mit einem DNS-Lookup überprüfen, ob die Domain existiert.

    – David Martensson

    4. Juni 2021 um 14:23 Uhr

  • @DavidMårtensson Ein Kunde, der ein Zeichen in seiner E-Mail falsch eingibt, wird dessen regulären Ausdruck validieren lassen, wenn es immer noch falsch ist. Das Ergebnis wird sein: nein Kommunikation möglich. Für mich ist das die schlimmste Benutzererfahrung, die man sich vorstellen kann. Eine Validierungsbestätigung wird den Benutzer in ein Gespräch verwickeln, das Respekt und echtes Interesse an den Kundenbedürfnissen zeigt.

    – der König2

    6. Dezember 2021 um 12:39 Uhr

  • Sehr ähnlich: Wie kann ich eine E-Mail-Adresse mit einem regulären Ausdruck validieren?

    – Peter Mortensen

    16. Februar um 23:18 Uhr

Verwenden Reguläre Ausdrücke ist wahrscheinlich der beste Weg. Sie können eine Reihe von Tests sehen hier (genommen von Chrom)

const validateEmail = (email) => {
  return String(email)
    .toLowerCase()
    .match(
      /^(([^<>()[\]\\.,;:\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,}))$/
    );
};

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

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

Aber denken Sie daran, dass man sich nicht nur auf die JavaScript-Validierung verlassen sollte. JavaScript kann einfach deaktiviert werden. Dies sollte auch auf der Serverseite validiert werden.

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

const validateEmail = (email) => {
  return email.match(
    /^(([^<>()[\]\\.,;:\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,}))$/
  );
};

const 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;
}

$('#email').on('input', validate);

Und das ist die html:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<label for="email">Enter an email address: </label>
<input id="email" />
<h2 id="result"></h2>

  • Diese Regex eliminiert gültige, verwendete E-Mails. Verwende nicht. Google nach “RFC822” oder “RFC2822”, um eine korrekte Regex zu erhalten.

    – Randal Schwartz

    8. September 2010 um 2:34 Uhr

  • 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 eine Regex, die keine gültigen Adressen ablehnt [^@]+@[^@]+\.[^@]+ und schützt vor häufigen Fehlern.

    – Vro

    26. Oktober 2012 um 6:32 Uhr


  • Sie können E-Mail-Adressen nicht validieren, Punkt. Die einzige Person, die eine E-Mail-Adresse validieren kann, ist der Anbieter der E-Mail-Adresse. Diese Antwort sagt beispielsweise 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.com sind alle gültig, aber Gmail lässt keine dieser E-Mail-Adressen zu. Sie sollten dies tun, indem Sie die E-Mail-Adresse akzeptieren und eine E-Mail-Nachricht an diese E-Mail-Adresse senden, mit einem Code/Link, den der Benutzer besuchen muss, um die Gültigkeit zu bestätigen.

    – Kevin Fegan

    1. Februar 2014 um 8:49 Uhr


  • @KevinFegan Seien wir realistisch: Sie würden kein JavaScript verwenden, um zu bestätigen, ob eine E-Mail authentisch ist. Ich sehe diese Validierung als durchaus sinnvoll an, wenn sich ein Benutzer anmeldet. Wahrscheinlich möchten Sie sich nicht die Mühe machen, Bestätigungs-E-Mails an Adressen zu senden, die unmöglich existieren können. Einige haben möglicherweise auch ausgehende E-Mail-Limits, sodass es sich lohnt, E-Mails an North zu senden email@localhost, i don't have an email oder irgendwelche anderen lustigen Benutzereingaben.

    – nicht definiert

    16. Juli 2021 um 23:02 Uhr

  • gautam+@Gmail.com – das Anzeigen ist gültig, was nicht sein sollte

    – Gautam Parmar

    6. August 2021 um 6:33 Uhr

Wow, hier gibt es viel Komplexität. Wenn Sie nur die offensichtlichsten Syntaxfehler abfangen möchten, würde ich so etwas 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.

BEARBEITEN: Wir können auch nach ‘.’ in der E-Mail mit

/^\S+@\S+\.\S+$/

  • Sie können etwas 20-mal so lange implementieren, was einigen Benutzern Probleme bereiten könnte und in Zukunft möglicherweise nicht mehr gültig ist, oder Sie können sich die Version von ImmortalFirefly schnappen, um sicherzustellen, dass sie sich zumindest die Mühe machen, es echt aussehen zu lassen. Abhängig von Ihrer Anwendung ist es wahrscheinlicher, dass jemand wütend wird, weil Sie seine unkonventionelle E-Mail nicht akzeptieren, als dass jemand Probleme verursacht, indem er E-Mail-Adressen eingibt, die nicht wirklich existieren (was er sowieso durch Eingabe tun kann eine 100 % gültige RFC2822-E-Mail-Adresse, aber mit einem nicht registrierten Benutzernamen oder einer nicht registrierten Domäne). Upvoted!

    – user83358

    30. Juli 2012 um 18:20 Uhr


  • @ImmortalFirefly, die von Ihnen bereitgestellte Regex 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 des Textes ‘^’ und das Ende des Textes ‘$’ erfordern würde. Die, die ich verwende, ist /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')

    – OregonTrail

    9. August 2012 um 14:58 Uhr

  • Der zweite reguläre Ausdruck erfordert keine Top-Level-Domain, dh er akzeptiert user@domain. Aber AFAIK ist dies tatsächlich eine gültige E-Mail-Adresse, obwohl dies ungewöhnlich ist. Der erste reguläre Ausdruck erfordert eine TLD, sodass diese Arten von Adressen nicht abgedeckt werden.

    – Waldgeist

    15. Juli 2021 um 13:00 Uhr

  • E-Mails können mehrere enthalten @ Zeichen (als Kommentar), auch eine E-Mail muss keinen Punkt enthalten.

    – Ruola

    6. Oktober 2021 um 14:08 Uhr

  • @JoseG. Ja. Z.B http://ai ist jemandes gültige Domäne, also könnte er zB verwenden a@ai als ihre E-Mail.

    – Ruola

    10. Februar um 9:42 Uhr

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 Verknüpfung

Von dem HTML5-Spezifikation:

EIN Gültige E-Mail-Adresse ist eine Zeichenfolge, die mit der übereinstimmt email Produktion des folgenden ABNF, 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 ist a vorsätzliche Verletzung des RFC 5322, der eine Syntax für E-Mail-Adressen definiert, die gleichzeitig zu streng (vor dem “@”-Zeichen), zu vage (nach dem “@”-Zeichen) und zu lax (Kommentare, Leerzeichen und Anführungszeichen zulassen) ist Zeichenfolgen in einer den meisten Benutzern ungewohnten Weise), 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])?)*$/

Nur der Vollständigkeit halber, Hier haben Sie eine weitere RFC 2822-kompatible Regex

Der offizielle Standard ist bekannt als RFC-2822. Es beschreibt die Syntax, die gültige E-Mail-Adressen einhalten müssen. Sie können (aber das solltest du nichtweiter lesen) implementieren Sie 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])+)\])

(…) Eine praktischere Implementierung von RFC 2822 erhalten wir, wenn wir die Syntax mit doppelten Anführungszeichen und eckigen Klammern weglassen. Es stimmt immer noch mit 99,99 % aller E-Mail-Adressen überein, 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önnten, besteht darin, jede aus zwei Buchstaben bestehende Top-Level-Domain mit Ländercode zuzulassen und nur bestimmte generische Top-Level-Domains. Diese Regex filtert Dummy-E-Mail-Adressen wie asdf@adsf.adsf. Du muss aktualisiert werden, 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 bei Einhaltung offizieller Standards müssen also immer noch Kompromisse eingegangen 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.

Betonung von mir

  • NB: „Im tatsächlichen Gebrauch heute” kann gültig gewesen sein, als der Code geschrieben wurde, damals im Jahr 200x. Der Code Wille wahrscheinlich über dieses bestimmte Jahr hinaus in Gebrauch bleiben. (Wenn ich einen Cent für jedes “meh, niemand wird jemals eine TLD mit 4 oder mehr Buchstaben verwenden, außer diesen spezifischen”, die ich reparieren müsste, hätte ich den Kupfer- und Nickelmarkt der Welt in die Enge ;))

    – Piskvor verließ das Gebäude

    13. Juni 2012 um 15:51 Uhr


  • Beachten Sie, dass dies einige gültige E-Mail-Adressen wie diese Emoji-Adressen nicht erfasst: mailoji.com

    – Toasttrackenigma

    6. Oktober 2021 um 1:28 Uhr

1010380cookie-checkWie kann ich testen, ob eine Zeichenfolge eine E-Mail-Adresse für mein Webformular zu sein scheint? [closed]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy