अपना ईमेल पता कैसे खोजें या जाँचें

"त्रुटियों" का उल्लेख नहीं करने के लिए समीक्षाओं की सबसे बड़ी संख्या, एक नियमित अभिव्यक्ति ई-मेल पते पर मेरे पास आती है:

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[AZ]{2,4}\b 

मैं कहता हूं कि यह नियमित अभिव्यक्ति किसी भी ई-मेल पते को परिभाषित करती है। प्रतिक्रिया आमतौर पर एक ई-मेल पता दिखाती है जो इस अभिव्यक्ति के लायक नहीं है; इसके अलावा, बग की रिपोर्टें सही रेगेक्स के निर्माण का सुझाव देती हैं।

जैसा कि मैं नीचे बताऊंगा, मेरा कथन सत्य है जब आप मेरी परिभाषा को स्वीकार करते हैं कि वैध ईमेल पता क्या है और क्या नहीं है। यदि आप एक अलग परिभाषा का उपयोग करते हैं, तो आपको अभिव्यक्ति को समायोजित करना होगा। एक वैध ई-मेल पता निर्धारित करना एक बेहतरीन उदाहरण है जो दिखा रहा है

• अभिव्यक्ति लिखने से पहले, आपको ठीक से पता होना चाहिए कि क्या करना चाहिए और क्या नहीं;
• सटीकता और व्यावहारिकता के बीच एक व्यापार बंद किया जाना चाहिए।

मेरी नियमित अभिव्यक्ति की गरिमा यह है कि यह आज इस्तेमाल किए गए ईमेल पतों के 99% को परिभाषित करता है। सभी प्राप्त पतों को 99% ईमेल कार्यक्रमों द्वारा संसाधित किया जा सकता है। यदि आप एक त्वरित समाधान की तलाश कर रहे हैं, तो आपको केवल अगले पैराग्राफ को पढ़ने की आवश्यकता है।

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

 ^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[AZ]{2,4}$ 

ईमेल की पुष्टि में व्यापार बंद

हां, ईमेल पते का एक पूरा गुच्छा है जिसे मेरी नियमित अभिव्यक्ति नहीं मिल सकती है। सबसे अधिक उद्धृत पते वे हैं जिनके पास एक .Museum शीर्ष स्तर का डोमेन है जो इसके लिए अनुमत 4 वर्णों से अधिक लंबा है। मैं इस समझौते को स्वीकार करता हूं क्योंकि इस शीर्ष-स्तरीय डोमेन का उपयोग करने वाले लोगों की संख्या बहुत कम है। मुझे कभी भी शिकायत नहीं मिली है कि मेरी कंपनी की वेबसाइटों पर ऑर्डर फॉर्म या न्यूज़लेटर सदस्यताएँ .museum के साथ एक पते का उपयोग करने से इनकार करती हैं।

.Museum को सक्षम करने के लिए, आप इस अभिव्यक्ति का उपयोग कर सकते हैं:

 ^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[AZ]{2,6}$ 

लेकिन यह एक और समझौता है। यह एक्सप्रेशन john@mail.office के पते पर मिलेगा । यह बहुत अधिक संभावना है कि जॉन उस पते के अंत में .com को शामिल करना भूल गया। उसने ICANN की अनुमति के बिना .office शीर्ष स्तर डोमेन बनाया।

ऊपर दिया गया उदाहरण एक अन्य व्यापार-बंद दिखाता है: क्या आप चाहते हैं कि एक उच्च-स्तरीय डोमेन मौजूद हो या नहीं? मेरी नियमित अभिव्यक्ति नहीं है। दो से चार वर्णों का कोई भी संयोजन सभी मौजूदा (और नियोजित) शीर्ष-स्तरीय डोमेन को कवर करेगा, जो कि .Museum [और .travel - लगभग के अपवाद के साथ है। प्रति। ] लेकिन यह asdf@asdf.asdf के अवैध ई-मेल पते निर्धारित करेगा। शीर्ष-स्तरीय डोमेन पर अत्यधिक सख्त होने के बिना, जब भी अगला डोमेन बनाया जाता है, मुझे नियमित अभिव्यक्ति अपडेट नहीं करनी होती है।

 ^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.(?:[AZ]{2}|com|org|net|edu|gov|mil|biz|info|mobi|name|aero|asia|jobs|museum)$ 

