Jakie znaki są dozwolone w adresie e-mail?

Nie pytam o pełną weryfikację adresu e-mail.

Chcę tylko wiedzieć, w jakie znaki są dozwolone user-namei jakie serverczęści adresu e-mail. Może to być zbyt uproszczone, może adresy e-mail mogą przybierać inne formy, ale mnie to nie obchodzi. Pytam tylko o tę prostą formę: user-name@server(np. [email protected]) i dozwolone znaki w obu częściach.

Patrz RFC 5322: Internetowy format wiadomości oraz, w mniejszym stopniu, RFC 5321: Simple Mail Transfer Protocol .

RFC 822 obejmuje również adresy e-mail, ale zajmuje się głównie jego 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

I jak zwykle Wikipedia ma porządny artykuł na temat adresów e-mail :

Lokalna część adresu e-mail może używać dowolnego z następujących znaków ASCII:

• wielkie i małe litery łacińskie Ado Zi ado z;
• cyfry 0do 9;
• znaki specjalne !#$%&'*+-/=?^_`{|}~;
• kropka ., pod warunkiem że nie jest to pierwszy lub ostatni znak, chyba że jest cytowany, oraz pod warunkiem, że nie pojawia się po kolei, chyba że jest cytowany (np. [email protected]nie jest dozwolony, ale "John..Doe"@example.comjest dozwolony);
• spacja i "(),:;<>@[\]znaki są dozwolone z ograniczeniami (są dozwolone tylko wewnątrz ciągu cytowanego, jak opisano w akapicie poniżej, a dodatkowo odwrotny ukośnik lub podwójny cudzysłów muszą być poprzedzone odwrotnym ukośnikiem);
• komentarze są dozwolone w nawiasach na obu końcach części lokalnej; np. john.smith(comment)@example.comi (comment)[email protected]oba są równoważne [email protected].

Oprócz znaków ASCII od 2012 r. Można używać znaków międzynarodowych powyżejU+007F , zakodowanych jako UTF-8, jak opisano w specyfikacji RFC 6532 i wyjaśniono na Wikipedii . Należy pamiętać, że od 2019 r. Standardy te są nadal oznaczone jako Proponowane, ale są wdrażane powoli. Zmiany w tym konkretnym dodaniu znaków międzynarodowych jako prawidłowych znaków alfanumerycznych (atext) bez wpływu na zasady dotyczące dozwolonych i ograniczonych znaków specjalnych, takich jak !#i @:.

Aby sprawdzić poprawność, zobacz Używanie wyrażenia regularnego do sprawdzania poprawności adresu e-mail .

domainCzęść jest określona w następujący sposób :

Standardy internetowe (Żądanie komentarzy) dotyczące protokołów wymagają, aby etykiety nazwy hosta komponentu mogły zawierać tylko litery ASCII aprzez z(bez rozróżniania wielkości liter), cyfry 0przez 9i łącznik ( -). Oryginalna specyfikacja nazw hostów w RFC 952 wymagała , aby etykiety nie zaczynały się cyfrą lub łącznikiem i nie mogły kończyć się łącznikiem. Jednak kolejna specyfikacja ( RFC 1123 ) zezwalała, aby etykiety nazw hostów zaczynały się od cyfr. Żadne inne symbole, znaki interpunkcyjne ani spacje są niedozwolone.

Uważaj! W tym wątku jest zgnilizna wiedzy (rzeczy, które kiedyś były prawdziwe, a teraz nie są).

Aby uniknąć fałszywie pozytywnych odrzuceń rzeczywistych adresów e-mail w obecnym i przyszłym świecie oraz z dowolnego miejsca na świecie, musisz znać przynajmniej ogólną koncepcję RFC 3490 „Internacjonalizacja nazw domen w aplikacjach (IDNA)”. Wiem, że ludzie w USA i A często tego nie lubią, ale jest to już szeroko rozpowszechnione i szybko rośnie na całym świecie (głównie części zdominowane przez język angielski).

