Bir e-posta adresinde hangi karakterlere izin verilir?

Tam e-posta doğrulaması hakkında soru sormuyorum.

Sadece izin verilen karakterlerin user-nameve servere-posta adresinin bölümlerinin neler olduğunu bilmek istiyorum . Bu aşırı basitleştirilmiş olabilir, belki e-posta adresleri başka biçimler alabilir, ama umrumda değil. Sadece bu basit formu soruyorum: user-name@server(örn. Wild.wezyr@best-server-ever.com) ve her iki kısımda da izin verilen karakterler.

Bkz. RFC 5322: Internet İleti Biçimi ve daha az ölçüde RFC 5321: Basit Posta Aktarım Protokolü .

RFC 822 ayrıca e-posta adreslerini de kapsar, ancak çoğunlukla yapısı ile ilgilenir:

 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

Ve her zamanki gibi, Wikipedia'nın e-posta adresleri hakkında iyi bir makalesi var :

E-posta adresinin yerel kısmı şu ASCII karakterlerinden herhangi birini kullanabilir:

• büyük harfe ve Latin harfleri küçük harfe Akadar Zve ahiç z;
• parmaklara 0için 9;
• özel karakterler !#$%&'*+-/=?^_`{|}~;
• dot .o alıntı ve (örneğin alıntılanan sürece ardışık görünmüyor olması da temin sürece ilk veya son karakter değil şartıyla, John..Doe@example.comizin verilmez ancak "John..Doe"@example.comizin verilir);
• boşluklara ve "(),:;<>@[\]karakterlere kısıtlamalarla izin verilir (yalnızca aşağıdaki paragrafta açıklandığı gibi tırnak içine alınmış bir dize içinde bunlara izin verilir ve ek olarak bir ters eğik çizgi veya çift tırnak öncesinde bir ters eğik çizgi kullanılmalıdır);
• yerel bölümün her iki ucunda da parantezle yorumlara izin verilir; örneğin john.smith(comment)@example.comve (comment)john.smith@example.comher ikisi de eşdeğerdir john.smith@example.com.

ASCII karakterlerine ek olarak, 2012 itibariyle yukarıdaki RFC 6532 spesifikasyonunda açıklandığı ve Wikipedia'da açıklandığı U+007Fgibi UTF-8 olarak kodlanan uluslararası karakterleri kullanabilirsiniz . 2019'dan itibaren bu standartların hala Önerilen olarak işaretlendiğini, ancak yavaşça uygulandığını unutmayın. Bu spesifikasyondaki değişiklikler, ve gibi izin verilen ve kısıtlanan özel karakterlerin kurallarını etkilemeden uluslararası karakterleri geçerli alfasayısal karakterler (metin) olarak ekledi .!#@:

Doğrulama için bkz . E-posta adresini doğrulamak için normal bir ifade kullanma .

domainKısmı tanımlanır , aşağıdaki gibi :

Protokoller için Internet standartları (Request for Comments) bileşeni hostname etiketleri yalnızca ASCII harf içerebileceğini zorunlu aaracılığıyla z, (bir harf duyarsız bir şekilde) rakamları 0ile 9, ve tire ( -). RFC 952'deki ana bilgisayar adlarının özgün belirtimi, etiketlerin bir rakamla veya kısa çizgiyle başlayamayacağını ve kısa çizgiyle bitmemesini zorunlu kılmıştır. Ancak, sonraki bir belirtim ( RFC 1123 ), ana bilgisayar adı etiketlerinin rakamlarla başlamasına izin verdi. Başka hiçbir simgeye, noktalama işaretine veya boş alana izin verilmez.

Dikkat et! Bu iş parçacığında çürük bir bilgi çürüğü var (eskiden doğru olan ve şimdi olmayan şeyler).

Mevcut ve gelecekteki dünyada ve dünyanın herhangi bir yerinden gerçek e-posta adreslerinin yanlış pozitif reddinden kaçınmak için, en azından RFC 3490'ın "Uygulamalarda Alan Adlarını Uluslararasılaştırma (IDNA)" üst düzey kavramını bilmeniz gerekir . Ben ABD ve A genellikle bu konuda değil biliyorum, ama zaten dünyada yaygın ve hızla artan kullanımda (çoğunlukla İngilizce olmayan baskın parçalar).

