Der vollständig RFC 822-konforme Regex ist aufgrund seiner Länge ineffizient und undurchsichtig. Glücklicherweise wurde RFC 822 zweimal ersetzt und die aktuelle Spezifikation für E-Mail-Adressen lautet RFC 5322. RFC 5322 führt zu einem Regex, der verstanden werden kann, wenn er für ein paar Minuten untersucht wird und effizient genug für den tatsächlichen Gebrauch ist. Laden Sie zunächst eine Reihe gültiger und ungültiger Beispieldaten in das Tool. In diesem Fall handelt es sich um eine Liste gültiger E-Mail-Adressen und eine Liste ungültiger E-Mail-Adressen. Eine E-Mail-Adresse wie John.Smith@example.com besteht aus einem lokalen Teil, einem Symbol mit der Anzeige, und dann aus einer Domäne ohne Groß-/Kleinschreibung. Obwohl der Standard[1] vorschreibt, dass der lokale Teil die Groß-/Kleinschreibung berücksichtigt, wird auch darauf hingewiesen, dass empfangende Hosts Nachrichten in einer fallunabhängigen Weise übermitteln[2], z. B., dass das Mailsystem bei example.com John.Smith als john.smith gleichzustellen; einige Postsysteme behandeln sie sogar als gleichwertig mit Johnsmith. [3] E-Mail-Systeme beschränken die Namenswahl ihrer Nutzer oft auf eine Teilmenge der technisch gültigen Zeichen und beschränken in einigen Fällen auch die Adressen, an die E-Mails gesendet werden können. In dieser Antwort nehme ich „E-Mail-Adresse“ als addr-spec, wie in den RFCs definiert (d.h.
jdoe@example.org, aber nicht „John Doe“ jdoe@example.org>, noch einige-group:jdoe@example.org,mrx@exampel.org;). Wenn Sie nach E-Mail-Adressen in größeren Textkörpern suchen möchten, anstatt zu überprüfen, ob es sich bei der Eingabe als Ganzes um eine E-Mail-Adresse handelt, können Sie die Anker „“ und „“““ nicht verwenden. Das bloße Entfernen der Anker aus dem regulären Ausdruck ist nicht die richtige Lösung. Wenn Sie dies mit dem endgültigen Regex tun, der die Top-Level-Domain auf Buchstaben beschränkt, entspricht sie beispielsweise john@doe.com in john@doe.com77. Anstatt die Regex-Übereinstimmung am Anfang und am Ende des Betreffs zu verankern, müssen Sie angeben, dass der Anfang des lokalen Teils und der Domäne der obersten Ebene nicht Teil längerer Wörter sein dürfen. Bei der Zustellung von E-Mails verwendet ein SMTP-Client, z. B. Mail User Agent (MUA), Mail Transfer Agent (MTA), das Domain Name System (DNS), um einen Ressourceneintrag (RR) für die Domäne des Empfängers (den Teil der E-Mail-Adresse rechts neben dem Wenn ein E-Mail-Austausch-Ressourceneintrag (MX-Eintrag) vorhanden ist, enthält der zurückgegebene MX-Eintrag den Namen des Mailservers des Empfängers, andernfalls verwendet der SMTP-Client einen Adressdatensatz (A oder AAAA).
Der MTA stellt als nächstes eine Verbindung zu diesem Server als SMTP-Client her. Der lokale Teil einer E-Mail-Adresse hat keine Bedeutung für andere Zwischen-Mail-Relay-Systeme als den endgültigen Postfachhost. E-Mail-Absender und Zwischenrelaissysteme dürfen nicht davon ausgehen, dass die S-Groß-/Kleinschreibung nicht berücksichtigt wird, da der endgültige Postfachhost sie möglicherweise als solche behandelt. Ein einzelnes Postfach kann E-Mails für mehrere E-Mail-Adressen empfangen, sofern vom Administrator konfiguriert. Umgekehrt kann eine einzelne E-Mail-Adresse der Alias für eine Verteilerliste für viele Postfächer sein. E-Mail-Aliasnamen, elektronische Mailinglisten, Unteradressierung und Catch-All-Adressen, wobei letztere Postfächer sind, die Nachrichten unabhängig vom lokalen Teil empfangen, sind häufige Muster zum Erreichen einer Vielzahl von Übermittlungszielen. Der Domänenname, der Teil nach dem Zeichen . Internationalisierte Domänennamen sind nicht zulässig. Der lokale Teil, der Teil vor dem Zeichen , ist auf Zeichen beschränkt, die häufig in lokalen E-Mail-Teilen verwendet werden, was restriktiver ist, als die meisten E-Mail-Clients und -Server akzeptieren: Die maximale Gesamtlänge des lokalen Teils einer E-Mail-Adresse beträgt 64 Oktette. [9] Auf einem modernen PC oder Server wird dieser Regex bei der Validierung einer einzigen 254-stelligen E-Mail-Adresse gut funktionieren. Das Ablehnen längerer Eingaben wäre sogar schneller, da der Regex fehlschlägt, wenn das Lookahead beim ersten Durchgang fehlschlägt.
Aber ich würde nicht empfehlen, einen regex so komplex wie dieser zu verwenden, um nach E-Mail-Adressen durch ein großes Archiv von Dokumenten oder Korrespondenz zu suchen.