Chodzi o to, że możesz teraz używać adresów takich jak mason @ 日本 .com i wildwezyr@fahrvergnügen.net. Nie, nie jest to jeszcze zgodne ze wszystkim, co istnieje (jak wielu lamentowało powyżej, nawet proste adresy w stylu qmail + identyfikatory są często błędnie odrzucane). Ale jest RFC, jest specyfikacja, jest teraz wspierany przez IETF i ICANN, a - co ważniejsze - istnieje duża i wciąż rosnąca liczba wdrożeń wspierających to ulepszenie, które są obecnie w użyciu.

Sam nie wiedziałem wiele o tym rozwoju, dopóki nie wróciłem do Japonii i nie zobaczyłem adresów e-mail takich jak hei @ や る .ca i adresów URL Amazon:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ク デ - デ ジ タ ル カ メ ラ - ポ ー タ ブ ル オ ー デ デ ィ オ / b / ref = topnav_storetab_e? ie = UTF8 & node = 3210981

Wiem, że nie chcesz linków do specyfikacji, ale jeśli polegasz wyłącznie na przestarzałej wiedzy hakerów na forach internetowych, Twój weryfikator wiadomości e-mail ostatecznie odrzuci adresy e-mail, których użytkownicy nieanglojęzyczni coraz częściej oczekują pracy. Dla tych użytkowników taka walidacja będzie tak samo denerwująca, jak powszechna, martwa mózg forma, której wszyscy nienawidzimy, ta, która nie może poradzić sobie z + lub trzyczęściową nazwą domeny lub czymkolwiek innym.

Nie mówię więc, że to nie jest kłopot, ale pełna lista znaków „dozwolona pod pewnymi / dowolnymi / żadnymi warunkami” to (prawie) wszystkie znaki we wszystkich językach. Jeśli chcesz „zaakceptować wszystkie prawidłowe adresy e-mail (a także wiele niepoprawnych)”, musisz wziąć pod uwagę IDN, co w zasadzie czyni podejście oparte na znakach bezużyteczne (przepraszam), chyba że najpierw przekształcisz międzynarodowe adresy e-mail na Punycode .

Po wykonaniu tej czynności możesz postępować zgodnie z (większością) powyższych rad.

Format adresu e-mail to: local-part@domain-part(maks. 64 @ 255 znaków, w sumie nie więcej niż 256).

local-partI domain-partmoże mieć inny zestaw dozwolonych znaków, ale to nie wszystko, ponieważ istnieje więcej zasad do niego.

Zasadniczo część lokalna może mieć następujące znaki ASCII:

• małe litery łacińskie litery: abcdefghijklmnopqrstuvwxyz,
• wielkie litery łacińskie litery: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• cyfry: 0123456789,
• Znaki szczególne: !#$%&'*+-/=?^_`{|}~,
• kropka: .(nie pierwszy lub ostatni znak lub powtarzany, chyba że jest cytowany),
• znaki przestankowe, takie jak: "(),:;<>@[\](z pewnymi ograniczeniami),
• komentarze: ()(są dozwolone w nawiasach, np (comment)[email protected].).

Część domeny:

• małe litery łacińskie litery: abcdefghijklmnopqrstuvwxyz,
• wielkie litery łacińskie litery: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• cyfry: 0123456789,
• łącznik: -(nie pierwszy lub ostatni znak),
• może zawierać adres IP otoczony nawiasami kwadratowymi: jsmith@[192.168.2.1]lub jsmith@[IPv6:2001:db8::1].

Te adresy e-mail są prawidłowe:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected] (jednoliterowa część lokalna)
• "much.more unusual"@example.com
• "[email protected]"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• [email protected]
• admin@mailserver1 (nazwa domeny lokalnej bez domeny najwyższego poziomu)
• #!$%&'*+-/=?^_`{}|[email protected]
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (odstęp między cytatami)
• example@localhost (wysłane z localhost)
• [email protected](patrz Lista internetowych domen najwyższego poziomu )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

A te przykłady nieważności:

