ईमेल एड्रेस प्रोसेसिंग के लिए रेगेक्स की व्यावहारिकता पर

एक सहयोगी ने हाल ही में मुझे एक ब्लॉग पोस्ट की ओर इशारा किया: ईमेल रेगेक्स सत्यापन की व्यर्थता पर । संक्षिप्तता के लिए, मैं इस लेख में इसे व्यर्थता के रूप में संदर्भित करूँगा।

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

ऐसा इसलिए है क्योंकि यह RFC 5322 मैसेज हेडर को RFC 5321 एड्रेस लिटरल से मिलाता है; जो, सरल भाषा में, इसका अर्थ है कि एक मान्य SMTP ईमेल पता क्या होता है, सामान्य रूप से एक मान्य संदेश शीर्षलेख बनाने वाले से भिन्न होता है।

यह इसलिए भी है क्योंकि यह पाठक को किनारे के मामलों में व्यस्त होने के लिए उकसाता है जो सैद्धांतिक रूप से मानक दृष्टिकोण से संभव हैं, लेकिन जो मैं प्रदर्शित करूंगा, "जंगली में" होने की एक असीम संभावना है।

यह लेख इन दोनों कथनों पर विस्तार करेगा, ईमेल रेगेक्स के लिए कुछ संभावित उपयोग के मामलों पर चर्चा करेगा, और व्यावहारिक ईमेल रेगेक्स के एनोटेट "कुकबुक" उदाहरणों के साथ समाप्त होगा।

RFC 5321 5322 का स्थान लेता है

ईमेल के प्रसारण के लिए एसएमटीपी की सार्वभौमिकता का अर्थ है कि एक व्यावहारिक मामले के रूप में, प्रासंगिक आईईटीएफ आरएफसी, जो कि 5321 है, को ध्यान से पढ़े बिना ईमेल एड्रेस फॉर्मेटिंग की कोई परीक्षा पूरी नहीं होती है।

5322 ईमेल पतों को केवल एक सामान्य संदेश हेडर के रूप में मानता है, जिसमें कोई विशेष मामला नियम लागू नहीं होता है। इसका मतलब यह है कि कोष्ठक में संलग्न टिप्पणियाँ डोमेन नाम में भी मान्य हैं।

फ्यूटिलिटी में संदर्भित परीक्षण सूट में 10 परीक्षण शामिल हैं जिनमें टिप्पणियाँ, या विशेषक या यूनिकोड वर्ण शामिल हैं, और इंगित करता है कि उनमें से 8 वैध ईमेल पते का प्रतिनिधित्व करते हैं।

यह गलत है क्योंकि RFC 5321 यह बताते हुए स्पष्ट है कि ईमेल पतों के डोमेन नाम भाग " ASCII वर्ण सेट से खींचे गए अक्षरों, अंकों और हाइफ़न के अनुक्रम से युक्त होने के लिए SMTP उद्देश्यों के लिए प्रतिबंधित हैं। "

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

यह सत्यापन के संदर्भ में कुछ अन्य व्यावहारिक विचारों को भी दर्शाता है जिसे हम आगे देखेंगे।

जंगली में मेलबॉक्स नाम

दोनों RFC के अनुसार, "@" प्रतीक के बाईं ओर ईमेल पते के हिस्से का तकनीकी नाम "मेलबॉक्स" है। दोनों RFC मेलबॉक्स भाग में कौन से वर्ण स्वीकार्य हैं, इसमें काफी अक्षांश की अनुमति देते हैं।

एकमात्र महत्वपूर्ण व्यावहारिक बाधा यह है कि उद्धरण या कोष्ठक संतुलित होना चाहिए, कुछ ऐसा जो वैनिला रेगेक्स में सत्यापित करने के लिए एक वास्तविक चुनौती है।

हालाँकि वास्तविक-विश्व मेलबॉक्स कार्यान्वयन फिर से वह उपाय है जो व्यावहारिक प्रोग्रामर को नियोजित करना चाहिए।

एक नियम के रूप में, जो लोग हमें भुगतान करते हैं, वे हमारे बिल योग्य घंटों के 90% को 10% सैद्धांतिक किनारे के मामलों को हल करने के लिए निर्देशित करते हैं जो संभवतः वास्तविक जीवन में बिल्कुल भी मौजूद नहीं हो सकते हैं।

आइए प्रमुख ईमेल मेलबॉक्स प्रदाताओं, उपभोक्ताओं और व्यवसायों को देखें, और विचार करें कि वे किस प्रकार के ईमेल पतों की अनुमति देते हैं।