Burada esas olan mason @ 日本 .com ve wildwezyr@fahrvergnügen.net gibi adresleri kullanabilmeniz. Hayır, bu henüz dışarıdaki her şeyle uyumlu değil (birçoğu yukarıda atılmış olduğu gibi, basit qmail tarzı + kimlik adresleri bile genellikle yanlış reddedilir). Ancak bir RFC var, bir spesifikasyon var, şimdi IETF ve ICANN tarafından destekleniyor ve daha da önemlisi, şu anda hizmette olan bu gelişmeyi destekleyen çok sayıda uygulama var.

Japonya'ya dönüp hei @ や る .ca gibi e-posta adreslerini ve bunun gibi Amazon URL'lerini görmeye başlayana kadar bu gelişme hakkında çok şey bilmiyordum:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル カ メ ラ -? ポ ー タ ブ ル オ ー デ ィ オ / b / ref = topnav_storetab_e yani = UTF-8 ve düğüm = 3.210.981

Spesifikasyonlara bağlantı istemediğinizi biliyorum, ancak yalnızca İnternet forumlarındaki hackerların eski bilgisine güveniyorsanız, e-posta doğrulayıcınız İngilizce konuşan kullanıcıların gittikçe daha fazla çalışmayı beklediği e-posta adreslerini reddetecektir. Bu kullanıcılar için böyle bir doğrulama, hepimizin nefret ettiği sıradan beyin ölü formu kadar, + veya üç bölümlü bir alan adını işleyemeyen ya da her neyse can sıkıcı olacaktır.

Bu yüzden bir güçlük değil demiyorum, ancak "bazı / herhangi bir / hiçbir koşulda izin verilen" karakterlerin tam listesi (neredeyse) tüm dillerdeki tüm karakterlerdir. Eğer "(çok ve pek çok) geçersiz tüm geçerli e-posta adreslerini kabul" istiyorsanız o zaman temelde yararsız bir karakter tabanlı bir yaklaşım yapar bir hesaba IDN almak zorunda (üzgün), önce sürece uluslararası e-posta adreslerini dönüştürmek için Punycode .

Bunu yaptıktan sonra yukarıdaki tavsiyeleri (çoğunu) takip edebilirsiniz.

E-posta adresinin biçimi: local-part@domain-part(maksimum 64 @ 255 karakter, toplam 256 karakter).

local-partVe domain-partbuna kural olmaz olarak izin verilen karakter farklı bir dizi olabilir, ama bu, hepsi bu değil.

Genel olarak, yerel kısım şu ASCII karakterlerine sahip olabilir:

• Latin harfleri küçük harfe: abcdefghijklmnopqrstuvwxyz,
• Latin harfleri büyük harfe: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• basamak: 0123456789,
• Özel karakterler: !#$%&'*+-/=?^_`{|}~,
• nokta: .(ilk veya son karakter değil veya alıntılanmadığı sürece tekrarlanır),
• gibi noktalama işaretleri: "(),:;<>@[\](bazı kısıtlamalarla),
• yorumlar: ()(parantez içinde izin verilir, örn. (comment)john.smith@example.com).

Alan adı bölümü:

• Latin harfleri küçük harfe: abcdefghijklmnopqrstuvwxyz,
• Latin harfleri büyük harfe: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• basamak: 0123456789,
• tire: -(ilk veya son karakter değil),
• köşeli parantez içine alınmış IP adresi içerebilir: jsmith@[192.168.2.1]veya jsmith@[IPv6:2001:db8::1].