• Abc.example.com(bez @postaci)
• A@b@[email protected](tylko jeden @znak jest dozwolony poza cudzysłowem)
• a"b(c)d,e:f;gi[j\k][email protected] (żaden ze znaków specjalnych w tej lokalnej części nie jest dozwolony poza cudzysłowami)
• just"not"[email protected] (ciągi cytowane muszą być oddzielone kropkami lub jedynym elementem tworzącym część lokalną)
• this is"not\[email protected] (spacje, cytaty i ukośniki odwrotne mogą istnieć tylko wtedy, gdy zawierają ciągi cudzysłowione i są poprzedzone ukośnikiem odwrotnym)
• this\ still\"not\[email protected] (nawet jeśli jest to znak ucieczki (poprzedzony odwrotnym ukośnikiem), spacje, cytaty i odwrotne ukośniki muszą być nadal zawarte w cudzysłowach)
• [email protected](podwójna kropka przed @); (z zastrzeżeniem: Gmail przepuszcza to)
• [email protected](podwójna kropka po @)
• poprawny adres ze spacją wiodącą
• prawidłowy adres ze spacją końcową

Źródło: adres e-mail z Wikipedii

Wyrażenie regularne RFC2822 Perla do sprawdzania poprawności wiadomości e-mail:

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

Pełne wyrażenie regularne dla adresów RFC2822 wyniosło zaledwie 3,7 tys.

Zobacz także: Parser adresów e-mail RFC 822 w PHP .

Formalne definicje adresów e-mail znajdują się w:

• RFC 5322 (sekcje 3.2.3 i 3.4.1, nieaktualne RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (dozwolone znaki).

Związane z:

• Prawdziwa moc wyrażeń regularnych

Wikipedia ma dobry artykuł na ten temat , a oficjalna specyfikacja jest tutaj . Z Wikipdii:

Lokalna część adresu e-mail może używać dowolnego z następujących znaków ASCII:

• Wielkie i małe litery angielskie (az, AZ)
• Cyfry od 0 do 9
• Postacie ! # $% I '* + - / =? ^ _ `{| } ~
• Postać . (kropka, kropka, kropka) pod warunkiem, że nie jest to pierwszy lub ostatni znak, i pod warunkiem, że nie pojawia się dwa lub więcej razy pod rząd.

Dodatkowo dozwolone są ciągi cytowane (np. „John Doe” @ example.com), co pozwala na znaki, które w innym przypadku byłyby zabronione, jednak nie pojawiają się w powszechnej praktyce. RFC 5321 ostrzega również, że „host, który spodziewa się otrzymywać pocztę, POWINIEN unikać definiowania skrzynek pocztowych, w których część lokalna wymaga (lub używa) formy ciągu cytowanego”.

Google robi ciekawą rzecz ze swoimi adresami gmail.com. Adresy gmail.com dopuszczają tylko litery (az), cyfry i kropki (które są ignorowane).

np. [email protected] jest taki sam jak [email protected], a oba adresy e-mail zostaną wysłane na tę samą skrzynkę pocztową. [email protected] jest również dostarczany do tej samej skrzynki pocztowej.

Tak więc, aby odpowiedzieć na pytanie, czasami zależy od implementatora, ile standardów RFC chcą przestrzegać. Styl adresu gmail.com firmy Google jest zgodny ze standardami. Robią to w ten sposób, aby uniknąć nieporozumień, gdy różne osoby wybierają podobne adresy e-mail, np

*** gmail.com accepting rules ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

Link do wikipedii jest dobrym źródłem informacji o tym, na co ogólnie pozwalają adresy e-mail. http://en.wikipedia.org/wiki/Email_address

Możesz zacząć od artykułu na Wikipedii :

• Wielkie i małe litery angielskie (az, AZ)
• Cyfry od 0 do 9
• Postacie ! # $% I '* + - / =? ^ _ `{| } ~
• Postać . (kropka, kropka, kropka) pod warunkiem, że nie jest to pierwszy lub ostatni znak, i pod warunkiem, że nie pojawia się dwa lub więcej razy pod rząd.

Imię:

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

Serwer:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Sprawdź @ i. a następnie wyślij im wiadomość e-mail w celu weryfikacji.

Nadal nie mogę używać mojego adresu e-mail .name w 20% witryn w Internecie, ponieważ ktoś spieprzył swoją weryfikację adresu e-mail lub ponieważ poprzedza to, że nowe adresy są prawidłowe.

Krótka odpowiedź jest taka, że ​​są 2 odpowiedzi. Jest jeden standard tego, co powinieneś zrobić. tj. zachowanie, które jest mądre i uchroni cię przed kłopotami. Istnieje inny (znacznie szerszy) standard zachowania, który powinieneś zaakceptować bez kłopotów. Ta dualność działa w przypadku wysyłania i przyjmowania wiadomości e-mail, ale ma szerokie zastosowanie w życiu.

Dobry przewodnik po twoich adresach; patrz: http://www.remote.org/jochen/mail/info/chars.html

Aby filtrować prawidłowe wiadomości e-mail, przekaż wszystko, co jest wystarczająco zrozumiałe, aby zobaczyć kolejny krok. Lub zacznij czytać kilka RFC, uwaga, tutaj będą smoki.

Dobra lektura w tej sprawie .

Fragment:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]

