Regexp Anerkennung von E-Mail-Adresse hart?
https://stackoverflow.com/questions/156430
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Vor kurzem habe ich irgendwo gelesen, dass eine regexp schreiben eine E-Mail-Adresse entspricht, unter Berücksichtigung alle Varianten und Möglichkeiten der Standard extrem hart und ist wesentlich komplizierter als das, was man zunächst annehmen.
Kann jemand etwas Einblick schaffen, warum das so ist?
Gibt es bekannte und bewährte regexps, die tatsächlich das tun vollständig?
Was sind einige gute Alternativen zur Verwendung von regulären Ausdrücken für passende E-Mail-Adressen?
Lösung
Für die formal E-Mail-spec, ja, es ist technisch unmöglich, über Regex aufgrund der Rekursion von Dingen wie Kommentare (vor allem, wenn Sie Kommentare nicht entfernen zuerst Leerzeichen) und die verschiedene Formate (eine E-Mail-Adresse ist nicht immer someone@somewhere.tld). Sie können nahe kommen (mit einigen massiven und unverständlich Regex-Mustern), aber eine viel bessere Möglichkeit, eine E-Mail zu prüfen ist, die sehr vertraut Händedruck zu tun:
- sagen sie, ihre E-Mail
- Sie ihnen eine confimation Verbindung mit einem Guid E-Mail
-
, wenn sie auf den Link klicken Sie, dass:
- die E-Mail korrekt ist
- es existiert
- Sie besitzen es
Viel besser als blind eine E-Mail-Adresse zu akzeptieren.
Andere Tipps
Es gibt eine Reihe von Perl-Modulen (zum Beispiel), die dies tut. Versuchen Sie nicht, und Ihre eigenen regulären Ausdruck schreiben, es zu tun. Schauen Sie sich
Mail::VRFY tun Syntax und Netzwerküberprüfungen (tut und SMTP-Server irgendwo akzeptieren diese Adresse)
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address - a. Rekursiven Abstieg E-Mail-Adresse Parser
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address - regexp-basierte Adressvalidierung, lohnt ein Blick auf nur für die wahnsinnige regexp
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
ähnliche Tools geben sich für andere Sprachen. Insane regexp unten ...
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
Validieren von E-Mail-Adressen sind nicht wirklich sowieso sehr hilfreich. Es wird nicht gemeinsame Tippfehler oder konfektionierten E-Mail-Adressen fangen, da diese syntaktisch wie gültige Adressen suchen neigen.
Wenn Sie eine Adresse gültig ist sicher sein wollen, Sie haben keine andere Wahl, als eine Bestätigungsmail zu senden.
Wenn Sie nur sicher sein wollen, dass die Benutzereingaben etwas, das wie eine E-Mail sieht nicht nur „asdf“, dann für ein @ überprüfen. Komplexere Validierung bietet keine wirklich keinen Nutzen.
(Ich weiß, dass dies nicht Ihre Fragen nicht beantworten, aber ich denke, es lohnt sich zu erwähnen sowieso)
Ich habe nun Testfälle von Cal Henderson, Dave Kind, Phil Haack, Doug Lovell und RFC 3696. 158 Testadressen in allen zusammengefasst.
Ich lief all diese Tests gegen alle Validatoren ich finden konnte. Der Vergleich ist hier: http://www.dominicsayers.com/isemail
Ich werde versuchen, diese Seite zu halten up-to-date wie die Menschen ihre Validatoren verbessern. Dank Cal, Dave und Phil für ihre Hilfe und Zusammenarbeit in diesen Tests und konstruktive Kritik von meine eigenen Validator .
sollten Menschen sich bewusst sein errata gegen RFC 3696 insbesondere . Drei der kanonischen Beispiele sind in der Tat ungültige Adressen. Und die maximale Länge einer Adresse ist 254 oder 256 Zeichen, nicht 320.
Es ist nicht alles Unsinn obwohl, wie so dass Zeichen wie ‚+‘ kann für Benutzer Bekämpfung Spam sehr nützlich sein, zum Beispiel myemail+sketchysite@gmail.com ( Instant-Einweg-Gmail-Adressen )
Nur wenn eine Website es akzeptiert though.
Es gibt eine kontextfreie Grammatik in BNF, die gültigen E-Mail-Adressen in RFC-2822 . Es ist komplex. Zum Beispiel:
" @ "@example.com
ist eine gültige E-Mail-Adresse. Ich weiß nicht von irgendwelchen regexps, dass es voll zu tun; die Beispiele in der Regel gegeben erfordern Kommentare zuerst abisoliert werden. Ich schrieb einen rekursiven Abstiegs-Parser es einmal vollständig zu tun.
Ob oder nicht akzeptieren, bizarr, ungewöhnlich E-Mail-Adressformate ab, meiner Meinung nach, auf dem, was man will, mit ihnen zu tun.
Wenn Sie einen Mail-Server schreiben, müssen Sie sehr genau sein und quälend richtig in was Sie akzeptieren. Das "insane" regex oben zitierte ist daher angebracht.
Für den Rest von uns, aber wir sind in erster Linie nur daran interessiert, dass etwas ein Benutzer in einem Web-Formular vernünftig aussieht und nicht über irgendeine Art von SQL-Injection oder Pufferüberlauf in es.
Ehrlich gesagt, ist es egal jemand wirklich über das Lassen jemand eine 200-Zeichen-E-Mail-Adresse eingeben mit Kommentaren, Zeilenumbrüche, Zitate, Leerzeichen, Klammern oder andere Kauderwelsch, wenn für eine Mailingliste, Newsletter, oder auf der Website anmelden? Die richtige Antwort auf eine solche Clowns ist „später Komm wieder, wenn Sie eine Adresse haben, wie username@domain.tld aussieht“.
Die Validierung ich tun besteht, sicherzustellen, dass es genau eine ‚@‘; dass es keine Leerzeichen, Nullen oder Zeilenumbrüche; daß der Teil rechts von der ‚@‘ mindestens einen Punkt (aber nicht zwei Punkte in einer Reihe); und dass es keine Anführungszeichen, Klammern, Kommata, Doppelpunkte, Ausrufe, Semikolons oder Schrägstriche, von denen alle sind eher Versuche hackery sein, als Teile einer tatsächlichen E-Mail-Adresse.
Ja, das bedeutet ich die Ablehnung gültige Adressen, mit denen jemand versuchen könnte auf meinen Web-Site registrieren - vielleicht ich „falsch“ zurückweisen, so viele wie 0,001% der realen Adressen! Ich kann damit leben.
Zitiert und verschiedene andere selten verwendet, aber gültige Teile des RFC es schwer machen. Ich weiß nicht genug über dieses Thema endgültig Stellung zu nehmen, anders als „es ist schwer“ - aber zum Glück andere Menschen haben darüber ausführlich geschrieben .
Wie auf einen gültigen regulären Ausdruck dafür, die Perl-Mail :: rfc822 :: Adressmodul enthält ein regulärer Ausdruck, die offenbar funktioniert - aber nur, wenn keine Kommentare bereits durch Leerzeichen ersetzt. (Kommentare in einer E-Mail-Adresse? Sie sehen, warum es schwieriger ist, als man erwarten würde ...)
Natürlich sind die vereinfachten Regexes die an anderer Stelle gibt es zuhauf validiert fast jede E-Mail-Adresse, die tatsächlich verwendet wird ...
Einige Aromen von regex kann tatsächlich verschachtelten Klammern entsprechen (zum Beispiel Perl kompatibel sind). Das heißt, ich habe einen regulären Ausdruck gesehen, die richtig passen RFC behauptet, 822 und es war zwei Seiten Text ohne Leerzeichen. Daher ist der beste Weg, um eine gültige E-Mail-Adresse zu erkennen, ist E-Mail an sie zu senden und sehen, ob es funktioniert.
Sie einfach einen regulären Ausdruck hinzuzufügen, die weniger verrückt als die von @mmaibaum aufgeführt:
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
Es ist nicht kugelsicher, und schon gar nicht die gesamte E-Mail-spec decken, aber es hat die für die meisten grundlegenden Anforderungen einen anständigen Job zu tun. Noch besser ist, es ist etwas verständlich und kann bearbeitet werden.
cribbed aus einer Diskussion unter HouseOfFusion.com , eine Weltklasse-Coldfusion-Ressource.
Eine einfache und gute Möglichkeit, E-Mail-Adressen in Java zu überprüfen, ist den EmailValidator der Apache Commons Validator zu verwenden Bibliothek.
Ich würde immer eine E-Mail-Adresse in einer Eingabeform gegen so etwas wie dies überprüfen, bevor eine E-Mail zu senden - auch wenn Sie nur ein paar Tippfehler fangen. Sie wollen wahrscheinlich nicht ein automatisiertes Scanner für „die Lieferung nicht“ Benachrichtigungs-Mails zu schreiben. : -)
Es ist wirklich schwer, weil es eine Menge Dinge gibt, die in einer E-Mail-Adresse nach der E-Mail-Spec, RFC 2822 . Dinge, die Sie normalerweise nicht wie + sehen sind perfekt gültige Zeichen für eine E-Mail-Adresse .. nach dem spec.
Es gibt einen ganzen Abschnitt gewidmet Adressen eine E-Mail an http://regexlib.com , die eine große Ressource ist. Ich würde vorschlagen, dass Sie bestimmen, welche Kriterien für Sie wichtig und finden, das passt. Die meisten Menschen nicht wirklich brauchen volle Unterstützung für alle von der Spezifikation erlaubt Möglichkeiten.
Wenn Sie auf dem .NET Framework laufen lassen, nur versuchen, ein MailAddress Objekt zu erhalten und fangen die FormatException wenn es bläst, oder die Address herausziehen, wenn es gelingt. Ohne in jeden Unsinn über die Leistung Ausnahmen zu fangen (wirklich, wenn dies nur auf einer einzigen Web ist bilden es wird nicht so viel von einem Unterschied machen), die MailAddress Klasse in dem .NET-Framework geht durch eine ziemlich vollständige Analyse Prozess (es verwendet kein RegEx). Aufmachen Reflektor und die Suche nach MailAddress und MailBnfHelper.ReadMailAddress() um zu sehen, all die fancy stuff es tut. Jemand klüger als ich viel Zeit bauen, dass Parser bei Microsoft verbrachte, werde ich es benutzen, wenn ich tatsächlich eine E-Mail an diese Adresse senden, so könnte ich auch verwenden, um die eingehende Adresse zu validieren, zu.
Viele haben versucht, und viele nahe kommen. Sie können die Wikipedia-Artikel und einige andere .
Insbesondere möchten Sie daran erinnern, dass viele Websites und E-Mail-Server Validierung von E-Mail-Adressen gelockert haben, so im Wesentlichen nicht implementiert den Standard vollständig. Es ist gut genug für E-Mail, obwohl die ganze Zeit zu arbeiten.
Versuchen Sie dieses:
"(?:[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])+)\])"
Hier finden Sie aktuelle hier für die Details.
Doch anstatt die RFC822 Norm umgesetzt, vielleicht wäre es besser, es aus einem anderen Blickwinkel zu betrachten. Es spielt eigentlich keine Rolle, was der Standard sagt, wenn E-Mail-Server nicht den Standard spiegeln. Deshalb würde ich behaupten, dass es besser wäre, zu imitieren, was der beliebtestene Mail-Server tun, wenn E-Mail-Adressen zu validieren.
Diese Klasse für Java hat einen Validator darin: http://www.leshazlewood.com/?p=23
Dies wird durch die Schöpfer von Shiro geschrieben (formal Ki, formal JSecurity)
Die Vor- und Nachteile der Tests für E-Mail-Adresse Gültigkeit:
Es gibt zwei Arten von regulären Ausdrücken, die E-Mails bestätigen:
- Diejenigen, die zu locker sind.
-
Diejenigen, die zu streng sind.
Es ist nicht möglich, dass ein regulärer Ausdruck alle gültigen E-Mail-Adressen übereinstimmen und keine E-Mail-Adressen, die nicht gültig sind, weil einige Strings wie gültige E-Mail-Adressen aussehen könnte, aber tatsächlich gehen nicht zu jedermann Posteingang. Der einzige Weg, um zu sehen, zu testen, ob eine E-Mail tatsächlich gültig ist, ist eine E-Mail an diese Adresse zu senden und sehen, ob Sie irgendeine Art von Antwort. Mit dem im Verstand, reguläre Ausdrücke, die zu streng sind an passenden E-Mail scheinen nicht wirklich viel von einem Zweck zu haben.
Ich denke, dass die meisten Menschen, die für einen E-Mail-Regex bitten für die erste Option suchen, regulären Ausdrücke, die zu locker sind. Sie wollen einen String testen und sehen, ob es sieht aus wie eine E-Mail, wenn es definitiv nicht eine E-Mail, dann können sie sagen, für den Benutzer: „Hey, Sie sollen hier eine E-Mail setzen und dies ist definitiv keine gültige E-Mail. vielleicht haben Sie nicht erkennen, dass dieses Feld für eine E-Mail oder vielleicht gibt es einen Tippfehler“.
Wenn ein Benutzer in einer Zeichenfolge setzt, die viel wie eine gültige E-Mail aussieht, aber es ist eigentlich nicht ein, dann ist das ein Problem, das durch einen anderen Teil der Anwendung behandelt werden soll.
Kann jemand bietet einen Einblick, warum das so ist?
Ja, es ist ein äußerst komplizierter Standard, der viele Sachen erlaubt, die niemand wirklich heute verwendet. :)
Gibt es bekannte und regexps bewiesen, dass diese vollständig eigentlich tun?
Hier ist einen Versuch, den ganzen Standard vollständig zu analysieren ...
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
Was sind einige gute Alternativen zur Verwendung von regulären Ausdrücken für passende E-Mail-Adressen?
Mit einem bestehenden Rahmen für die es in welcher Sprache Sie verwenden, ich denke? Obwohl diese werden wahrscheinlich regexp intern verwenden. Es ist eine komplexe Zeichenfolge. Regexps sind so ausgelegt, komplexe Zeichenfolge zu analysieren, so dass wirklich die beste Wahl.
Bearbeiten : Ich sollte hinzufügen, dass die regexp ich nur zum Spaß verbunden war. Ich unterstütze nicht eine komplexe regexp wie das mit - einige Leute sagen, dass, „wenn Ihr regexp mehr als eine Zeile ist, ist es garantiert einen Fehler in ihm irgendwo haben“. Ich mit ihm verbunden zu veranschaulichen, wie komplex die Norm ist.
Zusätzlich zu Wayne die Antwort, gibt es auch einen Abschnitt www.regular-expressions.info gewidmet eine E-Mail mit ein paar Proben.
Sie können immer die Frage, ob es sich lohnt, oder wenn in der Tat jeder weniger als 100% -covering regexp trägt nur zu einem falschen Gefühl der Sicherheit.
Am Ende tatsächlich Senden die E-Mail ist es, was die wirkliche endgültige Validierung liefern. (-You'll herauszufinden, ob Ihr Mail-Server hat Fehler; -)
Für Vollständigkeit dieser Post, auch für PHP gibt es eine Sprache integrierte Funktion E-Mails zu überprüfen.
Für PHP Verwenden Sie die schöne filter_var mit dem spezifischen E-MAIL Prüfungstyp:)
No more insane E-Mail Regexes in php: D
var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));
