856 Stimmen

Welche Zeichen sind in einer E-Mail-Adresse erlaubt?

Ich frage nicht nach einer vollständigen E-Mail-Validierung.

Ich möchte nur wissen, welche Zeichen in user-name y server Teile der E-Mail Adresse. Das ist vielleicht zu vereinfacht, vielleicht können E-Mail-Adressen auch andere Formen annehmen, aber das ist mir egal. Ich frage nur nach dieser einfachen Form: user-name@server (z. B. wild.wezyr@best-server-ever.com) und erlaubte Zeichen in beiden Teilen.

267 Stimmen

Le site + erlaubt ist. Es macht mich wahnsinnig, wenn Websites dies nicht zulassen, weil meine E-Mail eine + und viele Websites erlauben dies nicht.

0 Stimmen

Ich habe gerade ein Kopfgeld ausgesetzt. Es gibt bereits gute Antworten, aber sie erklären nicht, welche Zeichen im Serverteil der E-Mail-Adresse erlaubt sind. Ich werde eine vollständige Antwort auf meine Fragen akzeptieren (Benutzername und Serverteil erklärt).

0 Stimmen

Vielleicht auch RFC2821 und RFC2822 .

1005voto

Anton Gogolev Punkte 109749

Siehe RFC 5322: Internet-Nachrichtenformat und, in geringerem Maße, RFC 5321: Simple Mail Transfer Protocol .

RFC 822 befasst sich auch mit E-Mail-Adressen, aber hauptsächlich mit deren Struktur:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

Und wie immer hat Wikipedia eine gute Artikel über E-Mail-Adressen :

Der lokale Teil der E-Mail-Adresse kann jedes dieser ASCII-Zeichen verwenden:

  • lateinische Groß- und Kleinbuchstaben A a Z y a a z ;
  • Ziffern 0 a 9 ;
  • Sonderzeichen !#$%&'*+-/=?^_`{|}~ ;
  • Punkt . sofern es nicht das erste oder letzte Zeichen ist, es sei denn, es wird zitiert, und sofern es nicht fortlaufend erscheint, es sei denn, es wird zitiert (z. B. John..Doe@example.com ist nicht erlaubt, aber "John..Doe"@example.com ist erlaubt);
  • Raum und "(),:;<>@[\] Zeichen sind mit Einschränkungen erlaubt (sie sind nur innerhalb einer Zeichenkette in Anführungszeichen erlaubt, wie im folgenden Absatz beschrieben, und außerdem muss einem Backslash oder doppelten Anführungszeichen ein Backslash vorausgehen);
  • Kommentare sind mit Klammern an beiden Enden des lokalen Teils erlaubt; z. B. john.smith(comment)@example.com y (comment)john.smith@example.com sind beide gleichwertig mit john.smith@example.com .

Zusätzlich zu den ASCII-Zeichen, ab 2012 Sie können die internationale Zeichen oben U+007F , kodiert als UTF-8 wie in der RFC 6532-Spezifikation und erklärt auf Wikipedia . Beachten Sie, dass diese Standards ab 2019 immer noch als "Proposed" gekennzeichnet sind, aber langsam eingeführt werden. Die Änderungen in dieser Spezifikation fügten im Wesentlichen internationale Zeichen als gültige alphanumerische Zeichen (atext) hinzu, ohne die Regeln für erlaubte und eingeschränkte Sonderzeichen zu beeinflussen, wie !# y @: .

Für die Validierung, siehe Verwendung eines regulären Ausdrucks zur Validierung einer E-Mail Adresse .

Le site domain Teil ist definiert wie folgt :

Die Internet-Standards (Request for Comments) für Protokolle schreiben vor, dass die Bezeichnungen der Komponenten-Hostnamen nur die ASCII-Buchstaben enthalten dürfen a über z (Groß- und Kleinschreibung wird nicht berücksichtigt), die Ziffern 0 über 9 und der Bindestrich ( - ). Die ursprüngliche Spezifikation von Hostnamen in RFC 952 wurde festgelegt, dass Etiketten weder mit einer Ziffer noch mit einem Bindestrich beginnen und auch nicht mit einem Bindestrich enden dürfen. Allerdings wurde eine spätere Spezifikation ( RFC 1123 ) erlaubte, dass Hostnamenbezeichnungen mit Ziffern beginnen. Andere Symbole, Interpunktionszeichen oder Leerzeichen sind nicht erlaubt.