Przyjęta odpowiedź odnosi się do artykułu w Wikipedii podczas omawiania prawidłowej lokalnej części adresu e-mail, ale Wikipedia nie jest w tym zakresie autorytetem.

IETF RFC 3696 jest organem w tej sprawie i należy się z nim zapoznać w sekcji 3. Ograniczenia dotyczące adresów e-mail na stronie 5:

Współczesne adresy e-mail składają się z „części lokalnej” oddzielonej od „części domeny” (w pełni kwalifikowanej nazwy domeny) znakiem „at” („@”). Składnia części domeny odpowiada tej z poprzedniej sekcji. Obawy zidentyfikowane w tej sekcji dotyczące filtrowania i list nazw dotyczą również nazw domen używanych w kontekście wiadomości e-mail. Nazwę domeny można również zastąpić adresem IP w nawiasach kwadratowych, ale forma ta jest zdecydowanie odradzana, z wyjątkiem testów i rozwiązywania problemów.

Część lokalna może pojawić się przy użyciu konwencji cytowania opisanych poniżej. Cytowane formularze są rzadko stosowane w praktyce, ale są wymagane do niektórych uzasadnionych celów. Dlatego nie powinny być odrzucane w procedurach filtrowania, ale powinny być przekazywane do systemu poczty e-mail w celu oceny przez docelowego hosta.

Dokładna zasada jest taka, że ​​dowolny znak ASCII, w tym znaki kontrolne, może pojawiać się w cudzysłowie lub w ciągu cytowanym. Kiedy potrzebne jest cytowanie, znak cudzysłowu jest używany do cytowania następującego znaku. Na przykład

  Abc\@[email protected]

to poprawna forma adresu e-mail. Mogą również pojawić się puste miejsca, jak w

  Fred\ [email protected]

Znaku odwrotnego ukośnika można również użyć do zacytowania samego siebie, np.

  Joe.\\[email protected]

Oprócz cytowania za pomocą znaku odwrotnego ukośnika do otaczania ciągów można stosować konwencjonalne znaki podwójnego cudzysłowu. Na przykład

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

są alternatywnymi formami dwóch pierwszych przykładów powyżej. Te cytowane formularze są rzadko zalecane i są rzadkie w praktyce, ale, jak omówiono powyżej, muszą być obsługiwane przez aplikacje przetwarzające adresy e-mail. W szczególności cytowane formularze często pojawiają się w kontekście adresów związanych z przejściem z innych systemów i kontekstów; te przejściowe wymagania wciąż istnieją, a ponieważ system akceptujący podany przez użytkownika adres e-mail nie może „wiedzieć”, czy ten adres jest powiązany ze starszym systemem, formularze adresowe muszą zostać zaakceptowane i przekazane do środowiska pocztowego.

Bez cudzysłowów części lokalne mogą składać się z dowolnej kombinacji
znaków alfabetycznych, cyfr lub dowolnych znaków specjalnych

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

kropka („.”) może również pojawiać się, ale nie może być używana do rozpoczęcia lub zakończenia części lokalnej, ani też nie mogą pojawiać się dwa lub więcej kolejnych okresów. Inaczej mówiąc, dowolny znak graficzny (drukujący) ASCII inny niż znak at („@”), ukośnik odwrotny, cudzysłów, przecinek lub nawiasy kwadratowe mogą pojawiać się bez cudzysłowu. Jeśli ma się pojawić jakakolwiek lista wykluczonych znaków, należy ją zacytować. Formularze takie jak

  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]