Bu e-posta adresleri geçerlidir:

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com (tek harfli yerel bölüm)
• "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 (üst düzey alan adı olmayan yerel alan adı)
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (tırnak işaretleri arasındaki boşluk)
• example@localhost (localhost'tan gönderildi)
• example@s.solutions(bkz . İnternet üst düzey alan adlarının listesi )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

Ve bu geçersiz örnekler:

• Abc.example.com( @karakter yok )
• A@b@c@example.com( @tırnak işaretleri dışında yalnızca bir tanesine izin verilir)
• a"b(c)d,e:f;gi[j\k]l@example.com (bu yerel bölümdeki özel karakterlerin hiçbirine tırnak işareti dışında izin verilmez)
• just"not"right@example.com (alıntılanan dizeler noktadan ayrılmış veya yerel parçayı oluşturan tek öğe olmalıdır)
• this is"not\allowed@example.com (boşluklar, tırnak işaretleri ve ters eğik çizgiler yalnızca tırnak içine alınmış dizelerde ve önünde ters eğik çizgi varsa kullanılabilir)
• this\ still\"not\allowed@example.com (kaçış olsa bile (önce ters eğik çizgi kullanılsa bile), boşluklar, tırnak işaretleri ve ters eğik çizgiler tırnak içinde bulunmalıdır)
• john..doe@example.com(önce çift nokta @); (uyarı ile: Gmail bunu sağlar)
• john.doe@example..com(sonra çift nokta @)
• önde gelen alanı olan geçerli bir adres
• boşluk içeren geçerli bir adres

Kaynak: Wikipedia'daki e-posta adresi

E-postaları doğrulamak için Perl'in RFC2822 normal ifadesi :

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

RFC2822 adresleri için tam normal ifade sadece 3.7k idi.

Ayrıca bkz: PHP'de RFC 822 E-posta Adresi Ayrıştırıcı .

E-posta adreslerinin resmi tanımları şöyledir:

• RFC 5322 (bölüm 3.2.3 ve 3.4.1, eski RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (izin verilen karakterler).

İlişkili:

• Düzenli ifadelerin gerçek gücü

Wikipedia'nın bu konuda iyi bir makalesi var ve resmi spesifikasyon burada . Wikipdia'dan:

E-posta adresinin yerel kısmı şu ASCII karakterlerinden herhangi birini kullanabilir:

• Büyük ve küçük İngilizce harfleri (az, AZ)
• 0-9 arasındaki rakamlar
• Karakterler! # $% & '* + - / =? ^ _ `{| } ~
• Karakter. (nokta, nokta, tam durdurma), ilk veya son karakter olmaması koşuluyla ve art arda iki veya daha fazla kez görünmemesi şartıyla.

Ayrıca, alıntılanan dizelere (yani: "John Doe" @ example.com) izin verilir, böylece aksi takdirde yasaklanacak karakterlere izin verilir, ancak ortak uygulamada görünmezler. RFC 5321 ayrıca "Posta almayı bekleyen bir ana bilgisayarın, Yerel bölümün Alıntılanan dize formunu gerektirdiği (veya kullandığı) posta kutularını tanımlamaması GEREKİR" uyarısı verir.

Google, gmail.com adresleriyle ilginç bir şey yapıyor. gmail.com adresleri yalnızca (az) harflere, sayılara ve noktalara (yok sayılır) izin verir.

örneğin, pikachu@gmail.com pi.kachu@gmail.com ile aynıdır ve her iki e-posta adresi de aynı posta kutusuna gönderilir. PIKACHU@gmail.com da aynı posta kutusuna teslim edilir.

Bu nedenle, soruyu cevaplamak bazen uygulayıcıya RFC standartlarının ne kadarını takip etmek istediklerine bağlıdır. Google'ın gmail.com adres stili standartlarla uyumludur. Bunu, farklı kişilerin benzer e-posta adreslerini alacağı karışıklığı önlemek için yaparlar.

*** 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)

Wikipedia bağlantısı genellikle e-posta adreslerinin genel olarak nelere izin verdiğine dair iyi bir referanstır. http://en.wikipedia.org/wiki/Email_address

Wikipedia makalesinden başlayabilirsiniz :

• Büyük ve küçük İngilizce harfleri (az, AZ)
• 0-9 arasındaki rakamlar
• Karakterler! # $% & '* + - / =? ^ _ `{| } ~
• Karakter. (nokta, nokta, tam durdurma), ilk veya son karakter olmaması koşuluyla ve art arda iki veya daha fazla kez görünmemesi şartıyla.

Ad:

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

Sunucu:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

@ Ve öğesini kontrol edin. ve doğrulamaları için bir e-posta gönderin.

Birisi e-posta doğrulamasını bozduğu veya yeni adreslerin geçerli olduğundan önce geldiği için .name e-posta adresimi hala internetteki sitelerin% 20'sinde kullanamıyorum.

Kısa cevap 2 cevap olmasıdır. Yapmanız gerekenler için bir standart var. yani akıllıca ve sizi beladan uzak tutacak davranış. Sorun çıkarmadan kabul etmeniz gereken davranış için başka (çok daha geniş) bir standart daha vardır. Bu ikilik, e-posta göndermek ve kabul etmek için çalışır, ancak yaşamda geniş bir uygulamaya sahiptir.

Oluşturduğunuz adreslerle ilgili iyi bir kılavuz için; bkz. http://www.remote.org/jochen/mail/info/chars.html

Geçerli e-postaları filtrelemek için bir sonraki adımı görecek kadar anlaşılır bir şey iletmeniz yeterlidir. Veya bir sürü RFC okumaya başlayın, dikkat edin, işte ejderhalar.

Konuyla ilgili iyi bir okuma .

Alıntı:

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

Kabul edilen cevap, bir e-posta adresinin geçerli yerel kısmını tartışırken bir Wikipedia makalesine atıfta bulunur, ancak Wikipedia bu konuda bir otorite değildir.

IETF RFC 3696 bu konuda bir otoritedir ve bölüm 3'e başvurulmalıdır . E-posta adreslerindeki kısıtlamalar sayfa 5:

Çağdaş e-posta adresleri, bir "alan adı bölümünden" (tam nitelikli bir alan adı) işaretli ("@") ayrılmış bir "yerel bölümden" oluşur. Etki alanı bölümünün sözdizimi, önceki bölümdekinin sözdizimine karşılık gelir. Bu bölümde, filtreleme ve ad listeleriyle ilgili endişeler, bir e-posta bağlamında kullanılan alan adları için de geçerlidir. Alan adı, köşeli parantez içindeki bir IP adresiyle de değiştirilebilir, ancak bu form test etme ve sorun giderme amaçları dışında kesinlikle önerilmez.

Yerel kısım, aşağıda açıklanan alıntı kuralları kullanılarak görünebilir. Alıntılanan formlar pratikte nadiren kullanılır, ancak bazı meşru amaçlar için gereklidir. Bu nedenle, filtreleme rutinlerinde reddedilmemeli, bunun yerine hedef ana bilgisayar tarafından değerlendirilmek üzere e-posta sistemine geçirilmelidir.

Tam kural, kontrol karakterleri de dahil olmak üzere herhangi bir ASCII karakterinin tırnak içine alınmış veya tırnak içine alınmış bir dizede görünebilmesidir. Alıntılama gerektiğinde, ters eğik çizgi karakteri aşağıdaki karakteri belirtmek için kullanılır. Örneğin

  Abc\@def@example.com

e-posta adresinin geçerli bir biçimidir. Boş alanlar da olduğu gibi görünebilir

  Fred\ Bloggs@example.com

Ters eğik çizgi karakteri ayrıca alıntı yapmak için kullanılabilir, ör.

  Joe.\\Blow@example.com

Ters eğik çizgi karakterini kullanarak alıntı yapmaya ek olarak, dizeleri çevrelemek için geleneksel çift tırnak karakterleri kullanılabilir. Örneğin

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

yukarıdaki ilk iki örneğin alternatif formlarıdır. Bu alıntılanan formlar nadiren önerilir ve uygulamada nadirdir, ancak yukarıda tartışıldığı gibi e-posta adreslerini işleyen uygulamalar tarafından desteklenmelidir. Özellikle, alıntılanan formlar genellikle diğer sistemlerden ve bağlamlardan geçişlerle ilişkili adresler bağlamında görünür; bu geçiş gereksinimleri hala ortaya çıkmaktadır ve kullanıcı tarafından sağlanan bir e-posta adresini kabul eden bir sistem, bu adresin eski bir sistemle ilişkilendirilip ilişkilendirilmediğini "bilemez", adres formlarının kabul edilmesi ve e-posta ortamına aktarılması gerekir.

Tırnak işaretleri olmadan, yerel parçalar
alfabetik karakterlerin, rakamların veya özel karakterlerin herhangi bir kombinasyonundan oluşabilir

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

nokta (".") da görünebilir, ancak yerel parçayı başlatmak veya bitirmek için kullanılamaz veya iki veya daha fazla ardışık dönem görünemez. Farklı bir şekilde ifade edildiğinde, at işareti ("@"), ters eğik çizgi, çift tırnak işareti, virgül veya köşeli parantezler dışında herhangi bir ASCII grafik (yazdırma) karakteri tırnak işareti olmadan görünebilir. Bu hariç tutulan karakterler listesinden herhangi biri görünecekse, tırnak işaretleri içine alınmalıdır. Gibi formlar

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

geçerlidir ve oldukça düzenli olarak görülür, ancak yukarıda listelenen karakterlerden herhangi birine izin verilir.

Diğerlerinin yaptığı gibi, e-posta adreslerini doğrulamak için hem PHP hem de JavaScript için çalışan bir normal ifade gönderirim:

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

Bulunabilir gibi bu Wikipedia linki

E-posta adresinin yerel kısmı şu ASCII karakterlerinden herhangi birini kullanabilir:

• büyük harfe ve Latin harfleri küçük harfe Akadar Zve ahiç z;

• parmaklara 0için 9;

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

• dot .o alıntı ve (örneğin alıntılanan sürece ardışık görünmüyor olması da temin sürece ilk veya son karakter değil şartıyla, John..Doe@example.comizin verilmez ancak "John..Doe"@example.comizin verilir);

• boşluklara ve "(),:;<>@[\]karakterlere kısıtlamalarla izin verilir (yalnızca aşağıdaki paragrafta açıklandığı gibi tırnak içine alınmış bir dize içinde bunlara izin verilir ve ek olarak bir ters eğik çizgi veya çift tırnak öncesinde bir ters eğik çizgi kullanılmalıdır);

• yerel bölümün her iki ucunda da parantezle yorumlara izin verilir; örneğin john.smith(comment)@example.comve (comment)john.smith@example.comher ikisi de eşdeğerdir john.smith@example.com.

Yukarıdaki ASCII karakterlerine ek olarak, UTF-8 olarak kodlanan U + 007F üzerindeki uluslararası karakterlere RFC 6531 tarafından izin verilir , ancak posta sistemleri yerel parçalar atarken hangi karakterlerin kullanılmasını kısıtlayabilir.

Bir nokta yerel-parçası içinde varlık ayrılmış gibi bir alıntı dize var olabilir, ya da en dıştaki tırnak yerel kısım dıştaki karakterlerdir zaman var olabilir (örneğin, abc."defghi".xyz@example.comya da "abcdefghixyz"@example.com. Tersine izin verilir, abc"defghi"xyz@example.com; ne olduğu değil abc\"def\"ghi@example.com). Ancak alıntılanan dizeler ve karakterler yaygın olarak kullanılmaz. RFC 5321 ayrıca "Posta almayı bekleyen bir ana bilgisayarın, Yerel bölümün Alıntılanan dize formunu gerektirdiği (veya kullandığı) posta kutularını tanımlamaması GEREKİR" uyarısı verir.

Yerel parça postmasterözel olarak ele alınır - büyük / küçük harfe duyarlı değildir ve alan adı e-posta yöneticisine iletilmelidir. Teknik olarak tüm diğer yerel-parçaları harfe duyarlıdır, bu nedenle jsmith@example.comve JSmith@example.comfarklı posta kutularını belirlemek; ancak, birçok kuruluş büyük ve küçük harfleri eşdeğer kabul eder.

Teknik olarak geçerli çok çeşitli özel karakterlere rağmen; kuruluşlar, posta hizmetleri, posta sunucuları ve posta istemcileri genellikle hepsini kabul etmez. Örneğin, Windows Live Hotmail yalnızca e-posta adreslerinin alfasayısal, nokta ( .), alt çizgi ( _) ve kısa çizgi ( ) kullanılarak oluşturulmasına izin verir -. Reddedilen e-posta riskinden kaçınmak için bazı özel karakterler kullanmaktan kaçınmak yaygın bir öneridir.

Cevap (neredeyse) ALL(7 bitlik ASCII).
İçerme kurallarına "... bazı / herhangi / hiçbir koşulda izin verilir ..."

Sadece sayfa 17'nin üstündeki RFC 5322'deki "alan metni" bölümünde izin verilen metin için birkaç olası ekleme kuralından birine bakarak şunları buluyoruz:

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

bu açıklamadaki sadece üç eksik karakter, alan-değişmezinde [], tırnak içine alınmış bir çift \ve beyaz boşluk karakteri (% d32) oluşturmak için kullanılır. Bununla birlikte, 32-126 (ondalık) aralığı kullanılır. Benzer bir gereksinim "qtext" ve "ctext" olarak görünür. Birçok kontrol karakterine de izin verilir / kullanılır. Bu tür kontrol grafiklerinin bir listesi, RFC 5322'nin sayfa 31 bölüm 4.1'inde obs-NO-WS-CTL olarak görünür .

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

Tüm bu kontrol karakterlerine bölüm 3.5'in başında belirtildiği şekilde izin verilir:

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

Ve böyle bir içerme kuralı bu nedenle "çok geniş" tir. Veya başka bir deyişle, beklenen kural "çok basit" tir.

Basitlik adına, doğrulamadan önce çift tırnak içindeki ve çift tırnak çevresindeki tüm metinleri kaldırarak, kibosh'u izin verilmeyen şeylere dayanarak e-posta adresi gönderimlerine koyarak gönderimi sanitize ederim. Birisi John olabilir çünkü. Gelecekte, ücretsiz bir e-posta adresi almanın, poponuzu silerek iyi bir iş yapmaktan daha az zaman alacağı gelecekte yaşıyoruz. E-posta ölçütleri, girişin hemen yanında neye izin verilip neye izin verilmediğini söylenmemiş gibi değil.

Ayrıca, belirtilen materyal çıkarıldıktan sonra çeşitli RFC'lerin izin vermediğini dezenfekte ediyorum. Özel olarak izin verilmeyen karakterler ve kalıpların listesi, test edilmesi gereken çok daha kısa bir liste gibi görünüyor.

İzin verilmeyen:

    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 )

Verilen örnekte:

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

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

E-posta adresini ekleme veya değiştirme girişimi sonrasında kalan sonuca onaylanmış bir e-posta mesajı göndermek, kodunuzun gönderilen e-posta adresini işleyip işleyemeyeceğini görmek için iyi bir yoldur. E-posta, gerektiği kadar sterilize etme işleminden sonra doğrulamayı geçerse, bu onayı tetikleyin. Onay bağlantısından bir istek geri gelirse, yeni e-posta gerçek birinci sınıf saklanan bir e-posta haline gelmek için holding || geçici || araf durumu veya depolama alanından taşınabilir.

Düşünceli olmak istiyorsanız eski e-posta adresine bir e-posta adresi değişikliği hatası veya başarılı bildirimi gönderilebilir. Onaylanmamış hesap kurulumları, makul bir süre sonra tamamen başarısız girişimler olarak sistemden düşebilir.

Sistemimde pis kokulu e-postalara izin vermiyorum, belki bu sadece para atıyor. Ancak, insanların% 99,9'u sadece doğru olanı yapar ve son durum uyumluluk senaryolarını kullanarak uyumluluk sınırlarını eşiğine getirmeyen bir e-postaya sahiptir. Regex DDoS dikkatli olun, bu bela başlayabilirsiniz bir yerdir. Ve bu yaptığım üçüncü şeyle ilgili, herhangi bir e-postayı ne kadar süreyle işlemek istediğime bir sınır koydum. Doğrulanması için makinemi yavaşlatması gerekiyorsa, gelen veri API'sı uç nokta mantığımı geçmiyor.

Edit: Bu cevap "kötü" olduğu için ölmek devam etti ve belki de hak etti. Belki hala kötü, belki de değil.

PHP'imde bu kontrolü kullanıyorum

<?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";
}
?>

kendiniz deneyin http://phpfiddle.org/main/code/9av6-d10r

Bu normal ifadeyi RFC yönergelerine göre oluşturdum:

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

Gmail yalnızca + işaretine özel karakter olarak ve bazı durumlarda (.) İzin verir, ancak Gmail'de başka hiçbir özel karaktere izin verilmez. RFC'ler, özel karakterler kullanabileceğinizi, ancak Gmail'e özel karakterlerle posta göndermekten kaçınmanız gerektiğini söylüyor.