उपभोक्ता ईमेल के लिए, मैंने ट्विटर खातों से लीक हुए 5,280,739 ईमेल पतों की सूची का उपयोग करते हुए कुछ प्राथमिक शोध किया।

115 मिलियन ट्विटर खातों के आधार पर, यह हमें ट्विटर की पूरी आबादी के लिए त्रुटि के 0.055% मार्जिन के साथ 99% आत्मविश्वास का स्तर देता है, जो सभी इंटरनेट ईमेल पतों की सामान्य आबादी का बहुत प्रतिनिधि होगा। यहाँ मैंने सीखा है:

• 82% पतों में केवल ASCII अल्फ़ान्यूमेरिक वर्ण होते हैं,

• 15% में सभी पतों के 97% के लिए केवल ASCII अल्फ़ान्यूमेरिक और डॉट्स (ASCII अवधि) शामिल हैं,

• नाममात्र 100% ईमेल पतों के लिए 3% में केवल ASCII अल्फ़ान्यूमेरिक, डॉट्स और डैश होते हैं।

हालाँकि, यह एक गोल 100% है। सामान्य ज्ञान के प्रेमियों के लिए, मैंने यह भी पाया:

• कुल के 0.00072% के लिए अंडरस्कोर के साथ 38 पते

• 0.00051% के लिए प्लस चिह्नों के साथ 27, और

• कुल का 0.00002% का प्रतिनिधित्व करने वाले यूनिकोड वर्णों वाला 1 पता।

शुद्ध प्रभाव यह है कि ईमेल पता मेलबॉक्स में केवल ASCII अल्फ़ान्यूमेरिक, डॉट्स और डैश होते हैं, जो आपको उपभोक्ता ईमेल के लिए 5 9 की सटीकता से बेहतर देंगे।

व्यावसायिक ईमेल के लिए, डेटानीज़ की रिपोर्ट है कि 6,771,269 कंपनियां 91 विभिन्न ईमेल होस्टिंग समाधानों का उपयोग करती हैं। हालाँकि पेरेटो वितरण कायम है, और उन मेलबॉक्सों में से 95.19% को केवल 10 सेवा प्रदाताओं द्वारा होस्ट किया जाता है।

व्यवसाय के लिए जीमेल (34.35% बाजार हिस्सेदारी)

मेलबॉक्स बनाते समय Google केवल ASCII अक्षरों, संख्याओं और बिंदुओं की अनुमति देता है। हालांकि यह ईमेल प्राप्त करते समय धन चिह्न को स्वीकार करेगा।

माइक्रोसॉफ्ट एक्सचेंज ऑनलाइन (33.60%)

केवल ASCII अक्षरों, संख्याओं और बिंदुओं की अनुमति देता है।

GoDaddy ईमेल होस्टिंग (14.71%)

Microsoft 365 का उपयोग करता है, और केवल ASCII अक्षरों, संख्याओं और बिंदुओं की अनुमति देता है।

7 अतिरिक्त प्रदाता (12.53%)

प्रलेखित नहीं।

दुर्भाग्य से, हम केवल 82% व्यवसायों के बारे में निश्चित हो सकते हैं और हम नहीं जानते कि कितने मेलबॉक्स प्रतिनिधित्व करते हैं। हालाँकि, हम जानते हैं कि ट्विटर ईमेल पतों में, 173,467 डोमेन में से केवल 400 में 100 से अधिक व्यक्तिगत ईमेल मेलबॉक्स का प्रतिनिधित्व किया गया था।

मेरा मानना है कि शेष 99% डोमेन में से अधिकांश व्यावसायिक ईमेल पते थे।

सर्वर या डोमेन स्तर पर मेलबॉक्स नामकरण नीतियों के संदर्भ में, मैं प्रस्ताव करता हूं कि इन 237,592 ईमेल पतों को 99% विश्वास स्तर और त्रुटि के 0.25% मार्जिन के साथ 1 बिलियन व्यावसायिक ईमेल पतों की आबादी का प्रतिनिधित्व करने के लिए उचित है, हमें दे रहा है 3 9 के करीब जब यह माना जाता है कि एक ईमेल पता मेलबॉक्स में केवल ASCII अल्फ़ान्यूमेरिक, डॉट्स और डैश होते हैं।

बक्सों का इस्तेमाल करें