są ważne i są widywane dość regularnie, ale każdy z wyżej wymienionych znaków jest dozwolony.

Podobnie jak inni, przesyłam wyrażenie regularne, które działa zarówno dla PHP, jak i JavaScript, aby zweryfikować adresy e-mail:

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

Jak można znaleźć w tym linku do Wikipedii

Lokalna część adresu e-mail może używać dowolnego z następujących znaków ASCII:

• wielkie i małe litery łacińskie Ado Zi ado z;

• cyfry 0do 9;

• znaki specjalne !#$%&'*+-/=?^_`{|}~;

• kropka ., pod warunkiem że nie jest to pierwszy lub ostatni znak, chyba że jest cytowany, oraz pod warunkiem, że nie pojawia się po kolei, chyba że jest cytowany (np. [email protected]nie jest dozwolony, ale "John..Doe"@example.comjest dozwolony);

• spacja i "(),:;<>@[\]znaki są dozwolone z ograniczeniami (są dozwolone tylko wewnątrz ciągu cytowanego, jak opisano w akapicie poniżej, a dodatkowo odwrotny ukośnik lub podwójny cudzysłów muszą być poprzedzone odwrotnym ukośnikiem);

• komentarze są dozwolone w nawiasach na obu końcach części lokalnej; np. john.smith(comment)@example.comi (comment)[email protected]oba są równoważne [email protected].

Oprócz powyższych znaków ASCII, znaki międzynarodowe powyżej U + 007F, zakodowane jako UTF-8, są dozwolone przez RFC 6531 , chociaż systemy pocztowe mogą ograniczać, których znaków należy używać podczas przypisywania części lokalnych.

Cytowany ciąg może istnieć jako jednostka oddzielona kropkami w części lokalnej lub może istnieć, gdy najbardziej zewnętrzne cytaty są zewnętrznymi znakami części lokalnej (np. abc."defghi"[email protected]Lub "abcdefghixyz"@example.comsą dozwolone. Przeciwnie, abc"defghi"[email protected]nie jest; żadna nie jest abc\"def\"[email protected]). Cytowane ciągi i znaki nie są jednak powszechnie używane. RFC 5321 ostrzega również, że „host, który spodziewa się otrzymywać pocztę, POWINIEN unikać definiowania skrzynek pocztowych, w których część lokalna wymaga (lub używa) formy ciągu cytowanego”.

Część lokalna postmasterjest traktowana specjalnie - bez rozróżniania wielkości liter i należy ją przekazać administratorowi poczty e-mail domeny. Z technicznego punktu widzenia wszystkie inne części lokalne uwzględniają wielkość liter [email protected]i [email protected]określają różne skrzynki pocztowe; jednak wiele organizacji traktuje wielkie i małe litery jako równoważne.

Pomimo szerokiej gamy znaków specjalnych, które są technicznie ważne; organizacje, usługi pocztowe, serwery pocztowe i klienci pocztowi w praktyce często nie akceptują wszystkich z nich. Na przykład usługa Windows Live Hotmail zezwala tylko na tworzenie adresów e-mail za pomocą znaków alfanumerycznych, kropek ( .), podkreślenia ( _) i łącznika ( -). Często zaleca się unikanie używania niektórych znaków specjalnych, aby uniknąć ryzyka odrzucenia wiadomości e-mail.

Odpowiedź brzmi (prawie) ALL(7-bitowy ASCII).
Jeśli reguły włączenia to „... dozwolone pod pewnymi / dowolnymi / żadnymi warunkami ...”

Wystarczy spojrzeć na jedną z kilku możliwych reguł włączenia dozwolonego tekstu w części „tekst domeny” w RFC 5322 u góry strony 17 i znajdujemy:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

jedyne trzy brakujące znaki w tym opisie są używane w literaturze domenowej [], tworząc parę w cudzysłowie \i znak spacji (% d32). Dzięki temu wykorzystywany jest cały zakres 32-126 (dziesiętny). Podobny wymóg pojawia się jako „qtext” i „ctext”. Wiele znaków kontrolnych jest również dozwolonych / używanych. Jedna lista takich znaków kontrolnych pojawia się na stronie 31 sekcja 4.1 RFC 5322 jako obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Wszystkie te znaki kontrolne są dozwolone, jak podano na początku sekcji 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

Taka zasada włączenia jest zatem „po prostu zbyt szeroka”. Lub, w innym sensie, oczekiwana zasada jest „zbyt uproszczona”.

Dla uproszczenia dezynfekuję przesyłanie, usuwając cały tekst z podwójnych cudzysłowów i powiązanych z nimi podwójnych cudzysłowów przed sprawdzeniem poprawności, umieszczając kibosh na przesyłanych adresach e-mail w oparciu o to, co jest niedozwolone. To, że ktoś może mieć Johna ... „The * $ hizzle * Bizzle” .. [email protected] adres nie oznacza, że ​​muszę pozwolić na to w moim systemie. Żyjemy w przyszłości, w której uzyskanie darmowego adresu e-mail może zająć mniej czasu niż wykonanie dobrej pracy wycierania tyłka. I nie jest tak, że kryteria e-mail nie są umieszczane obok danych wejściowych z informacją o tym, co jest i nie jest dozwolone.

Oczyszczam również to, co nie jest dozwolone przez różne RFC po usunięciu cytowanego materiału. Lista szczególnie niedozwolonych znaków i wzorców wydaje się być o wiele krótszą listą do przetestowania.

Niedozwolone:

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &’`*|/                          ( some&thing`[email protected] )
    more than one @                 ( which@[email protected] )
    :%                              ( mo:characters%mo:[email protected] )