24 Stimmen

@WildWzyr, So einfach ist das nicht. Für E-Mail-Adressen gibt es eine Reihe von Regeln, was erlaubt ist. Es ist einfacher, sich auf die Spezifikation zu beziehen, als sie alle aufzulisten. Wenn du die komplette Regex haben willst, schau hier nach, um eine Vorstellung davon zu bekommen, warum es nicht so einfach ist: reguläre-ausdrücke.info/email.html

6 Stimmen

Es gibt keine einfache liste. nur weil du etwas einfach haben willst, heißt das nicht, dass es auch so sein wird. manche zeichen können nur an bestimmten orten sein und an anderen nicht. du kannst nicht immer haben, was du willst.

16 Stimmen

@WildWezyr Nun, das Punktzeichen ist im Lokalteil erlaubt. Aber nicht am Anfang oder Ende. Oder mit einem anderen Punkt. Die Antwort ist also NICHT so einfach wie eine Liste der erlaubten Zeichen, sondern es gibt Regeln, wie diese Zeichen verwendet werden dürfen. .ann..other.@example.com ist keine gültige E-Mail-Adresse, sondern ann.other@example.com ist, auch wenn beide die gleichen Zeichen verwenden.

401voto

Mason Punkte 4753

Aufgepasst! In diesem Thread gibt es einen Haufen verrottetes Wissen (Dinge, die früher wahr waren und jetzt nicht mehr wahr sind).

Um falsch-positive Ablehnungen von tatsächlichen E-Mail-Adressen in der heutigen und zukünftigen Welt zu vermeiden, müssen Sie zumindest das allgemeine Konzept von RFC 3490 Internationalisierung von Domain-Namen in Anwendungen (IDNA)". Ich weiß, dass die Leute in den USA und A oft nicht auf dem Laufenden sind, aber es ist bereits in weit verbreitete und rasch zunehmende Nutzung in der ganzen Welt (vor allem in den nicht englischsprachigen Teilen).

Das Wesentliche ist, dass Sie jetzt Adressen wie mason@.com und wildwezyr@fahrvergnügen.net verwenden können. Nein, das ist noch nicht mit allem kompatibel, was es gibt (wie viele oben beklagt haben, werden sogar einfache +ident-Adressen im Stil von qmail oft fälschlicherweise abgelehnt). Aber es gibt ein RFC, es gibt eine Spezifikation, es wird jetzt von der IETF und ICANN unterstützt, und - was noch wichtiger ist - es gibt eine große und wachsende Anzahl von Implementierungen, die diese Verbesserung unterstützen und derzeit in Betrieb sind.

Ich wusste selbst nicht viel über diese Entwicklung, bis ich nach Japan zurückkehrte und anfing, E-Mail-Adressen wie hei@.ca und Amazon-URLs wie diese zu sehen:

http://www.amazon.co.jp/--/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

Ich weiß, dass Sie keine Links zu Spezifikationen wollen, aber wenn Sie sich ausschließlich auf das veraltete Wissen von Hackern in Internetforen verlassen, wird Ihr E-Mail-Validator am Ende E-Mail-Adressen ablehnen, von denen nicht-englischsprachige Benutzer zunehmend erwarten, dass sie funktionieren. Für diese Benutzer wird eine solche Überprüfung genauso lästig sein wie das alltägliche hirntote Formular, das wir alle hassen, das nicht mit einem + oder einem dreiteiligen Domänennamen oder was auch immer umgehen kann.

