Jakie znaki są dozwolone w adresie e-mail?


639

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. Wild.wezyr@best-server-ever.com) i dozwolone znaki w obu częściach.


184
+Jest dozwolone. Doprowadza mnie to do szału, gdy strony internetowe na to nie pozwalają, ponieważ mój e-mail ma +w sobie taką zawartość, a wiele stron na to nie pozwala.
Dan Herbert

42
Myślę, że ważne jest, aby podawać linki do specyfikacji, ponieważ naprawdę chcesz to zrobić poprawnie i właśnie tam pojawia się specyfikacja. Jeśli jesteś zbyt leniwy, aby przeczytać i zrozumieć specyfikację, pozostaw zaznaczenie dozwolonych znaków w adresach e-mail dla ludzi, którym zależy na tym stuf.
jhwist

9
Wcześniejsze pytanie dotyczące tego samego materiału: stackoverflow.com/questions/760150/ . Smutne jest to, że chociaż to pytanie jest prawie 8 miesięcy starsze od tego, starsze pytanie ma znacznie lepsze odpowiedzi. Prawie wszystkie poniższe odpowiedzi były już nieaktualne, kiedy zostały pierwotnie opublikowane. Zobacz wpis w Wikipedii (i nie martw się, ma on odpowiednie oficjalne referencje ).
John Y

10
W przeciwieństwie do kilku odpowiedzi, w lokalnej części adresów e-mail dozwolone spacje , jeśli są cytowane. "hello world"@example.comjest ważny.
user253751

3
@LaraRuffleColes - Podczas tworzenia konta e-mail w Gmailu nie można tworzyć adresów zawierających znak „+”. Znak „+” („Adresowanie plus”) pozwala każdemu, kto ma adres Gmail, dodać znak „+”, a następnie „ciąg” na końcu nazwy użytkownika, aby utworzyć adres e-mail „alternatywny” („alias”) do korzystania z ich konta. Przykład: „example@gmail.com”, „example+tag@gmail.com”. Typowym (i prawdopodobnie „podstawowym”) zastosowaniem tego jest możliwość tworzenia aliasowych adresów e-mail dla twojego konta, które pozwalają na oznaczanie i filtrowanie przychodzących wiadomości e-mail, teoretycznie filtrowanych przez nadawcę.
Kevin Fegan

Odpowiedzi:


797

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. John..Doe@example.comnie 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)john.smith@example.comoba są równoważne john.smith@example.com.

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.


15
@WildWzyr, To nie jest takie proste. Adresy e-mail mają wiele reguł dotyczących dozwolonych. Łatwiej jest odwołać się do specyfikacji, niż wymienić wszystkie z nich. Jeśli chcesz mieć pełny Regex, sprawdź tutaj, aby dowiedzieć się, dlaczego nie jest to takie proste: regular-expressions.info/email.html
Dan Herbert

6
nie ma prostej listy, tylko dlatego, że chcesz czegoś prostego, nie oznacza, że ​​tak będzie. niektóre postacie mogą znajdować się tylko w niektórych lokalizacjach, a nie w innych. nie możesz mieć tego, co chcesz cały czas.

15
@WildWezyr Cóż, kropka jest dozwolona w części lokalnej. Ale nie na początku ani na końcu. Lub z innym kropką. Tak więc odpowiedź NIE JEST tak prosta, jak tylko lista dozwolonych znaków, istnieją zasady dotyczące sposobu używania tych znaków - .ann..other.@example.comnie jest prawidłowym adresem e-mail, ale ann.other@example.comjest, mimo że oba używają tych samych znaków.
Mark Pim,

14
Pamiętaj też, że wraz z nadejściem nazw domen internacjonalizowanych lista dozwolonych znaków wybuchnie.
Chinmay Kanchi

50
To nie jest już prawidłowa odpowiedź z powodu międzynarodowych adresów. Zobacz odpowiedź Masona.
ZacharyP,

329

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.


17
Dobrze; za kulisami nazwy domen wciąż są tylko ASCII. Ale jeśli twoja aplikacja internetowa lub formularz akceptuje dane wprowadzone przez użytkownika, musi wykonać to samo zadanie, co przeglądarka internetowa lub klient poczty, gdy użytkownik wprowadza nazwę hosta IDN: aby przekonwertować dane wejściowe użytkownika na formę zgodną z DNS. Następnie sprawdź poprawność. W przeciwnym razie te międzynarodowe adresy e-mail nie przejdą weryfikacji. (Konwertery takie jak ten, który podłączyłem, aby modyfikować tylko znaki, które nie są ASCII, które są im podane, więc można bezpiecznie używać ich na nienależących do internacjonalizmu adresach e-mail (są one zwracane bez modyfikacji).)
Mason

2
Dla deweloperów Javascript badam teraz metody, aby to zrobić, a Punycode.js wydaje się być najbardziej kompletnym i dopracowanym rozwiązaniem.
wwaawaw