W podanym przykładzie:

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

Wysłanie potwierdzającej wiadomości e-mail do resztkowego wyniku przy próbie dodania lub zmiany adresu e-mail to dobry sposób na sprawdzenie, czy kod obsługuje podany adres e-mail. Jeśli wiadomość e-mail przejdzie walidację po tylu rundach dezynfekcji, ile potrzeba, odpal to potwierdzenie. Jeśli żądanie powróci z linku potwierdzającego, nowy adres e-mail można przenieść ze stanu tymczasowego || czyśćca lub magazynu, aby stać się prawdziwym, przechowywanym w dobrej wierze e-mailem pierwszej klasy.

Powiadomienie o niepowodzeniu lub powodzeniu zmiany adresu e-mail może zostać wysłane na stary adres e-mail, jeśli chcesz się nad tym zastanowić. Niepotwierdzone ustawienia konta mogą wypaść z systemu, ponieważ nieudane próby całkowicie po rozsądnym czasie.

Nie zezwalam na e-maile śmierdzące w moim systemie, może to po prostu wyrzucanie pieniędzy. Ale w 99,9% przypadków ludzie po prostu postępują właściwie i mają wiadomości e-mail, które nie przekraczają granic zgodności na krawędzi, wykorzystując scenariusze zgodności z przypadkami granicznymi. Uważaj na regex DDoS, jest to miejsce, w którym możesz wpaść w kłopoty. Jest to związane z trzecią rzeczą, którą robię, ograniczam czas, przez jaki jestem gotów przetworzyć dowolny e-mail. Jeśli musi spowolnić mój komputer, aby zostać sprawdzonym - nie przechodzi poza logikę punktu końcowego interfejsu API danych przychodzących.

Edycja: Ta odpowiedź ciągle się wahała za to, że była „zła” i być może zasługiwała na to. Może nadal jest źle, a może nie.

W moim PHP używam tego czeku

<?php
if (preg_match(
'/^(?:[\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])\]))$/',
"tim'[email protected]"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

spróbuj sam http://phpfiddle.org/main/code/9av6-d10r

Utworzyłem ten regex zgodnie z wytycznymi RFC:

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

Gmail zezwala tylko na znak + jako znak specjalny, aw niektórych przypadkach (.), Ale żadne inne znaki specjalne nie są dozwolone w Gmailu. RFC mówi, że możesz używać znaków specjalnych, ale powinieneś unikać wysyłania poczty do Gmaila ze znakami specjalnymi.