Damit will ich nicht sagen, dass es kein Problem ist, aber die vollständige Liste der Zeichen, die "unter einigen/allen/keinen Bedingungen zulässig sind", umfasst (fast) alle Zeichen in allen Sprachen. Wenn Sie "alle gültigen E-Mail-Adressen (und auch viele ungültige)" akzeptieren wollen, müssen Sie IDN berücksichtigen, was einen zeichenbasierten Ansatz im Grunde nutzlos macht (sorry), es sei denn, Sie machen zuerst die internationalisierten E-Mail-Adressen konvertieren (tot seit September 2015, war früher ein wie diese -eine funktionierende Alternative ist aquí ) an Punycode .

Danach können Sie die obigen Ratschläge (größtenteils) befolgen.

0 Stimmen

Sind Sie sicher, dass diese zusätzlichen Zeichen an die Server gesendet und von diesen verarbeitet werden? Soweit ich weiß, werden internationalisierte Domänennamen von Browsern (Protokoll-Clients, nicht von Servern) verarbeitet.

20 Stimmen

Richtig, hinter den Kulissen sind die Domänennamen noch immer nur ASCII. Aber wenn Ihre Webanwendung oder Ihr Formular Benutzereingaben akzeptiert, muss es die gleiche Aufgabe erfüllen wie der Webbrowser oder der E-Mail-Client, wenn der Benutzer einen IDN-Hostnamen eingibt: die Benutzereingabe in eine DNS-kompatible Form umwandeln. Dann validieren. Andernfalls werden diese internationalisierten E-Mail-Adressen Ihre Validierung nicht bestehen. (Konverter wie der, den ich verlinkt habe, ändern nur die Nicht-ASCII-Zeichen, die sie erhalten, so dass es sicher ist, sie für nicht-internationalisierte E-Mail-Adressen zu verwenden (diese werden einfach unverändert zurückgegeben).

1 Stimmen

Sie haben Recht, dass die anderen Antworten hier veraltete Informationen enthalten. Und es ist nicht nur die Domain, die gesamte Adresse kann UTF-8 sein. (Siehe meinen Kommentar zur Hauptfrage für weitere Hinweise).

106voto

kenorb Punkte 134883

Das Format der E-Mail-Adresse lautet: local-part@domain-part (max. 64@255 Zeichen, nicht mehr als 256 insgesamt).

Le site local-part y domain-part könnte verschiedene zulässige Zeichen haben, aber das ist noch nicht alles, denn es gibt noch mehr Regeln dafür.

Im Allgemeinen kann der lokale Teil diese ASCII-Zeichen enthalten:

  • lateinische Kleinbuchstaben: abcdefghijklmnopqrstuvwxyz ,
  • lateinische Großbuchstaben: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • Ziffern: 0123456789 ,
  • Sonderzeichen: !#$%&'*+-/=?^_`{|}~ ,
  • Punkt: . (nicht das erste oder letzte Zeichen oder die Wiederholung, außer in Anführungszeichen),
  • Interpunktionszeichen wie: "(),:;<>@[\] (mit einigen Einschränkungen),
  • Kommentare: () (sind innerhalb von Klammern erlaubt, z. B. (comment)john.smith@example.com ).

Teil des Bereichs:

  • lateinische Kleinbuchstaben: abcdefghijklmnopqrstuvwxyz ,
  • lateinische Großbuchstaben: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • Ziffern: 0123456789 ,
  • Bindestrich: - (nicht erstes oder letztes Zeichen),
  • kann die IP-Adresse in eckigen Klammern enthalten: jsmith@[192.168.2.1] o jsmith@[IPv6:2001:db8::1] .

Diese E-Mail-Adressen sind gültig:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (einbuchstabiger Ortsteil)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (lokaler Domänenname ohne Top-Level-Domäne)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (Leerzeichen zwischen den Anführungszeichen)
  • example@localhost (gesendet von localhost)
  • example@s.solutions (siehe die Liste der Internet-Top-Level-Domains )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

Und diese Beispiele sind ungültig:

  • Abc.example.com (nein @ Zeichen)
  • A@b@c@example.com (nur eine @ ist außerhalb der Anführungszeichen erlaubt)
  • a"b(c)d,e:f;gi[j\k]l@example.com (keines der Sonderzeichen in diesem lokalen Teil ist außerhalb der Anführungszeichen erlaubt)
  • just"not"right@example.com (in Anführungszeichen gesetzte Zeichenfolgen müssen durch Punkte getrennt sein oder das einzige Element sein, aus dem der lokale Teil besteht)
  • this is"not\allowed@example.com (Leerzeichen, Anführungszeichen und Backslashes dürfen nur innerhalb von Zeichenketten in Anführungszeichen und mit vorangestelltem Backslash vorkommen)
  • this\ still\"not\allowed@example.com (Leerzeichen, Anführungszeichen und Backslashes müssen in Anführungszeichen gesetzt werden, auch wenn sie durch einen Backslash ersetzt werden)
  • john..doe@example.com (Doppelpunkt vor @ ); (mit Vorbehalt: Gmail lässt dies durch)
  • john.doe@example..com (Doppelpunkt nach @ )
  • eine gültige Adresse mit einem führenden Leerzeichen
  • eine gültige Adresse mit einem Leerzeichen am Ende

Quelle: E-Mail Adresse bei Wikipedia


Perl's RFC2822 Regex für die Validierung von E-Mails:

(?:(?:\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*)

Der vollständige Regexp für RFC2822-Adressen umfasste lediglich 3,7k.

Siehe auch: RFC 822 E-Mail-Adressen-Parser in PHP .


Die formalen Definitionen von E-Mail-Adressen sind vorhanden:

  • RFC 5322 (Abschnitte 3.2.3 und 3.4.1, obsolete RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (zulässige Zeichen).

Verwandt:

23 Stimmen

Als zusätzliche Warnung für potenzielle Implementierer dieser Regex: Tun Sie es nicht. Vergewissern Sie sich einfach, dass sie dem Format folgt something@something.something und machen Feierabend.

1 Stimmen

So etwas ist zwar nicht wartbar, aber es ist eine nette Übung, um herauszufinden, was es tut

0 Stimmen

@ChrisSobolewski mehrere Irgendetwas auf beiden Seiten des '@' zulassen

26voto

Mike Weller Punkte 44986

Wikipedia hat einen guten Artikel zu diesem Thema y Die offizielle Spezifikation finden Sie hier . Von Wikipdia:

Der lokale Teil der E-Mail-Adresse kann jedes dieser ASCII-Zeichen verwenden:

  • Englische Groß- und Kleinbuchstaben (a-z, A-Z)
  • Ziffern 0 bis 9
  • Zeichen ! # $ % & ' * + - / = ? ^ _ ` { | } ~
  • Zeichen . (Punkt, Punkt, Punkt), sofern es nicht das erste oder letzte Zeichen ist und sofern es nicht zwei- oder mehrmals hintereinander vorkommt.

Darüber hinaus sind Zeichenketten in Anführungszeichen (z. B. "John Doe"@example.com) erlaubt, so dass Zeichen zulässig sind, die sonst verboten wären, die aber in der Praxis nicht vorkommen. RFC 5321 warnt auch, dass "ein Host, der erwartet, Post zu empfangen, es vermeiden sollte, Postfächer zu definieren, bei denen der lokale Teil die Form "Quoted-string" erfordert (oder verwendet)".

0 Stimmen

@WildWezyr Gültige Hostnamen, bei denen es sich um eine IP-Adresse, einen FQN oder einen in einen lokalen Netzwerkhost auflösbaren Namen handeln kann.

0 Stimmen

Zitierte Schnüre waren unerlässlich, um ein Tor zu durchschreiten, erinnern Sie sich an Banyan Vines?

17voto

Mac Punkte 1157

Die akzeptierte Antwort bezieht sich auf einen Wikipedia-Artikel, wenn es um den gültigen lokalen Teil einer E-Mail-Adresse geht, aber Wikipedia ist keine Autorität auf diesem Gebiet.

IETF RFC 3696 ist eine Behörde zu diesem Thema und sollte unter folgender Adresse konsultiert werden 3. Beschränkungen für E-Mail-Adressen auf Seite 5:

Moderne E-Mail-Adressen bestehen aus einem "lokalen Teil", der von einem einem "Domänenteil" (vollqualifizierter Domänenname) durch ein At-Zeichen ("@"). Die Syntax des Domänenteils entspricht derjenigen im vorherigen Abschnitt. Die in diesem Abschnitt genannten Bedenken hinsichtlich der Filterung und und Namenslisten gelten auch für Domänennamen, die in einem E-Mail-Kontext ebenfalls. Der Domänenname kann auch durch eine IP-Adresse ersetzt werden in eckigen Klammern ersetzt werden, aber von dieser Form wird dringend abgeraten, außer für Test- und Fehlerbehebungszwecken.

Der lokale Teil kann unter Verwendung der beschriebenen Anführungszeichen-Konventionen erscheinen unten beschrieben. Die zitierten Formen werden in der Praxis selten verwendet, sind aber für einige legitime Zwecke erforderlich. Daher sollten sie nicht in Filterroutinen zurückgewiesen werden, sondern sollten stattdessen an das E-Mail-System weitergeleitet werden zur Auswertung durch den Zielhost weitergeleitet werden.

Die genaue Regel lautet, dass jedes ASCII-Zeichen, einschließlich Steuerzeichen Zeichen, in Anführungszeichen oder in einer Zeichenkette in Anführungszeichen erscheinen kann. Wenn Anführungszeichen erforderlich ist, wird das Backslash-Zeichen verwendet, um das folgende Zeichen in Anführungszeichen Zeichen. Zum Beispiel

  Abc\@def@example.com

ist eine gültige Form einer E-Mail-Adresse. Es können auch Leerzeichen erscheinen, wie in

  Fred\ Bloggs@example.com

Das Backslash-Zeichen kann auch verwendet werden, um sich selbst zu zitieren, z. B.,

  Joe.\\Blow@example.com

Neben der Verwendung des Backslash-Zeichens können auch herkömmliche doppelte Anführungszeichen verwendet werden, um Zeichenketten zu umschließen. Zum Beispiel

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

sind alternative Formen der ersten beiden obigen Beispiele. Diese zitierten Formen werden selten empfohlen und sind in der Praxis unüblich, müssen aber, wie erörtert, müssen sie von Anwendungen unterstützt werden, die E-Mail-Adressen verarbeiten. Insbesondere erscheinen die zitierten Formen oft im Zusammenhang mit Adressen, die mit Übergängen aus anderen Systemen und Kontexten verbunden sind; diese Übergangsanforderungen treten immer noch auf und, da ein System, das eine vom Benutzer bereitgestellte E-Mail-Adresse akzeptiert, nicht nicht "wissen" kann, ob diese Adresse mit einem Altsystem verknüpft ist, muss die müssen die Adressformulare akzeptiert und in die E-Mail-Umgebung übertragen werden.

Ohne Anführungszeichen können die lokalen Teile aus einer beliebigen Kombination von alphabetischen Zeichen, Ziffern oder einem der Sonderzeichen

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

Punkt (".") kann ebenfalls erscheinen, darf aber nicht als Anfang oder Ende den lokalen Teil zu beginnen oder zu beenden, noch dürfen zwei oder mehr aufeinanderfolgende Punkte erscheinen. Anders ausgedrückt, jedes grafische ASCII-Zeichen (Druckzeichen) mit Ausnahme von das at-Zeichen ("@"), der Backslash, das doppelte Anführungszeichen, das Komma oder die eckigen Klammern kann ohne Anführungszeichen erscheinen. Wenn eines der in dieser Liste ausgeschlossenen Zeichen auftauchen, müssen sie in Anführungszeichen gesetzt werden. Formulare wie

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

sind gültig und werden ziemlich regelmäßig gesehen, aber jedes der oben aufgeführten Zeichen sind erlaubt.

Wie andere schon getan haben, reiche ich eine Regex ein, die sowohl für PHP als auch für JavaScript funktioniert, um E-Mail-Adressen zu validieren:

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

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X