यह नियमित अभिव्यक्ति किसी भी दो-अक्षर वाले देश कोड और केवल विशिष्ट सामान्य शीर्ष-स्तरीय डोमेन के लिए उपयोग की जा सकती है। यह सूची इस समय पुरानी हो सकती है। मैं आपके आवेदन में वैश्विक सूची के रूप में इस सूची को सहेजने की सलाह देता हूं ताकि आपको केवल एक ही स्थान पर इसे अपडेट करना पड़े। आप सभी देश कोड भी सूचीबद्ध कर सकते हैं, हालांकि उनमें से लगभग दो सौ पहले से हैं।

एक ईमेल पते को एक उपडोमेन पर भी पंजीकृत किया जा सकता है, उदाहरण के लिए john@mail.company.com । उपरोक्त सभी नियमित अभिव्यक्तियाँ इस पते को परिभाषित करेंगी, जैसा कि मैंने "" वर्ण चरित्र वर्ग में @ जोड़ा है। लेकिन वे john @ aol ... com का भी निर्धारण करेंगे, जो सच नहीं है। आप " [A-Z0-9 .-] + \ _ " के साथ " ((?: [[A-Z0-9 -] + \ _।) + " को बदलकर ऐसे मामलों को समाप्त कर सकते हैं। मैंने चरित्र वर्ग से बिंदु को हटा दिया और इसके बजाय उस वर्ग और बिंदु चरित्र को दोहराया। उदाहरण के लिए

 \b[A-Z0-9._%+-]+@(?:[A-Z0-9-]+\.)+[AZ]{2,4}\b 

john@server.depbox.company.com निर्धारित करेगा , लेकिन जॉन @ aol ... com नहीं ।

एक और व्यापार बंद है कि मेरे नियमित भाव केवल लैटिन अक्षर, संख्या और कुछ विशेष वर्णों की अनुमति देते हैं। इसका मुख्य कारण यह है कि मुझे यकीन नहीं है कि मेरी मेल सेवा बाकी पात्रों को संभाल सकती है। भले ही John.O'Hara@theoharas.com एक सिंटैक्टिकली सही ई-मेल एड्रेस है, लेकिन एक खतरा है कि कुछ मेल प्रोग्राम एपोस्ट्रोफ को कोटेशन सीमांकक के रूप में मानते हैं। उदाहरण के लिए, SQL में इस पते को नेत्रहीन रूप से सम्मिलित करने पर क्रैश हो जाएगा यदि तार एकल उद्धरण द्वारा अलग हो जाते हैं। और, ज़ाहिर है, कई सालों तक, डोमेन में गैर-लैटिन वर्ण शामिल हो सकते हैं। अधिकांश कार्यक्रम और यहां तक ​​कि डोमेन रजिस्ट्रार, हालांकि, अभी भी उन 37 वर्णों का पालन करते हैं, जिनका वे उपयोग करते हैं।

निष्कर्ष यह है: यह तय करने के लिए कि किस नियमित अभिव्यक्ति का उपयोग करना है, इससे कोई फर्क नहीं पड़ता कि आप एक ई-मेल पता या कुछ और ठीक से परिभाषित करने जा रहे हैं, तो आपको सभी ट्रेड-ऑफ पर विचार करके शुरू करना होगा। यह तथ्य कितना बुरा है कि जो मिला है वह सत्य नहीं है? कितना बुरा है कि कुछ वास्तविक नहीं मिला है? आपकी नियमित अभिव्यक्ति कितनी जटिल हो सकती है? इस भाव को बदलने के लिए आप किस कीमत का भुगतान करेंगे? इन सवालों के अलग-अलग जवाबों को समाधान के रूप में अलग-अलग नियमित अभिव्यक्तियों की आवश्यकता होती है। मेरे नियमित एक्सप्रेशन वही करते हैं जो मैं चाहता हूं, लेकिन वे वह नहीं कर सकते जो आप चाहते हैं।

नियमित अभिव्यक्ति ई-मेल नहीं भेजती है

अपने नियमित अभिव्यक्ति में अमान्य ईमेल पतों को समाप्त करने के अपने प्रयासों को ज़्यादा मत करो। यदि आपको .museum को सक्षम करने की आवश्यकता है, तो सभी मौजूदा डोमेन को सूचीबद्ध करने की तुलना में सभी छह-वर्ण शीर्ष-स्तरीय डोमेन को अनुमति देना अक्सर बेहतर होता है। कारण यह है कि आप वास्तव में यह नहीं जानते हैं कि क्या यह ई-मेल पता तब तक मान्य है जब तक आप इसे ईमेल भेजने का प्रयास नहीं करते। और यहां तक ​​कि यह पर्याप्त नहीं हो सकता है। भले ही पत्र मेलबॉक्स में आता है, इसका मतलब यह नहीं है कि कोई इसे पढ़ेगा।

