दिलचस्प पोस्ट
कैसे एक फ़ेविकॉन चेतन करने के लिए? एनपीएम काम नहीं कर रहा है – "ईनोनसेसेट पढ़ें" Matplotlib – प्रत्येक बिन लेबल इसका अर्थ क्या है? प्रॉक्सी के माध्यम से कर्ल का उपयोग कैसे करें? नई लाइन पर ताला खोलने के साथ एक्सकोड 4 स्विफ्ट – CGPoint संरेखण Laravel, आखिरी प्रविष्टि आईडी का प्रयोग करके एलोक्यून्ट प्राप्त करें एक WHERE खंड में एक स्तंभ उपनाम का जिक्र करते हुए सूची तत्व से \ n कैसे निकालें? अंतर और चारों में अंतर मिलकर / फेट्टाक और पुचर / एफटीपीसी? कन्वर्ट। परिवर्तनीय प्रकार () में विफल रहता है MySQL में, क्या मैं एक ही तालिका में सम्मिलित करने के लिए एक पंक्ति को कॉपी कर सकता हूँ? एंड्रॉइड: दृश्य शैली को प्रोग्राम के अनुसार सेट करें निष्पादन को कैसे रोकें, नींद, आर में एक्स सेकंड की प्रतीक्षा करें?

किसी ईमेल पते में कौन-से पात्रों की अनुमति है?

मैं पूर्ण ईमेल सत्यापन के बारे में नहीं पूछ रहा हूं

मैं यह जानना चाहता हूं कि user-name और ईमेल पते के server भागों में अक्षरों को क्या अनुमति है। यह अतिरंजित हो सकता है, शायद ईमेल पते अन्य रूप ले सकता है, लेकिन मुझे परवाह नहीं है। मैं केवल इस सरल रूप के बारे में पूछ रहा हूं: user-name@server (उदाहरण के लिए wild.wezyr@best-server-ever.com) और दोनों भागों में अक्षरों को अनुमति दी गई है।

वेब के समाधान से एकत्रित समाधान "किसी ईमेल पते में कौन-से पात्रों की अनुमति है?"

आरएफसी 5322 देखें : इंटरनेट संदेश स्वरूप और, कम हद तक, आरएफसी 5321: सिंपल मेल ट्रांसफर प्रोटोकॉल

आरएफसी 822 भी ईमेल पते को कवर करता है, लेकिन यह ज्यादातर इसकी संरचना से संबंधित है:

  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 

और हमेशा की तरह, विकिपीडिया के ईमेल पते पर एक अच्छा लेख है :