फिर से, हमारे दिमाग में व्यावहारिकता को सबसे पहले रखते हुए, आइए विचार करें कि किन परिस्थितियों में हमें एक वैध ईमेल पते की प्रोग्रामेटिक रूप से पहचान करने की आवश्यकता हो सकती है।

नया खाता निर्माण/उपयोगकर्ता पंजीकरण

इस उपयोग के मामले में, एक संभावित नया ग्राहक खाता बनाने का प्रयास कर रहा है। दो उच्च-स्तरीय रणनीतियाँ हैं जिन पर हम विचार कर सकते हैं। पहले मामले में, हम यह सत्यापित करने का प्रयास करते हैं कि नए उपयोगकर्ता द्वारा प्रदान किया गया ईमेल पता मान्य है और समकालिक रूप से खाता निर्माण के लिए आगे बढ़ें।

आप इस तरीके को क्यों नहीं अपनाना चाहते इसके दो कारण हो सकते हैं। पहला यह है कि हालाँकि आप यह सत्यापित करने में सक्षम हो सकते हैं कि ईमेल पते का एक वैध रूप है, फिर भी यह मौजूद नहीं हो सकता है।

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

संपर्क प्रपत्र

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

तो एक बार फिर, एक फॉर्म में दर्ज स्ट्रिंग के प्रोग्रामेटिक सत्यापन की तुलना में फायर-एंड-भूल मॉडल एक बेहतर विकल्प है।

रेफरर लॉग और डेटा के अन्य बड़े संस्करणों का विश्लेषण।

यह हमें सामान्य रूप से प्रोग्रामेटिक ईमेल एड्रेस आइडेंटिफिकेशन के लिए वास्तविक उपयोग के मामले की ओर ले जाता है, और विशेष रूप से रेगेक्स: असंरचित पाठ के बड़े हिस्से को अज्ञात या खनन करना।

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

ये करोड़ों लाइनों वाली फाइलें थीं, और एक दिन में सैकड़ों फाइलें थीं। "पंक्तियाँ" लगभग एक हज़ार वर्ण लंबी हो सकती हैं।

एक पंक्ति में वर्णों के माध्यम से पुनरावृति करना, जटिल परीक्षण लागू करना (उदाहरण के लिए, यह लाइन में @ की पहली घटना है और क्या यह फ़ाइल नाम का हिस्सा है जैसे कि imagefile@2x.png ?) लूप और मानक स्ट्रिंग फ़ंक्शंस का उपयोग करके बनाया गया होगा एक समय जटिलता जो असंभव रूप से बड़ी थी।

दरअसल, इस (बहुत बड़ी) कंपनी की इन-हाउस डेवलपमेंट टीम ने इसे असंभव काम करार दिया था।

मैंने निम्नलिखित संकलित रेगेक्स लिखा था:

search_pattern = re.compile("[a-zA-Z0-9\!\#\$\%\'\*\+\-\^\_\`\{\|\}\~\.]+@|\%40(?!(\w+\.)**(jpg|png))(([\w\-]+\.)+([\w\-]+)))")

और इसे निम्नलिखित पायथन सूची समझ में गिरा दिया:

results = [(re.sub(search_pattern, "redacted@example.com", line)) for line in file]

मुझे याद नहीं है कि यह कितनी तेज थी, लेकिन यह तेज थी। मेरा दोस्त इसे लैपटॉप पर चला सकता है और मिनटों में किया जा सकता है। यह सटीक था। हमने इसे 5 9 पर फाल्स नेगेटिव और फाल्स पॉजिटिव दोनों को देखते हुए देखा।

रेफरर लॉग के रूप में इस तथ्य से मेरा काम कुछ हद तक आसान हो गया था; उनमें केवल URL "कानूनी" वर्ण हो सकते हैं, इसलिए मैं किसी भी टक्कर को मैप करने में सक्षम था जिसे मैंने रेपो रीडमी में प्रलेखित किया था।

इसके अलावा, मैं इसे और भी सरल (और तेज़) बना सकता था यदि मैंने ईमेल पता विश्लेषण किया होता और इस आश्वासन के साथ सीखा होता कि 5 9 के लक्ष्य को प्राप्त करने के लिए केवल ASCII अल्फ़ान्यूमेरिक, डॉट्स और डैश की आवश्यकता थी।

फिर भी, यह व्यावहारिकता का एक अच्छा उदाहरण है और वास्तविक समस्या को हल करने के लिए हल करने के लिए समाधान की गुंजाइश है।