एक ही सिद्धांत कई स्थितियों में लागू होता है। जब एक वैध तिथि खोजने की कोशिश की जा रही है, तो एक नियमित अभिव्यक्ति के अंदर ऐसा करने की कोशिश करने की तुलना में लीप वर्षों को निर्धारित करने के लिए थोड़ा अंकगणित जोड़ना आसान होता है। संभावित मिलान खोजने के लिए नियमित अभिव्यक्तियों का उपयोग करें, या यह देखने के लिए जांचें कि इनपुट आवश्यक सिंटैक्स से मेल खाता है, और नियमित अभिव्यक्ति द्वारा पाए गए उम्मीदवारों के लिए वैध परीक्षण करें। नियमित अभिव्यक्ति एक शक्तिशाली उपकरण है, लेकिन रामबाण नहीं है।

आधिकारिक मानक: RFC 2822

शायद आप सोच रहे हैं कि ईमेल पते खोजने के लिए "आधिकारिक" विश्वसनीय नियमित अभिव्यक्ति क्यों नहीं है? खैर, यहाँ आधिकारिक परिभाषा है, लेकिन यह शायद ही विश्वसनीय है।

आधिकारिक मानक RFC 2822 के रूप में जाना जाता है। यह सिंटैक्स का वर्णन करता है कि मान्य ईमेल पते का पालन करना चाहिए। आप इसे (लेकिन नहीं करना चाहिए) निम्नलिखित नियमित अभिव्यक्ति के साथ लागू कर सकते हैं:

 (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) 

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

@ के बाद के भाग में भी दो विकल्प हैं। यह या तो पूरी तरह से योग्य डोमेन नाम हो सकता है (उदाहरण के लिए, example.com) या वर्ग कोष्ठक में शाब्दिक इंटरनेट पता। शाब्दिक इंटरनेट एड्रेस एक आईपी एड्रेस या एक विषय-उन्मुख रूटिंग एड्रेस हो सकता है।

कारण आपको इस नियमित अभिव्यक्ति का उपयोग नहीं करना चाहिए क्योंकि यह केवल ईमेल पते के मूल सिंटैक्स की जांच करता है। john@aol.com.nospam को RFC 2822 के अनुसार एक वैध ईमेल पता माना जाएगा। जाहिर है, यह ईमेल पता काम नहीं करेगा, क्योंकि कोई .nospam शीर्ष-स्तरीय डोमेन नहीं है। यह भी गारंटी नहीं है कि आपका ईमेल प्रोग्राम इसे संभाल सकता है। सभी एप्लिकेशन दोहरे उद्धरण चिह्नों या वर्ग कोष्ठक का उपयोग करके वाक्यविन्यास का समर्थन नहीं करते हैं। वास्तव में, RFC 2822 स्वयं वर्गाकार कोष्ठक के उपयोग को चिह्नित करता है।

यदि हम उन हिस्सों को छोड़ देते हैं जहां डबल कोट्स और स्क्वायर ब्रैकेट्स का उपयोग किया जाता है, तो हम RFC 2822 का अधिक व्यावहारिक कार्यान्वयन प्राप्त करेंगे। यह अभी भी 99.99% सभी ईमेल पतों से मेल खाता है जो वास्तविक उपयोग में हैं।

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

एक और बदलाव जो आप कर सकते हैं वह है शीर्ष-स्तरीय डोमेन के लिए किसी भी दो-अक्षर वाले देश कोड, और केवल विशिष्ट जेनेरिक शीर्ष-स्तरीय डोमेन के लिए अनुमति देना। यह रेगुलर एक्सप्रेशन ddf ईमेल एड्रेस जैसे asdf@adsf.adsf को फिल्टर करता है । नए शीर्ष-स्तरीय डोमेन जोड़ते ही आपको इसे अपडेट करना होगा।

 [a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[AZ]{2}|com|org|net|edu|gov|mil|biz|info|mobi|name|aero|asia|jobs|museum)\b 

इसलिए आधिकारिक मानकों का पालन करने के बाद भी, समझौते अभी भी बने हुए हैं। ऑनलाइन लाइब्रेरी या फ़ोरम से नियमित अभिव्यक्तियों को नेत्रहीन कॉपी न करें। हमेशा उन्हें अपने डेटा पर और अपने स्वयं के अनुप्रयोगों के साथ परीक्षण करें।