5
Należy pamiętać, że internacjonalizowana poczta e-mail (zgodnie z obecnie zdefiniowaną definicją) nie konwertuje adresów spoza ASCII przy użyciu kodu punycode lub podobnego, zamiast tego rozszerza duże części samego protokołu SMTP, aby używać UTF8.
IMSoP

2
Czy coś pomijam, czy to nie odpowiada na pytanie? Czytam „druga odpowiedź jest nieprawidłowa, musisz zaakceptować więcej znaków”, ale potem nie określa, które dodatkowe znaki. Nie mogłem (łatwo) zobaczyć w tym dokumencie RFC, czy oznacza to wszystkie punkty kodu Unicode, czy tylko BMP.
Samuel Harmer,

3
Wydaje się, że jest to właściwa droga do poprawnej odpowiedzi. Założę się, że zyskałbyś o wiele więcej głosów, gdybyś podał szczegóły dotyczące zarezerwowanych i dozwolonych postaci.
Sean

59

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)john.smith@example.com.).

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:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (jednoliterowa część lokalna)
  • "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 (nazwa domeny lokalnej bez domeny najwyższego poziomu)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (odstęp między cytatami)
  • example@localhost (wysłane z localhost)
  • example@s.solutions(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@c@example.com(tylko jeden @znak jest dozwolony poza cudzysłowem)
  • a"b(c)d,e:f;gi[j\k]l@example.com (żaden ze znaków specjalnych w tej lokalnej części nie jest dozwolony poza cudzysłowami)
  • just"not"right@example.com (ciągi cytowane muszą być oddzielone kropkami lub jedynym elementem tworzącym część lokalną)
  • this is"not\allowed@example.com (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\allowed@example.com (nawet jeśli jest to znak ucieczki (poprzedzony odwrotnym ukośnikiem), spacje, cytaty i odwrotne ukośniki muszą być nadal zawarte w cudzysłowach)
  • john..doe@example.com(podwójna kropka przed @); (z zastrzeżeniem: Gmail przepuszcza to)
  • john.doe@example..com(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:


5
Jako dodatkową przestrogę dla przyszłych implementatorów tego wyrażenia regularnego: nie. Po prostu sprawdź, czy odpowiada formatowi something@something.somethingi nazwij go dzień.
Chris Sobolewski,

Chociaż czegoś takiego nie
da się

@ChrisSobolewski zezwala na wiele elementów po obu stronach „@”
Jasen

Próbowałem zaimplementować to w Postfiksie poprzez tabelę dostępu do pcre pod ograniczeniem check_recipient_access, najpierw zamieniając 3 długie pcres (z połączonej strony) w jedną linię i dodając w ten sposób: /^[...pcre ..] $ / DUNNO, a następnie dodając ostatni wiersz /.*/ REJECT, ale nadal pozwala na nieprawidłowe adresy e-mail. Postfix 3.3.0; perl 5, wersja 26, subversion 1 (v5.26.1).
scoobydoo

3
Mówię szaleństwo. Kto kiedykolwiek użyje go w produkcji. W pewnym momencie nie należy już używać wyrażeń regularnych. To daleko poza ten punkt.
tomuxmon

22

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”.


@WildWezyr Prawidłowe nazwy hostów, którymi może być adres IP, FQN lub coś, co można rozwiązać z hostem sieci lokalnej.
JensenDied

Cytowane struny były niezbędne do przejścia przez bramę, pamiętasz Banyana Vinesa?
mckenzm

13

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

np. pikachu@gmail.com jest taki sam jak pi.kachu@gmail.com, a oba adresy e-mail zostaną wysłane na tę samą skrzynkę pocztową. PIKACHU@gmail.com 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 ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (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


2
Tak, to świetna odpowiedź na pytanie, dlaczego Gmail nie zezwala na TWORZENIE wiadomości e-mail w ten sposób. Ale {john'doe}@my.serverbez problemu możesz wysyłać i odbierać wiadomości e-mail . Testowane również z serwerem hMail.
Piotr Kula

Możesz przetestować swojego klienta, wysyłając wiadomość e-mail na adres {piotr'kula}@kula.solutions- jeśli zadziała, otrzymasz od niego ładną automatyczną odpowiedź. W przeciwnym razie nic się nie wydarzy.
Piotr Kula

3
Gmail postępuje zgodnie z RFC 6530 w tym sensie, że każdy możliwy adres e-mail dozwolony przez Gmaila jest ważny zgodnie z RFC. Gmail po prostu decyduje o dalszym ograniczeniu zestawu dozwolonych adresów za pomocą dodatkowych reguł i tworzeniu podobnych adresów z kropkami w części lokalnej, opcjonalnie po nich „+” i znaki alfanumeryczne, synonimami.
Teemu Leisti,

Google ogranicza kryteria tworzenia konta ... Wyobrażam sobie, że szorują ciąg przychodzącego konta e-mail z dodatkową „interpunkcją” i znakiem końcowym oraz poprzedzonym znakiem ciągu aliasu, aby poczta mogła zostać przekierowana na właściwe konto. Bułka z masłem. W ten sposób skutecznie nie pozwalają ludziom tworzyć adresów e-mail typu „szarpanie się”, tak aby utworzone prawidłowe adresy często przechodziły proste i najbardziej złożone weryfikacje.
BradChesney79

To nie tylko Gmail, niektórzy dostawcy mają „filtry przekazujące”, które odrzucają niektóre cytowane ciągi, w szczególności zawierające „=” tak, jakby były ogranicznikami. Ma to na celu zablokowanie użytkownikom konfigurowania bram i zagnieżdżania adresów spamowych w prywatnym cytowanym ciągu. „@” jest prawidłowe, ale „= @ =” nie jest (uważane) za prawidłowe.
mckenzm,

12

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.

11

Imię:

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

Serwer:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Co z <>i []? Np. "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Proszę cytować źródła. Bez źródeł wygląda to jak przypuszczenie.
Mathieu K.,

15
To jest nieaktualne i prawdopodobnie nigdy nie było poprawne.
Jason Harrison,

9

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.


9
Parzysty . nie jest absolutnie konieczne; Słyszałem o co najmniej jednym przypadku adresu e-mail w domenie najwyższego poziomu (konkretnie ua). Adres to <nazwa> @ua - bez kropki!

Jest to prawie najłatwiejszy sposób, aby nie zepsuć sprawdzania poprawności, ponieważ prawie wszystko jest dozwolone, a jeśli coś nie jest dozwolone, serwer odbiorcy poinformuje Cię o tym.
Avamander

5

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.


Link zniknął. Co tam było?
ygoe

5

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/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Zastanawiałem się nad „@” przed częścią domeny. Czy można tego użyć?
Saiyaff Farouk

@SaiyaffFarouk zgodnie ze specyfikacją, tak. Jednak większość dostawców poczty prawdopodobnie nie zezwoli na to w ramach własnej weryfikacji
Luke Madhanga

ten blog zawiera listy Joe.\\Blow@example.combez cytatów. Czy to jest rzeczywiście ważne? Nie wydaje się jasne, biorąc pod uwagę odpowiedzi tutaj, ale pytam, ponieważ widziałem (bardzo rzadkie) przypadki ciągów adresów e-mail nazw DNS SoA zawierających odwrotne ukośniki.
wesinat0r

5

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\@def@example.com

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

  Fred\ Bloggs@example.com

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

  Joe.\\Blow@example.com

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

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

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

3

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. John..Doe@example.comnie 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)john.smith@example.comoba są równoważne john.smith@example.com.

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".xyz@example.comLub "abcdefghixyz"@example.comsą dozwolone. Przeciwnie, abc"defghi"xyz@example.comnie jest; żadna nie jest abc\"def\"ghi@example.com). 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 jsmith@example.comi JSmith@example.comokreś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.


0

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”.


0

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” .. Doe@whokolwiek.com 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 ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

W podanym przykładzie:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

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.


2
Wydaje mi się, że ta odpowiedź została odrzucona, ponieważ jest to opinia i tak naprawdę nie odpowiada na pytanie. Poza tym użytkownicy, którzy po cichu oczyszczą swój adres e-mail, nigdy nie otrzymają od ciebie wiadomości e-mail. Lepiej poinformuj ich, że ich adres e-mail nie jest akceptowany.
vcarel

2
Podejrzewam, że opinie są negatywne, ponieważ jest tutaj zbyt wiele pomysłów. Niedozwolona lista, mimo że są to przydatne testy jednostkowe, powinna być poprzedzona tym, co jest dozwolone. Podejście programistyczne wydaje się względnie dobre, ale prawdopodobnie lepiej by pasowało po podaniu specyfikacji, z którymi pracujesz itp. Pomogą w tym sekcje i łagodne edytowanie kopii. Tylko moje 2 centy.
HoldOffHunger,

@vcarel - Och, absolutnie. Sprawdzanie poprawności po stronie użytkownika poinformuje ich, jakie zasady (dostępne z etykietki) łamią. Masz rację - to ogólna opinia. Jednak powyższe pytanie pochodzi od osoby, która z pewnością prosi X o pytanie Y. To jest wskazówka i działa ... nie tylko działa, działa dobrze. Nie pozwalam bzdurnym adresom e-mail w moich systemach, w których podejmuję decyzje.
BradChesney79,

@HoldOffHunger Widzę, że ogólna idea nie jest tak spójnie wyrażona, jak mogłaby być, mogę dokonać korekty w innym dniu, w którym mam więcej czasu, aby lepiej to wyrazić. Dzięki za wgląd.
BradChesney79,

-1

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'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

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


-1

Utworzyłem ten regex zgodnie z wytycznymi RFC:

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

1
Ta wersja poprawia wyrażenie regularne, sprawdzając długość domeny / subdomen. Cieszyć się! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? (?: \\. [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.