एएसपी.NET 3.5 सत्यापन के साथ ईमेल प्रारूप सत्यापन के लिए सर्वश्रेष्ठ नियमित अभिव्यक्ति

Question

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

 
- \w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)* 
- ^([0-9a-zA-Z]([-\.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})$ 

मैं "तेजी से धीमी गति से अभिव्यक्ति" BCL Team Blog पर वर्णित समस्या से बचने की कोशिश कर रहा हूँ।

अद्यतन

प्रतिक्रिया के आधार पर मैं एक ईमेल मान्य है अगर परीक्षण करने के लिए एक समारोह बना दी:

Public Function IsValidEmail(ByVal emailString As String, Optional ByVal isRequired As Boolean = False) As Boolean 
    Dim emailSplit As String() 
    Dim isValid As Boolean = True 
    Dim localPart As String = String.Empty 
    Dim domainPart As String = String.Empty 
    Dim domainSplit As String() 
    Dim tld As String 

    If emailString.Length >= 80 Then 
     isValid = False 
    ElseIf emailString.Length > 0 And emailString.Length < 6 Then 
     'Email is too short 
     isValid = False 
    ElseIf emailString.Length > 0 Then 
     'Email is optional, only test value if provided 
     emailSplit = emailString.Split(CChar("@")) 

     If emailSplit.Count <> 2 Then 
      'Only 1 @ should exist 
      isValid = False 
     Else 
      localPart = emailSplit(0) 
      domainPart = emailSplit(1) 
     End If 

     If isValid = False OrElse domainPart.Contains(".") = False Then 
      'Needs at least 1 period after @ 
      isValid = False 
     Else 
      'Test Local-Part Length and Characters 
      If localPart.Length > 64 OrElse ValidateString(localPart, ValidateTests.EmailLocalPartSafeChars) = False OrElse _ 
       localPart.StartsWith(".") OrElse localPart.EndsWith(".") OrElse localPart.Contains("..") Then 
       isValid = False 
      End If 

      'Validate Domain Name Portion of email address 
      If isValid = False OrElse _ 
       ValidateString(domainPart, ValidateTests.HostNameChars) = False OrElse _ 
       domainPart.StartsWith("-") OrElse domainPart.StartsWith(".") OrElse domainPart.Contains("..") Then 
       isValid = False 
      Else 
       domainSplit = domainPart.Split(CChar(".")) 
       tld = domainSplit(UBound(domainSplit)) 

       ' Top Level Domains must be at least two characters 
       If tld.Length < 2 Then 
        isValid = False 
       End If 
      End If 
     End If 
    Else 
     'If no value is passed review if required 
     If isRequired = True Then 
      isValid = False 
     Else 
      isValid = True 
     End If 
    End If 

    Return isValid 
End Function 

नोट्स:

• IsValidEmail अनुमति पात्रों के बारे में अधिक प्रतिबंधात्मक है फिर आरएफसी, लेकिन यह उन पात्रों के सभी संभावित अमान्य उपयोगों के लिए परीक्षण नहीं करता है

Answer 1

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

एक और समस्या यह है कि आपके दो regexes मिलान कर सकते हैं तारों के प्रकार में काफी भिन्नता है। उदाहरण के लिए, दूसरा सिरों दोनों अंगों पर लंगर है, लेकिन पहला नहीं है; यह ">>>>foo@bar.com<<<<" से मेल खाता है क्योंकि ऐसा कुछ ऐसा है जो इसमें एम्बेड किए गए ईमेल पते जैसा दिखता है। हो सकता है कि फ्रेमवर्क पूरे स्ट्रिंग से मेल खाने के लिए रेगेक्स को मजबूर करे, लेकिन यदि ऐसा है, तो दूसरे को एंकर क्यों किया जाता है?

एक और अंतर यह है कि पहला रेगेक्स पूरे \w का उपयोग करता है, जबकि दूसरे स्थान पर [0-9a-zA-Z] का उपयोग करता है। अधिकांश रेगेक्स स्वादों में, \w अक्षरों और अंकों के अलावा अंडरस्कोर से मेल खाता है, लेकिन कुछ (.NET सहित) में यह यूनिकोड को ज्ञात प्रत्येक लेखन प्रणाली से अक्षरों और अंकों से मेल खाता है।

कई अन्य अंतर हैं, लेकिन यह अकादमिक है; उन regexes में से कोई भी बहुत अच्छा है। विषय की अच्छी चर्चा के लिए here देखें, और एक बेहतर रेगेक्स।

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

([A-Za-z]+|\w+)@ 

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

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

[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])* 