सभी प्रोग्रामिंग विद्या और इतिहास में सबसे महान उद्धरणों में से एक महान वार्ड कनिंघम की नसीहत है कि आप जो हासिल करने की कोशिश कर रहे हैं उसे याद रखने के लिए एक सेकंड लें, और फिर खुद से पूछें "सबसे सरल चीज क्या है जो संभवतः काम कर सकती है?"

बड़ी मात्रा में असंरचित पाठ से एक ईमेल पते को पार्स करने (और वैकल्पिक रूप से बदलने) के उपयोग के मामले में, यह समाधान निश्चित रूप से सबसे सरल चीज थी जिसके बारे में मैं सोच सकता था।

एनोटेट कुकबुक

जैसा कि मैंने शुरुआत में कहा था, मुझे एक RFC 5322 अनुरूप रेगेक्स मनोरंजक बनाने का विचार मिला, इसलिए मैं आपको मानक के विभिन्न पहलुओं से निपटने के लिए रेगेक्स के संयोजन योग्य भाग दिखाऊंगा और समझाऊंगा कि रेगेक्स नीतियां कैसी हैं। अंत में, मैं आपको दिखाऊंगा कि यह सब इकट्ठे होकर कैसा दिखता है।

एक ईमेल पते की संरचना है:

1. मेलबॉक्स
2. कानूनी पात्र
3. सिंगल डॉट्स (डबल डॉट्स कानूनी नहीं हैं)
4. फ़ोल्ड किया हुआ सफ़ेद स्थान (RFC 5322 पागलपन)
5. (एक पूर्ण रेगेक्स समाधान में संतुलित कोष्ठक और/या उद्धरण भी शामिल होंगे, लेकिन मेरे पास अभी तक नहीं है। और संभवतः कभी नहीं होगा।)
6. सीमांकक (@)
7. डोमेन नाम
8. मानक डीएनएस पार्स करने योग्य डोमेन
9. IPv4 पता शाब्दिक
10. IPv6 पता शाब्दिक
11. IPv6-पूर्ण
12. IPv6-COMP (संपीड़ित के लिए)
13. पहला रूप (बीच में शून्य के 2+ 16-बिट समूह)
14. दूसरा रूप (शुरुआत में शून्य के 2+ 16-बिट समूह)
15. तीसरा रूप (अंत में शून्य के 2 16-बिट समूह)
16. चौथा रूप (शून्य के 8 16-बिट समूह)
17. IPv6v4-पूर्ण
18. IPv6v4-COMP (संपीड़ित)
19. पहला रूप
20. दूसरा रूप
21. तीसरा रूप
22. चौथा रूप

अब रेगेक्स के लिए।

मेलबॉक्स