ईमेल पते का स्थानीय भाग इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

  • अपरकेस और लोअरकेस लैटिन अक्षर A टू Z और a टू z ;
  • अंक 0 से 9 ;
  • विशेष वर्ण !#$%&'*+-/=?^_`{|}~ ;
  • डॉट बशर्ते कि यह पहला या आखिरी चरित्र नहीं है, जब तक उद्धृत नहीं किया जाता है, और यह भी प्रदान किया जाता है कि यह लगातार प्रदर्शित नहीं होता है जब तक उद्धृत नहीं किया जाता है (उदाहरण के लिए John..Doe@example.com की अनुमति नहीं है, लेकिन " "John..Doe"@example.com अनुमति);
  • अंतरिक्ष और "(),:;<>@[\] पात्रों को प्रतिबंधों के साथ अनुमति दी जाती है (नीचे दिए पैराग्राफ में वर्णित अनुसार उन्हें केवल उद्धृत स्ट्रिंग के अंदर ही अनुमति है, और इसके अतिरिक्त, एक बैकस्लैश या दोहरे उद्धरण से पहले होना चाहिए एक बैकस्लैश);
  • टिप्पणियों को स्थानीय भाग के दोनों छोर पर कोष्ठकों के साथ अनुमति है; जैसे john.smith(comment)@example.com ( (comment)john.smith@example.com john.smith(comment)@example.com और (comment)john.smith@example.com बराबर हैं।

एएससीआईआई वर्णों के अतिरिक्त, 2012 तक आप यूटीएफ -8 के रूप में एन्कोडेड U+007F ऊपर अंतर्राष्ट्रीय अक्षर का उपयोग कर सकते हैं।

सत्यापन के लिए, किसी ईमेल पते को मान्य करने के लिए एक नियमित अभिव्यक्ति का उपयोग करना देखें।

domain भाग निम्नानुसार परिभाषित किया गया है :

प्रोटोकॉल के लिए इंटरनेट मानकों (टिप्पणियों के लिए अनुरोध) जनादेश करता है कि घटक मेजबाननाम लेबल में केवल एएससीआईआई अक्षरों के माध्यम से a z (एक मामले में असंवेदनशील तरीके से), अंक 0 से 9 , और हाइफ़न ( - ) हो सकते हैं। आरएफसी 952 में मेजबाननामों का मूल विवरण, अनिवार्य है कि लेबल एक अंक या हाइफ़न के साथ शुरू नहीं हो सकता, और एक हाइफ़न के साथ समाप्त नहीं होना चाहिए। हालांकि, बाद के विनिर्देश ( आरएफसी 1123 ) अंकों के साथ आरंभ करने के लिए होस्टनाम लेबल को अनुमति देता है। कोई अन्य प्रतीकों, विराम चिह्न या रिक्त स्थान की अनुमति नहीं है।

ध्यान रहे! इस धागे में ज्ञान सड़ने का एक गुच्छा है (सामान जो सच हो और अब नहीं है)।

वर्तमान और भविष्य की दुनिया में वास्तविक ई-मेल पते के झूठी-सकारात्मक अस्वीकृति से बचने के लिए, और दुनिया में कहीं से भी, आपको कम से कम आरएफसी 3490 की उच्च-स्तरीय अवधारणा, "अनुप्रयोगों में डोमेन नाम अंतर्राष्ट्रीयकरण (आईडीएनए)" जानना चाहिए। मैं अमेरिका में लोगों को जानता हूं और अक्सर इस पर कुछ नहीं होता है, लेकिन यह पहले से ही दुनिया भर में व्यापक रूप से बढ़ रहा है (मुख्य रूप से गैर अंग्रेजी प्रभुत्व वाले हिस्से)।

यह सार है कि अब आप मेसन @ जापान। कॉम और वाइल्डवेज़र @ फेहर्र्गेरग्जएनएनेट जैसे पते का उपयोग कर सकते हैं। नहीं, यह अभी तक सब कुछ के साथ संगत नहीं है (जैसा कि कई लोग ऊपर लिखे हैं, यहां तक ​​कि सरल qmail-style + ident पते अक्सर गलत तरीके से अस्वीकार कर दिए जाते हैं) लेकिन एक आरएफसी है, एक कल्पना है, अब इसे आईईटीएफ और आईसीएएनएन द्वारा समर्थित किया गया है, और – इससे भी महत्वपूर्ण बात यह है कि वर्तमान में सेवा में इस सुधार का समर्थन करने वाले बड़े और बढ़ते हुए कार्यान्वयन हैं।

जब तक मैं जापान में वापस नहीं लौटा और खुद को इस विकास के बारे में ज्यादा जानकारी नहीं देता, जैसे हीई @ や।

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ बी / ref = topnav_storetab_e यानी = UTF8 और नोड = 3,210,981

मुझे पता है कि आप ऐपिक्स के लिंक नहीं चाहते हैं, लेकिन अगर आप केवल इंटरनेट फ़ोरम पर हैकर्स के पुराना ज्ञान पर भरोसा रखते हैं, तो आपका ईमेल सत्यापनकर्ता अंतराल वाले ईमेल पतों को खारिज कर देगा, जो गैर-एनिलिश वाले उपयोगकर्ताओं को तेजी से काम करने की उम्मीद है। उन उपयोगकर्ताओं के लिए, इस तरह की मान्यता सामान्य मस्तिष्क-मृत रूप के रूप में परेशान होगी, जो हम सभी को नफरत करते हैं, जो एक + या तीन-भाग वाले डोमेन नाम या जो कुछ भी संभाल नहीं सकते

इसलिए मैं यह नहीं कह रहा हूं कि यह कोई परेशानी नहीं है, लेकिन सभी भाषाओं में सभी अक्षर के लगभग (लगभग) कुछ / किसी भी / कोई भी शर्तों के तहत अनुमति वाले पात्रों की पूरी सूची है यदि आप "सभी मान्य ईमेल पते (और बहुत से अवैध) स्वीकार करना चाहते हैं" तो आपको आईडीएन को ध्यान में रखना होगा, जो कि मूल रूप से एक चरित्र-आधारित दृष्टिकोण बेकार (खेद) बनाता है, जब तक कि आप पहले अंतर्राष्ट्रीय ईमेल पतों को पूनीकोड ​​में कनवर्ट नहीं करते ।

ऐसा करने के बाद आप ऊपर की सलाह (अधिकतर) का अनुसरण कर सकते हैं

नाम:

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

सर्वर:

 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-. 

विकिपीडिया का इस पर एक अच्छा लेख है , और आधिकारिक कल्पना यहाँ है विकिपीडिया से:

ई-मेल पते का स्थानीय भाग इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

  • अपरकेस और लोअरकेस अंग्रेज़ी अक्षर (एज़, एज़)
  • अंक 0 से 9 तक
  • वर्ण ! # $% और '* + – / =? ^ _ {{| } ~
  • चरित्र (डॉट, पीरियड, फुल स्टॉप) बशर्ते कि यह पहला या आखिरी चरित्र नहीं है, और यह भी प्रदान किया जाता है कि यह लगातार दो या दो बार प्रदर्शित नहीं होता है।

इसके अतिरिक्त, उद्धृत-स्ट्रिंग्स (अर्थात्: "जॉन डो" @ example.com) को अनुमति दी जाती है, इस प्रकार उन पात्रों को अनुमति दी जाती है जो अन्यथा प्रतिबंधित होती हैं, हालांकि वे सामान्य व्यवहार में प्रकट नहीं होते हैं आरएफसी 5321 भी चेतावनी देता है कि "एक मेजबान जो मेल प्राप्त करने की अपेक्षा करता है मेलबॉक्स को परिभाषित करने से बचने की आवश्यकता है जहां लोकल-भाग को उद्धृत-स्ट्रिंग फॉर्म (या उपयोग) की आवश्यकता है"।

ई-मेल पते का प्रारूप है: local-part@domain-part (अधिकतम 64 @ 255 वर्ण, कुल में कोई और नहीं 256)।

local-part और domain-part में अनुमत अक्षरों के अलग domain-part अलग सेट हो सकते हैं, लेकिन यह सब कुछ नहीं है, क्योंकि इसमें अधिक नियम हैं

सामान्य तौर पर, स्थानीय भाग में इन ASCII वर्ण हो सकते हैं:

  • लोअरकेस लैटिन अक्षर: abcdefghijklmnopqrstuvwxyz ,
  • अपरकेस लैटिन अक्षर: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • अंक: 0123456789 ,
  • विशेष वर्ण !#$%&'*+-/=?^_`{|}~ ,
  • डॉट:। (पहले या अंतिम वर्ण या दोहराए जाने तक नहीं)
  • अंतरिक्ष विराम चिह्न जैसे: "(),:;<>@[\] (कुछ प्रतिबंधों के साथ)
  • टिप्पणियाँ: () (कोष्ठक के भीतर अनुमति दी जाती है, जैसे ( (comment)john.smith@example.com ) (comment)john.smith@example.com )।

डोमेन भाग:

  • लोअरकेस लैटिन अक्षर: abcdefghijklmnopqrstuvwxyz ,
  • अपरकेस लैटिन अक्षर: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • अंक: 0123456789 ,
  • हाइफ़न: - (पहले या अंतिम वर्ण नहीं),
  • इसमें आईपी पते को चौकोर ब्रैकेट्स से घिरा हुआ हो सकता है: jsmith@[192.168.2.1] या jsmith@[IPv6:2001:db8::1]

ये ई-मेल पते मान्य हैं:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (एक-अक्षर वाला स्थानीय भाग)
  • "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 (कोई शीर्ष-स्तरीय डोमेन के साथ स्थानीय डोमेन नाम)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (उद्धरणों के बीच की जगह)
  • example@localhost (लोकलहोस्ट से भेजा गया)
  • example@s.solutions ( इंटरनेट शीर्ष-स्तरीय डोमेन की सूची देखें)
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

और ये अमान्य के उदाहरण:

  • Abc.example.com (कोई @ वर्ण नहीं)
  • A@b@c@example.com (केवल एक @ को उद्धरण चिह्नों के बाहर की अनुमति है)
  • a"b(c)d,e:f;gi[j\k]l@example.com (इस स्थानीय भाग में से कोई भी विशेष वर्ण बिना उद्धरण चिह्नों की अनुमति है)
  • just"not"right@example.com (उद्धृत स्ट्रिंग्स को डॉट से अलग किया जाना चाहिए या केवल स्थानीय भाग बनाने वाले तत्व)
  • this is"not\allowed@example.com (रिक्त स्थान, उद्धरण, और बैकस्लैश केवल तब ही मौजूद हो सकते हैं जब उद्धृत स्ट्रिंग्स के भीतर और बैकस्लैश से पहले)
  • this\ still\"not\allowed@example.com (यहां तक ​​कि बचने के बाद (बैकस्लैश से पहले), रिक्त स्थान, उद्धरण, और बैकस्लैश अभी भी उद्धरणों से निहित हैं)
  • john..doe@example.com ( john..doe@example.com डॉट डॉट @ ); (चेतावनी के साथ: जीमेल इस माध्यम से देता है)
  • john.doe@example..com (डबल डॉट के बाद @ )
  • एक प्रमुख स्थान के साथ एक मान्य पता
  • पीछे वाले स्थान के साथ एक मान्य पता

स्रोत: विकिपीडिया पर ईमेल पता


ईमेल मान्य करने के लिए पर्ल के RFC2822 regex:

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

ई-मेल पते की औपचारिक परिभाषाएं निम्न में हैं:

  • आरएफसी 5322 (खंड 3.2.3 और 3.4.1, आरएफसी 2822 को रद्द कर दिया गया है), आरएफसी 5321, आरएफसी 36 9 6,
  • आरएफसी 6531 (अनुमत पात्रों)

सम्बंधित:

  • नियमित अभिव्यक्ति की वास्तविक शक्ति

आप विकिपीडिया लेख से शुरू कर सकते हैं:

  • अपरकेस और लोअरकेस अंग्रेज़ी अक्षर (एज़, एज़)
  • अंक 0 से 9 तक
  • वर्ण ! # $% और '* + – / =? ^ _ {{| } ~
  • चरित्र (डॉट, पीरियड, फुल स्टॉप) बशर्ते कि यह पहला या आखिरी चरित्र नहीं है, और यह भी प्रदान किया जाता है कि यह लगातार दो या दो बार प्रदर्शित नहीं होता है।

गूगल अपने gmail.com पते के साथ एक दिलचस्प बात करते हैं gmail.com पते केवल अक्षरों (az), संख्याओं और अवधि (जिन्हें उपेक्षित कर दिया जाता है) को अनुमति देता है

जैसे, pikachu@gmail.com pi.kachu@gmail.com के समान है, और दोनों ईमेल पते उसी मेलबॉक्स पर भेजे जाएंगे। PIKACHU@gmail.com को एक ही मेलबॉक्स पर भी वितरित किया गया है।

तो सवाल का उत्तर देने के लिए, कभी-कभी यह कार्यान्वयनकर्ता पर निर्भर करता है कि वह कितने आरएफसी मानकों का पालन करना चाहते हैं। Google के gmail.com पता शैली मानकों के अनुरूप है। वे ऐसा भ्रम से बचने के लिए करते हैं, जहां अलग-अलग लोग समान ईमेल पते जैसे उदाहरण लेते हैं

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

विकिपीडिया लिंक आमतौर पर किस ईमेल पते की अनुमति देता है यह एक अच्छा संदर्भ है http://en.wikipedia.org/wiki/Email_address

संक्षिप्त जवाब यह है कि 2 उत्तर हैं आपको क्या करना चाहिए इसके लिए एक मानक है यानी व्यवहार जो बुद्धिमान है और आपको परेशानी से बचाएगा। व्यवहार के लिए एक अन्य (बहुत व्यापक) मानक है जिससे आपको परेशानी न हो। यह द्वंद्व ईमेल भेजने और स्वीकार करने के लिए काम करता है, लेकिन जीवन में विस्तृत आवेदन करता है।

आपके द्वारा बनाए गए पते के लिए एक अच्छी मार्गदर्शिका के लिए; देखें: http://www.remote.org/jochen/mail/info/chars.html

मान्य ईमेल को फ़िल्टर करने के लिए, बस अगले चरण देखने के लिए पर्याप्त कुछ समझें। या आरएफसी का एक झुंड पढ़ने के लिए सावधानी, यहाँ ड्रेगन हो।

@ और चेक करें और फिर सत्यापित करने के लिए उनके लिए एक ईमेल भेजें।

मैं अभी भी इंटरनेट पर 20% साइटों पर अपना .name ईमेल पता का उपयोग नहीं कर सकता क्योंकि किसी ने अपनी ईमेल सत्यापन को खराब कर दिया है या क्योंकि यह नए पते मान्य होने से पहले की बात करता है

मामले पर एक अच्छा पढ़ा।

अंश:

 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 

जैसा कि इस विकिपीडिया लिंक में पाया जा सकता है

ईमेल पते का स्थानीय भाग इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

  • अपरकेस और लोअरकेस लैटिन अक्षर A टू Z और a टू z ;

  • अंक 0 से 9 ;

  • विशेष वर्ण !#$%&'*+-/=?^_`{|}~ ;

  • डॉट बशर्ते कि यह पहला या आखिरी चरित्र नहीं है, जब तक उद्धृत नहीं किया जाता है, और यह भी प्रदान किया जाता है कि यह लगातार प्रदर्शित नहीं होता है जब तक उद्धृत नहीं किया जाता है (उदाहरण के लिए John..Doe@example.com की अनुमति नहीं है, लेकिन " "John..Doe"@example.com अनुमति);

  • अंतरिक्ष और "(),:;<>@[\] पात्रों को प्रतिबंधों के साथ अनुमति दी जाती है (नीचे दिए पैराग्राफ में वर्णित अनुसार उन्हें केवल उद्धृत स्ट्रिंग के अंदर ही अनुमति है, और इसके अतिरिक्त, एक बैकस्लैश या दोहरे उद्धरण से पहले होना चाहिए एक बैकस्लैश);

  • टिप्पणियों को स्थानीय भाग के दोनों छोर पर कोष्ठकों के साथ अनुमति है; जैसे john.smith(comment)@example.com ( (comment)john.smith@example.com john.smith(comment)@example.com और (comment)john.smith@example.com बराबर हैं।

उपरोक्त ASCII वर्णों के अलावा, यूटीएफ -8 के रूप में एन्कोडेड U + 007F के ऊपर अंतर्राष्ट्रीय अक्षर, आरएफसी 6531 द्वारा अनुमति है, हालांकि मेल सिस्टम स्थानीय-भागों को निर्दिष्ट करते समय उपयोग करने वाले वर्णों को प्रतिबंधित कर सकते हैं।

एक उद्धृत स्ट्रिंग स्थानीय-भाग के भीतर एक डॉट अलग इकाई के रूप में मौजूद हो सकती है, या यह तब मौजूद हो सकती है जब बाह्यतम उद्धरण स्थानीय भाग के बाह्यतम अक्षर होते हैं (जैसे, abc."defghi".xyz@example.com या "abcdefghixyz"@example.com की अनुमति है। इसके विपरीत, abc"defghi"xyz@example.com नहीं है; न ही abc\"def\"ghi@example.com )। हालांकि उद्धृत स्ट्रिंग्स और पात्रों, सामान्यतः उपयोग नहीं किए जाते हैं आरएफसी 5321 भी चेतावनी देता है कि "एक मेजबान जो मेल प्राप्त करने की अपेक्षा करता है मेलबॉक्स को परिभाषित करने से बचने की आवश्यकता है जहां लोकल-भाग को उद्धृत-स्ट्रिंग फॉर्म (या उपयोग) की आवश्यकता है"।

स्थानीय पार्ट postmaster विशेष रूप से व्यवहार किया जाता है-यह मामला असंवेदनशील है, और डोमेन ईमेल व्यवस्थापक को अग्रेषित किया जाना चाहिए। तकनीकी रूप से अन्य सभी स्थानीय-पार्ट्स केस-संवेदी होते हैं, इसलिए jsmith@example.com और JSmith@example.com अलग मेलबॉक्स निर्दिष्ट करते हैं; हालांकि, कई संगठन अपरकेस और लोअरकेस अक्षरों को समकक्ष मानते हैं।

विशेष वर्णों की विस्तृत श्रृंखला के बावजूद जो तकनीकी रूप से मान्य हैं; संगठनों, मेल सेवाओं, मेल सर्वर और डाक क्लाइंट अभ्यास में अक्सर उन सभी को स्वीकार नहीं करते हैं उदाहरण के लिए, Windows Live Hotmail केवल अल्फ़ान्यूमर्स, डॉट ( . ), अंडरस्कोर ( _ ) और हाइफ़न ( - ) का उपयोग करके ईमेल पते बनाने की अनुमति देता है। अस्वीकृत ईमेल के जोखिम से बचने के लिए कुछ विशेष वर्णों का उपयोग करने से बचने के लिए आम सलाह है

स्वीकृत जवाब एक विकिपीडिया लेख को संदर्भित करता है जब एक ईमेल पते के वैध स्थानीय भाग पर चर्चा करता है, लेकिन विकिपीडिया इस पर एक प्राधिकरण नहीं है।

आईईटीएफ आरएफसी 36 9 6 इस मामले पर एक प्राधिकरण है, और खंड 3 में परामर्श किया जाना चाहिए। पृष्ठ 5 पर ईमेल पते पर प्रतिबंध

जैसा कि दूसरों ने किया है, मैं एक regex सबमिट करता है जो ईमेल पते को मान्य करने के लिए PHP और जावास्क्रिप्ट दोनों के लिए काम करता है:

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

इसका उत्तर है (लगभग) ALL (7 बिट एएससीआईआई)
यदि शामिल किए गए नियम "कुछ / किसी भी / कोई भी शर्तों के तहत अनुमति दी जाती है …"

पृष्ठ 17 के शीर्ष पर आरएफसी 5322 में "डोमेन पाठ" भाग में अनुमत पाठ के लिए कई संभावित समावेश नियमों में से एक को देखकर हम पाते हैं:

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

इस वर्णन में केवल तीन लापता वर्ण डोमेन-शाब्दिक [] में उपयोग किए जाते हैं, एक उद्धृत-जोड़ी बनाने के लिए, और सफेद स्पेस वर्ण (% D32)। इसके साथ पूरी रेंज 32-126 (दशमलव) का उपयोग किया जाता है। एक समान आवश्यकता "qtext" और "ctext" के रूप में दिखाई देती है कई नियंत्रण पात्रों को भी अनुमति / प्रयोग किया जाता है। ऐसे नियंत्रण वर्णों की एक सूची आरएसएस 5322 के पृष्ठ 31 अनुभाग 4.1 में प्रकट होती है, जैसे- नो-डब्ल्यूएस-सीटीएल

 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 

धारा 3.5 की शुरुआत में बताया गया है कि यह सभी नियंत्रण पात्रों की अनुमति है:

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

और इस तरह के एक समावेश नियम इसलिए "बहुत चौड़ा" है या, दूसरे अर्थ में, अपेक्षित नियम "बहुत सरल" है

मेरे PHP में मैं इस चेक का उपयोग करता हूं

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

इसे खुद http://phpfiddle.org/main/code/9av6-d10r देखें

2016/01/24

इस समय 6531 तक सभी आरएफसी के बारे में …

मैं सभी पाठ को दोहरे उद्धरण और सत्यापन के पहले के आसपास के दोहरे उद्धरण चिह्नों को हटाने में देख रहा हूं, उद्धृत सामग्री को हटा दिए जाने के बाद विशेष रूप से अनुमति नहीं है (बहुत छोटी सूची … लगता है) के आधार पर ई-मेल पते प्रस्तुति पर किबाश डाल रहा है, पूरी ई-मेल पते पर एक पुष्टि ईमेल संदेश भेजकर उसका पीछा किया जाता है, यदि वह पिछले दो स्थितियों से गुजरता है, और अनिश्चित खाता सेटअप उचित समय के बाद पूरी तरह से सिस्टम से बाहर निकलते हैं

अनुमति न दिया:

  local part starts with a period two or more periods in series &'`*|/ more than one @ outside of double quotation marks :% 

मैंने RFC दिशानिर्देशों के अनुसार इस regex को बनाया है:

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

उन लोगों के लिए जो अंतरराष्ट्रीय डोमेन की मान्यता में दिलचस्पी रखते हैं, यहां उपलब्ध एक। नेट टूल है (कंपनी से संबद्ध नहीं):

http://cobisi.com/email-validation/.net-component – आरएफसी की लंबी सूची के अनुरूप:

IETF मानक (आरएफसी 1123, आरएफसी 2821, आरएफसी 2822, आरएफसी 34 9 0, आरएफसी 36 9 6, आरएफसी 42 9 1, आरएफसी 5321, आरएफसी 5322 और आरएफसी 5336), उद्धृत शब्दों, डोमेन शाब्दिक, गैर-एएससीआईआई डोमेन नामों (आईडीएनए) और मेलबॉक्स के समर्थन के साथ , और टिप्पणियां

जीमेल केवल + विशेष वर्ण के रूप में चिन्हित करेगा और कुछ मामलों में (।) लेकिन जीमेल पर किसी भी अन्य विशेष वर्ण की अनुमति नहीं है आरएफसी का कहना है कि आप विशेष वर्णों का उपयोग कर सकते हैं लेकिन आपको विशेष वर्णों के साथ Gmail को मेल भेजने से बचना चाहिए।