सब हिस्से का कार्य करता यकीन है जबकि कुछ अतिरिक्त वर्ण की इजाजत दी पहली और आखिरी पात्रों अक्षरांकीय कर रहे हैं है के बीच में। इस संस्करण में एक ही बात करता है, लेकिन यह अधिक तेजी से जब कोई मुकाबला संभव है विफल रहता है:

[0-9a-zA-Z][-.\w]*[0-9a-zA-Z] 

कि शायद बैक ट्रैकिंग समस्या को खत्म करने के लिए पर्याप्त होगा, लेकिन आप भी "@" और अधिक कुशल के बाद भाग कर सकता है एक परमाणु समूह का उपयोग करके:

(?>(?:[0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+)[a-zA-Z]{2,9} 

दूसरे शब्दों में, अगर आप सभी आप सबस्ट्रिंग कि अनुगामी डॉट्स के साथ डोमेन घटकों की तरह लग रही के कर सकते हैं मिलान किया गया है, और अगले भाग एक टीएलडी तरह नहीं दिखता है, डॉन ' बैकट्रैकिंग परेशान नहीं है। पहला अक्षर आपको छोड़ना होगा अंतिम बिंदु है, और आप जानते हैं कि [a-zA-Z]{2,9} उस से मेल नहीं खाएगा।

Answer 2

योगदान करने के लिए, मैं इस रेगेक्स का उपयोग कर रहा हूं।

^([a-zA-Z0-9]+[a-zA-Z0-9._%-]*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,4})$ 

Answer 3

ये email address RFC के अनुसार सभी स्वीकार्य ईमेल पते की जांच नहीं करते हैं।

Answer 4

हम इस RegEx का उपयोग करते हैं जिसे 1.5 मिलियन पते के विरुद्ध घर में परीक्षण किया गया है। यह हमारे 98% से बेहतर ढंग से पहचानता है, लेकिन कुछ प्रारूप हैं जिन्हें मैं जानता हूं कि इससे त्रुटि होगी।

^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$ 

हम यह भी सुनिश्चित करें कि डेटा में कोई EOL पात्रों एक EOL इस रेगुलर एक्सप्रेशन से बाहर नकली कर सकते हैं के बाद से देखते हैं कि सुनिश्चित करें। हमारे फंक्शन:

Public Function IsValidEmail(ByVal strEmail As String) As Boolean 
    ' Check An eMail Address To Ensure That It Is Valid 
    Const cValidEmail = "^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$" ' 98% Of All Valid eMail Addresses 
    IsValidEmail = False 
    ' Take Care Of Blanks, Nulls & EOLs 
    strEmail = Replace(Replace(Trim$(strEmail & " "), vbCr, ""), vbLf, "") 
    ' Blank eMail Is Invalid 
    If strEmail = "" Then Exit Function 
    ' RegEx Test The eMail Address 
    Dim regEx As New System.Text.RegularExpressions.Regex(cValidEmail) 
    IsValidEmail = regEx.IsMatch(strEmail) 
End Function 

Answer 5

मैं एमएस मेरे लिए काम करने के लिए करते हैं:

Public Function IsValidEmail(ByVal emailString As String) As Boolean 
    Dim retval As Boolean = True 
    Try 
     Dim address As New System.Net.Mail.MailAddress(emailString) 
    Catch ex As Exception 
     retval = False 
    End Try 
    Return retval 
End Function 

Answer 6

मैं एक नौसिखिया हूँ, लेकिन मैं निम्नलिखित की कोशिश की और यह ".xxx" केवल तक ही सीमित है लग रहा था प्रतीक '@' के बाद दो घटनाएं या उससे कम।

^([a-zA-Z0-9]+[a-zA-Z0-9._%-]*@(?:[a-zA-Z0-9-])+(\.+[a-zA-Z]{2,4}){1,2})$ 

नोट: डबल के साथ एक स्थानापन्न मैं था '\' '\\' के रूप में मैं आर

Answer 7

में इस reg expr उपयोग कर रहा हूँ सर्वर साइड सत्यापन के लिए, मैं फिल Haack के समाधान पाया एक होने की बेहतर लोगों का। उनका प्रयास आरएफसी से चिपक गया था:

string pattern = @"^(?!\.)(""([^""\r\\]|\\[""\r\\])*""|" 
      + @"([-a-z0-9!#$%&'*+/=?^_`{|}~]|(?<!\.)\.)*)(?<!\.)" 
      + @"@[a-z0-9][\w\.-]*[a-z0-9]\.[a-z][a-z\.]*[a-z]$"; 

Regex regex = new Regex(pattern, RegexOptions.IgnoreCase); 
return regex.IsMatch(emailAddress); 

विवरण: http://blog.degree.no/2013/01/email-validation-finally-a-net-regular-expression-that-works/

Answer 8

इसके बारे में बात विनिर्देशों प्रत्येक डोमेन एक्सटेंशन है कि शुरू की है के साथ बदलती रहती हैं।

आप यहां अपने रेगेक्स, परीक्षण, परीक्षण, परीक्षण और अधिक परीक्षण को संशोधित करते हैं। आखिरकार आप जो सोचते हैं वह सटीक होता है, तो विनिर्देश बदलता है ... आप अपनी आवश्यकताओं को ध्यान में रखते हैं कि नई आवश्यकताएं क्या हैं ..

तब कोई aa@aa.aa में प्रवेश करता है और आपने वह सब किया है क्या काम करता है? यह आपके फैंसी रेगेक्स के माध्यम से चलता है .. बमर!

आप भी एक ही @, और एक "के लिए जांच सकते हैं।"और आगे बढ़ो। मैं आपको आश्वस्त करता हूं, अगर आप इसे देना नहीं चाहते हैं तो आपको कुछ ईमेल नहीं मिलेगा। आपको कचरा या उनके हॉटमेल खाते मिलेंगे, वे कभी भी जांच नहीं करेंगे और कम परवाह नहीं कर सकते हैं।

I 'कई मामलों में देखा यह बुरी तरह गलत हो जाता है और एक ग्राहक कॉल क्योंकि उनके खुद के ईमेल पते एक खराब गढ़ी regex की जांच की वजह से अस्वीकार कर दिया है कौन सा रूप में उल्लेख किया भी प्रयास किया गया है नहीं करना चाहिए

Answer 9

पाठ बॉक्स: -।।

<asp:TextBox ID="txtemail" runat="server" CssClass="form-control pantxt" Placeholder="Enter Email Address"></asp:TextBox> 

आवश्यक दायर सत्यापनकर्ता:

<asp:RequiredFieldValidator ID="RequiredFieldValidator9" runat="server" ControlToValidate="txtemail" ErrorMessage="Required"></asp:RequiredFieldValidator> 

ईमेल सत्यापन के लिए

नियमित अभिव्यक्ति: // stackoverflow:

<asp:RegularExpressionValidator ID="validateemail" runat="server" ControlToValidate="txtemail" ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*" ErrorMessage="Invalid Email"></asp:RegularExpressionValidator> 

asp.net

[सी # में ईमेल सत्यापन के लिए सर्वश्रेष्ठ नियमित अभिव्यक्ति] की