^(?<mailbox>(\[a-zA-Z0-9\\+\\!\\#\\$\\%\\&\\'\\\*\\-\\/\\=\\?\\+\\\_\\\{\\}\\|\\\~]|(?<singleDot>(?<!\\.)(?<!^)\\.(?!\\.))|(?<foldedWhiteSpace>\\s?\\&\\#13\\;\\&\\#10\\;.))\{1,64})

सबसे पहले, हमारे पास ^ है जो स्ट्रिंग की शुरुआत में पहला अक्षर "लंगर" करता है। इसका उपयोग तब किया जाना चाहिए जब एक स्ट्रिंग को मान्य किया जाए जिसमें एक वैध ईमेल के अलावा कुछ भी न हो। यह सुनिश्चित करता है कि पहला चरित्र कानूनी है।

यदि इसके बजाय उपयोग केस एक लंबी स्ट्रिंग में ईमेल खोजने के लिए है, तो एंकर को छोड़ दें।

अगला, हमारे पास (?<mailbox> है। यह सुविधा के लिए कैप्चर समूह का नाम देता है। कैप्चर किए गए समूह के अंदर वैकल्पिक मिलान प्रतीक द्वारा अलग किए गए तीन रेगेक्स चंक्स हैं | जिसका अर्थ है कि एक वर्ण तीन भावों में से किसी एक से मेल खा सकता है।

अच्छा (निष्पादक और पूर्वानुमेय) रेगेक्स लिखने का एक हिस्सा यह सुनिश्चित करना है कि तीन भाव परस्पर अनन्य हैं। कहने का तात्पर्य यह है कि एक सबस्ट्रिंग जो एक से मेल खाता है, वह निश्चित रूप से अन्य दो में से किसी से भी मेल नहीं खाएगा। ऐसा करने के लिए हम खूंखार . .* के बजाय विशिष्ट वर्ण वर्गों का उपयोग करते हैं।

बिना शर्त कानूनी वर्ण

[a-zA-Z0-9\+\!\#\$\%\&\'\*\-\/\=\?\+\_\{\}\|\~]

पहला वैकल्पिक मिलान वर्गाकार कोष्ठकों में संलग्न एक वर्ण वर्ग है, जो सभी ASCII वर्णों को कैप्चर करता है जो डॉट, "फोल्ड व्हाइट स्पेस", दोहरे उद्धरण और कोष्ठक को छोड़कर एक ईमेल मेलबॉक्स में कानूनी हैं।

हमने उन्हें बाहर करने का कारण यह है कि वे केवल सशर्त रूप से कानूनी हैं, कहने का तात्पर्य यह है कि आप उनका उपयोग कैसे कर सकते हैं, इसके बारे में नियम हैं जिन्हें मान्य किया जाना है। हम उन्हें अगले 2 वैकल्पिक मैचों में संभाल लेंगे।

singleDot

(?<singleDot>(?<!\.)(?<!^)\.(?!\.))

ऐसा पहला नियम डॉट (पीरियड) से संबंधित है। एक मेलबॉक्स में, डॉट को केवल कानूनी वर्णों के दो स्ट्रिंग्स के बीच एक विभाजक के रूप में अनुमति दी जाती है, इसलिए लगातार दो डॉट्स कानूनी नहीं हैं।

अगर लगातार दो डॉट हैं तो मैच को रोकने के लिए, हम रेगुलर एक्सप्रेशन नेगेटिव लुकबाइंड (?<!\.) उपयोग करते हैं जो निर्दिष्ट करता है कि अगला वर्ण (एक डॉट) मेल नहीं खाएगा यदि इससे पहले कोई डॉट है।

चारों ओर रेगेक्स लुक को जंजीर से बांधा जा सकता है। डॉट (?!^) पर पहुंचने से पहले एक और नकारात्मक नज़रिया है जो इस नियम को लागू करता है कि डॉट मेलबॉक्स का पहला अक्षर नहीं हो सकता।

डॉट के बाद, एक नेगेटिव लुक_आगे_ _(?!\.)_ है , यह डॉट को मैच होने से रोकता है अगर इसके तुरंत बाद डॉट आता है।

मुड़ा हुआव्हाइटस्पेस

(?<foldedWhiteSpace>\s?\&\#13\;\&\#10\;.)

संदेशों में बहु-पंक्ति शीर्षलेखों को अनुमति देने के बारे में यह कुछ आरएफसी 5322 बकवास है। मैं शर्त लगाने के लिए तैयार हूं कि ईमेल पतों के इतिहास में, कभी भी कोई ऐसा नहीं हुआ है जिसने गंभीरता से मल्टीलाइन मेलबॉक्स के साथ एक पता बनाया हो (हो सकता है कि उन्होंने इसे मजाक के रूप में किया हो)।

लेकिन मैं 5322 गेम खेल रहा हूं, इसलिए यहां यह यूनिकोड वर्णों की स्ट्रिंग है जो एक वैकल्पिक मैच के रूप में फोल्डेड व्हाइट स्पेस बनाता है।

संतुलित डबल उद्धरण और कोष्ठक

दोनों RFC वर्णों को संलग्न करने (या भागने ) के तरीके के रूप में दोहरे उद्धरणों के उपयोग की अनुमति देते हैं जो सामान्य रूप से अवैध होंगे।

वे टिप्पणियों को कोष्ठक में संलग्न करने की भी अनुमति देते हैं ताकि वे मानवीय रूप से पठनीय हों, लेकिन पते की व्याख्या करते समय मेल ट्रांसफर एजेंट (एमटीए) द्वारा विचार नहीं किया जाएगा।

दोनों ही मामलों में, वर्ण संतुलित होने पर ही कानूनी होते हैं। इसका मतलब यह है कि पात्रों की एक जोड़ी होनी चाहिए, एक जो खुलती है और एक जो बंद होती है ।

मैं यह लिखने के लिए ललचा रहा हूं कि मैंने एक प्रदर्शन मिराबिलेम की खोज की है, हालांकि, यह शायद मरणोपरांत ही काम करता है। सच्चाई यह है कि यह वेनिला रेगेक्स में गैर-तुच्छ है।

मेरे पास एक अंतर्ज्ञान है कि "लालची" रेगेक्स की पुनरावर्ती प्रकृति का लाभ उठाने के लिए शोषण किया जा सकता है, हालांकि, अगले कुछ सालों तक इस समस्या पर हमला करने के लिए आवश्यक समय समर्पित करने की संभावना नहीं है, और इसलिए सबसे अच्छी परंपरा में, मैं इसे छोड़ देता हूं पाठक के लिए एक अभ्यास के रूप में।

मेलबॉक्स की लंबाई

{1,64}

जो चीज वास्तव में मायने रखती है वह मेलबॉक्स की अधिकतम लंबाई है: 64 वर्ण।

इसलिए जब हम मेलबॉक्स कैप्चर समूह को अंतिम समापन कोष्ठक के साथ बंद करते हैं, तो हम यह निर्दिष्ट करने के लिए घुंघराले ब्रेसिज़ के बीच एक क्वांटिफायर का उपयोग करते हैं कि हमें कम से कम एक बार और 64 से अधिक बार अपने किसी भी विकल्प से मेल खाना चाहिए।

संकेत पर

\s?(?<atSign>(?<!\-)(?<!\.)\@(?!\@))

सीमांकक हिस्सा विशेष मामले के साथ शुरू होता है \s? क्योंकि व्यर्थता के अनुसार, सीमांकक से ठीक पहले एक स्थान कानूनी है, और मैं इसके लिए सिर्फ उनका वचन ले रहा हूं।

शेष कैप्चर समूह सिंगलडॉट के समान पैटर्न का अनुसरण करता है; यदि डॉट या डैश से पहले या तुरंत किसी अन्य @ द्वारा पीछा किया जाता है तो यह मेल नहीं खाएगा।

डोमेन नाम

यहां, जैसा कि मेलबॉक्स में होता है, हमारे पास 3 वैकल्पिक मिलान हैं। और इनमें से अंतिम ने इसमें अन्य 4 वैकल्पिक मैच रखे हैं।

मानक डीएनएस पारसेबल

(?<dns>[[:alnum:]]([[:alnum:]\-]{0,63}\.){1,24}[[:alnum:]\-]{1,63}[[:alnum:]])

यह व्यर्थता में कई परीक्षणों को पास नहीं करेगा, लेकिन जैसा कि पहले उल्लेख किया गया है, यह RFC 5321 का कड़ाई से अनुपालन करता है जिसमें अंतिम शब्द है।

आईपीवी 4

(?<IPv4>\[((?: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]?)\])

इस बारे में ज्यादा कुछ कहने की जरूरत नहीं है। यह IPv4 पतों के लिए एक प्रसिद्ध और आसानी से उपलब्ध रेगेक्स है।

आईपीवी6

(?<IPv6>(?<IPv6Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){8}\]))|(?<IPv6Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?\]))|(?<IPv6Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,6}\]))|(?<IPv6Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,6}\:\]))|(?<IPv6Comp4>(\[IPv6\:\:\:)\])|(?<IPv6v4Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){6}\:((?: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]?)\])|(?<IPv6v4Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?(\:((?: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]?))\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?(\:((?: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]?))\]))|(?<IPv6v4Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,5}(\:((?: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]?))\]))|(?<IPv6v4Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,5}\:(((?: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]?))\]))|(?<IPv6v4Comp4>(\[IPv6\:\:\:((?: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]?)\]))

मैं IPv6 (और IPv6v4) पतों के लिए एक अच्छी रेगुलर एक्सप्रेशन खोजने में असमर्थ था, इसलिए मैंने RFC 5321 के बैकस/नौर नोटेटेड नियमों का ध्यानपूर्वक पालन करते हुए अपना खुद का लिखा।

मैं IPv6 रेगेक्स के प्रत्येक उपसमूह की व्याख्या नहीं करूंगा, लेकिन मैंने प्रत्येक उपसमूह को नाम दिया है ताकि अलग-अलग चुनना आसान हो और देख सकें कि क्या हो रहा है।

IUPv6Comp1 कैप्चर समूह में "बाएं" पक्ष पर लालची मिलान और "दाएं" पर गैर-लालची को संयुक्त करने के तरीके को छोड़कर वास्तव में कुछ भी दिलचस्प नहीं है।

द फुल मोंटी

मैंने अंतिम रेगेक्स को व्यर्थता से परीक्षण डेटा के साथ सहेजा है, और अपने स्वयं के कुछ IPv6 परीक्षण मामलों द्वारा बढ़ाया गया है, Regex101 तक। मुझे उम्मीद है कि आपको यह लेख अच्छा लगा होगा, और यह आप में से कई लोगों के लिए उपयोगी और समय बचाने वाला साबित होगा।

AZW