नियमित अभिव्यक्ति इतनी विवादास्पद क्यों हैं? [बन्द है]


212

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

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

नियमित अभिव्यक्तियों को इतना विवादास्पद क्यों माना जाता है? क्या उनके काम करने के तरीके के बारे में व्यापक गलतफहमियाँ हैं? या यह एक व्यापक धारणा हो सकती है कि नियमित अभिव्यक्ति आम तौर पर धीमी होती है?


9
यदि यह चर्चा है, तो क्या इसे बंद नहीं किया जाना चाहिए? लेकिन मैं वहाँ एक असली सवाल देखते हैं तो शायद चर्चा टैग नहीं है?
RCIX

6
मजाक नहीं। आप इसे लाते हैं और लोग इधर-उधर हो जाते हैं।
रायन फ्लोरेंस

1
प्रश्न में अच्छा अवलोकन और शब्दांकन!
इम्ज़ - इवान ज़खरीशेव

इसके अलावा प्रोग्रामर
।stackexchange.com

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

जवाबों:


136

मुझे नहीं लगता कि लोग नियमित अभिव्यक्तियों पर आपत्ति जताते हैं क्योंकि वे धीमे हैं, बल्कि इसलिए कि वे पढ़ना और लिखना कठिन हैं, साथ ही सही पाने के लिए मुश्किल भी। हालांकि कुछ स्थितियाँ ऐसी होती हैं जहाँ नियमित अभिव्यक्तियाँ समस्या का एक प्रभावी, संक्षिप्त समाधान प्रदान करती हैं, वे कभी-कभी ऐसी स्थितियों में ढल जाती हैं, जहाँ कोड के बजाय एक आसान-से-पढ़ने योग्य, उपयोग योग्य अनुभाग का उपयोग करना बेहतर होता है।


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

1
यदि आप जानते हैं कि रेगेक्स कैसे काम करता है, तो यह कोई समस्या नहीं है।
शिप्पू मोकादिम

8
@ स्पेसर, यह धीमा पैटर्न नहीं है , यह धीमा इंजन है । अधिकांश (आधुनिक) नियमित अभिव्यक्ति इंजन जटिल पैटर्न (उदाहरण के लिए |या कई .*) के लिए अनुपयुक्त हैं , क्योंकि वे एक स्टैक मशीन और बैकट्रैकिंग का उपयोग करते हैं। यही कारण है कि आपको पर्ल, जावा, पायथन, रूबी में अपने नियमित अभिव्यक्तियों को ध्यान से देखना होगा। पुरानी शैली के नियमित अभिव्यक्ति इंजन ( grepउदाहरण के लिए) पहले पैटर्न को डीएफए के लिए संकलित करते हैं। बाद में, पैटर्न की जटिलता काफी हद तक अप्रासंगिक है। मैंने सिर्फ जावा और grep का उपयोग एक ही पाठ और पैटर्न के लिए किया: 22min बनाम 2 s। यहाँ विज्ञान है: swtch.com/~rsc/regexp/regexp1.html
hagello

122

रेगेक्स को बनाए रखना

पूर्व में "नियमित अभिव्यक्ति" के रूप में संदर्भित पैटर्न को ध्वस्त करने की दिशा में एक प्रमुख अग्रिम है पर्ल का /xरेग्ज फ्लैग - कभी-कभी (?x)जब एम्बेडेड लिखा जाता है - जो व्हाट्सएप (लाइन ब्रेकिंग, इंडेंटिंग) और टिप्पणियों की अनुमति देता है। यह गंभीरता से पठनीयता और इसलिए रखरखाव में सुधार करता है। सफेद स्थान संज्ञानात्मक चैंकिंग के लिए अनुमति देता है, इसलिए आप देख सकते हैं कि किस समूह के साथ क्या है।

आधुनिक पैटर्न भी अब अपेक्षाकृत गिने और नामित बैकरेफरेंस का समर्थन करते हैं। इसका मतलब है कि आपको अब कैप्चर समूहों की गणना करने की आवश्यकता नहीं है जो आपको चाहिए $4या \7। यह पैटर्न बनाते समय मदद करता है जिसे आगे के पैटर्न में शामिल किया जा सकता है।

यहाँ एक उदाहरण है एक अपेक्षाकृत संख्या में कब्जा समूह:

$ डुपोर्ट = qr {\ b (?: (\ w +)) (?: \ s + \ g {-1}) +) \ b} xi;
$ उद्धृत = qr {([""] $ डुपोर्ट \ 1} x;

और यहाँ नामित कब्जा के बेहतर दृष्टिकोण का एक उदाहरण है:

$dupword = qr{ \b (?: (?<word> \w+ ) (?: \s+ \k<word> )+ ) \b }xi;
$quoted  = qr{ (?<quote> ["'] ) $dupword  \g{quote} }x;

व्याकरणिक संदर्भ

सबसे अच्छा , इन नामित कैप्चर को एक (?(DEFINE)...)ब्लॉक के भीतर रखा जा सकता है , ताकि आप अपने पैटर्न के अलग-अलग नामित तत्वों के निष्पादन से घोषणा को अलग कर सकें। यह उन्हें पैटर्न के भीतर सबरूटीन की तरह कार्य करता है।
इस तरह के "व्याकरणिक रेगेक्स" का एक अच्छा उदाहरण इस उत्तर और इस एक में पाया जा सकता है । ये व्याकरण संबंधी घोषणा के समान हैं।

जैसा कि उत्तरार्द्ध आपको याद दिलाता है:

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

यह अधिक जोर नहीं दिया जा सकता है। बेशक अगर आप अपने पैटर्न में उन चीजों का उपयोग नहीं करते हैं, तो आप अक्सर दुःस्वप्न पैदा करेंगे। लेकिन अगर आप कर उन्हें इस्तेमाल, हालांकि, आप नहीं आवश्यकता नहीं है।

आधुनिक व्याकरणिक पैटर्न का एक और उदाहरण, RFC 5322 को पार्स करने के लिए यह एक है: 5.10.0 का उपयोग करें;

$rfc5322 = qr{

   (?(DEFINE)

     (?<address>         (?&mailbox) | (?&group))
     (?<mailbox>         (?&name_addr) | (?&addr_spec))
     (?<name_addr>       (?&display_name)? (?&angle_addr))
     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ; (?&CFWS)?)
     (?<display_name>    (?&phrase))
     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)

     (?<addr_spec>       (?&local_part) \@ (?&domain))
     (?<local_part>      (?&dot_atom) | (?&quoted_string))
     (?<domain>          (?&dot_atom) | (?&domain_literal))
     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? (?&dcontent))* (?&FWS)?
                                   \] (?&CFWS)?)
     (?<dcontent>        (?&dtext) | (?&quoted_pair))
     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])

     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)

     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
     (?<quoted_pair>     \\ (?&text))

     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
     (?<qcontent>        (?&qtext) | (?&quoted_pair))
     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)

     (?<word>            (?&atom) | (?&quoted_string))
     (?<phrase>          (?&word)+)

     # Folding white space
     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
     (?<CFWS>            (?: (?&FWS)? (?&comment))*
                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))

     # No whitespace control
     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])

     (?<ALPHA>           [A-Za-z])
     (?<DIGIT>           [0-9])
     (?<CRLF>            \x0d \x0a)
     (?<DQUOTE>          ")
     (?<WSP>             [\x20\x09])
   )

   (?&address)

}x;

यह उल्लेखनीय नहीं है - और शानदार? आप एक बीएनएफ-शैली व्याकरण ले सकते हैं और अपनी मौलिक संरचना को खोए बिना सीधे कोड में अनुवाद कर सकते हैं!

यदि आधुनिक व्याकरणिक पैटर्न अभी भी आपके लिए पर्याप्त नहीं हैं, तो डेमियन कॉनवे के शानदार Regexp::Grammarsमॉड्यूल बेहतर डीबगिंग के साथ एक समान क्लीनर सिंटैक्स भी प्रदान करता है। यहाँ RFC 5322 को उस मॉड्यूल से एक पैटर्न में पार्स करने के लिए समान कोड है:

#!/usr/bin/perl

use strict;
use warnings;
use 5.010;
use Data::Dumper "Dumper";

my $rfc5322 = do {
    use Regexp::Grammars;    # ...the magic is lexically scoped
    qr{

    # Keep the big stick handy, just in case...
    # <debug:on>

    # Match this...
    <address>

    # As defined by these...
    <token: address>         <mailbox> | <group>
    <token: mailbox>         <name_addr> | <addr_spec>
    <token: name_addr>       <display_name>? <angle_addr>
    <token: angle_addr>      <CFWS>? \< <addr_spec> \> <CFWS>?
    <token: group>           <display_name> : (?:<mailbox_list> | <CFWS>)? ; <CFWS>?
    <token: display_name>    <phrase>
    <token: mailbox_list>    <[mailbox]> ** (,)

    <token: addr_spec>       <local_part> \@ <domain>
    <token: local_part>      <dot_atom> | <quoted_string>
    <token: domain>          <dot_atom> | <domain_literal>
    <token: domain_literal>  <CFWS>? \[ (?: <FWS>? <[dcontent]>)* <FWS>?

    <token: dcontent>        <dtext> | <quoted_pair>
    <token: dtext>           <.NO_WS_CTL> | [\x21-\x5a\x5e-\x7e]

    <token: atext>           <.ALPHA> | <.DIGIT> | [!#\$%&'*+-/=?^_`{|}~]
    <token: atom>            <.CFWS>? <.atext>+ <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom_text>   <.atext>+ (?: \. <.atext>+)*

    <token: text>            [\x01-\x09\x0b\x0c\x0e-\x7f]
    <token: quoted_pair>     \\ <.text>

    <token: qtext>           <.NO_WS_CTL> | [\x21\x23-\x5b\x5d-\x7e]
    <token: qcontent>        <.qtext> | <.quoted_pair>
    <token: quoted_string>   <.CFWS>? <.DQUOTE> (?:<.FWS>? <.qcontent>)*
                             <.FWS>? <.DQUOTE> <.CFWS>?

    <token: word>            <.atom> | <.quoted_string>
    <token: phrase>          <.word>+

    # Folding white space
    <token: FWS>             (?: <.WSP>* <.CRLF>)? <.WSP>+
    <token: ctext>           <.NO_WS_CTL> | [\x21-\x27\x2a-\x5b\x5d-\x7e]
    <token: ccontent>        <.ctext> | <.quoted_pair> | <.comment>
    <token: comment>         \( (?: <.FWS>? <.ccontent>)* <.FWS>? \)
    <token: CFWS>            (?: <.FWS>? <.comment>)*
                             (?: (?:<.FWS>? <.comment>) | <.FWS>)

    # No whitespace control
    <token: NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f]

    <token: ALPHA>           [A-Za-z]
    <token: DIGIT>           [0-9]
    <token: CRLF>            \x0d \x0a
    <token: DQUOTE>          "
    <token: WSP>             [\x20\x09]

    }x;

};


while (my $input = <>) {
    if ($input =~ $rfc5322) {
        say Dumper \%/;       # ...the parse tree of any successful match
                              # appears in this punctuation variable
    }
}

वहाँ में अच्छी चीजें की एक बहुत कुछ है perlre मैनपेज , लेकिन मौलिक regex डिजाइन सुविधाओं में इन नाटकीय सुधार किसी भी तरह अकेले पर्ल तक ही सीमित द्वारा कर रहे हैं। वास्तव में pcrepattern मैनपेज एक आसान पढ़ा जा सकता है, और एक ही क्षेत्र को कवर करता है।

आधुनिक पैटर्न में लगभग कुछ भी सामान्य नहीं है जो आपको अपने परिमित ऑटोमेटा वर्ग में सिखाया गया था।


9
हाँ! हाँ! अंत में, कोई व्यक्ति एक महान उदाहरण दिखाता है कि एक्स मॉडिफ़ायर के साथ रीडगेबल कैसे हो सकता है। मैं विश्वास नहीं कर सकता कि कितने लोग जानते हैं कि यह मौजूद है, अकेले वास्तव में इसका उपयोग करते हैं।
जर्बरीद

1
@ शब्बीरदेवी: यह सिर्फ नहीं है /x। यह (?&name)आंतरिक रेगेक्स सबरूटीन्स के साथ, व्याकरणिक रूप से रेगीज़ का उपयोग कर रहा है , जो वास्तव में इस चमक को बनाता है।
20

+1 आप हमेशा कुछ नया सीखते हैं। मुझे नहीं पता था कि PCRE को परिभाषित करने के लिए "झूठी" स्थिति थी।
NikiC

5
अजगर के पास एक re.VERBOSEझंडा है।
मैकेनिकल घोंघा

3
बस गुनना आगे बढ़ता है और कहता है कि मैं अभी भी लंबाई पर चकित हूं कि लोग रेगेक्स को उपयोग करने योग्य बनाने के लिए जाएंगे।
स्लेटर विक्टरोफ़

68

रेगेक्स एक महान उपकरण है, लेकिन लोगों को लगता है कि "हे, क्या एक महान उपकरण है, मैं इसे एक्स करने के लिए उपयोग करूंगा!" जहां X एक ऐसी चीज है, जिसके लिए एक अलग उपकरण (आमतौर पर एक पार्सर) बेहतर होता है। यह एक हथौड़ा का उपयोग करने वाला मानक है जहां आपको एक पेचकश समस्या की आवश्यकता होती है।


4
बस याद रखें कि अधिकांश पार्स -सेक्सुअल एनालाइज़र- फिर भी अपने सामान को पार्स करने के लिए नियमित अभिव्यक्ति का उपयोग करते हैं :-)
जैस्पर बेकर्स

62
यह कहना कि पार्सर नियमित अभिव्यक्ति का उपयोग करते हैं, यह कहना है कि पार्सर असाइनमेंट स्टेटमेंट का उपयोग करते हैं। इसका मतलब कुछ भी नहीं है जब तक आप यह नहीं देखते हैं कि उनका उपयोग कैसे किया जा रहा है।
चास।

24
जब एक पार्सर बेहतर होता है तो रेजेक्स का उपयोग करना कष्टप्रद होता है। एक RegEx का उपयोग करना जब भाषा के मानक स्ट्रिंग पाते हैं या कार्य को प्रतिस्थापित करते हैं (और रैखिक समय में आमतौर पर) काम करेंगे बस अक्षम्य है।
21

1
सहमत, क्योंकि एक RegEx को सभी ट्रेडों का एक जैक होना चाहिए जो ओवरहेड प्रसंस्करण कर रहा है वह बहुत बड़ा है। सिर्फ इसलिए कि एक RegEx इंजन का उपयोग करना आसान लगता है इसका मतलब यह नहीं है कि यह एक पुनरावृत्त पार्सर (डेवलपर निर्भर सीमा) पर एक बेहतर समाधान है। मेरे पसंदीदा उदाहरणों में से एक PHP के split($pattern,$string)बनाम explode($delimiter,$string)- शुक्र है कि पूर्व को ह्रास हो रहा है, लेकिन बहुत सारे कोड ने पूर्व का उपयोग किया जब उन्हें केवल बाद की शक्ति की आवश्यकता थी। Aggreed, RegEx कुछ काम करने के लिए एक आसान उपकरण प्रदान करता है, लेकिन जब तक आपको नियमित अभिव्यक्ति की पूरी शक्ति की आवश्यकता नहीं होती है, तब तक
रुडू

4
लेक्सिकल एनालाइजर वास्तव में रेग्जेस का उपयोग कर सकते हैं। उन्हें टोकेनाइज़र के रूप में भी जाना जाता है, लेकिन वे सिंटैक्टिक एनालाइज़र (या पार्सर) नहीं हैं। एक जटिल पर्याप्त स्ट्रिंग को पढ़ने के लिए, टोकन को टोकन के रूप में पढ़ने के लिए एक टोकनर का उपयोग किया जाना चाहिए (शायद टोकन के आधार पर, रेगेक्स के साथ, शायद नहीं। इन टोकन को तब पार्सर को पास किया जाना चाहिए, जो उन्हें व्याकरण के नियमों के साथ संसाधित करेगा, जो निश्चित रूप से रेगेक्स नहीं हैं।
एक्सल

53

लगभग हर कोई जानता है जो नियमित रूप से नियमित रूप से अभिव्यक्ति का उपयोग करता है (इरादा इरादा) एक यूनिक्स-ईश पृष्ठभूमि से आता है जहां वे ऐसे टूल का उपयोग करते हैं जो आरईएस को प्रथम श्रेणी के प्रोग्रामिंग कंस्ट्रक्शन के रूप में मानते हैं, जैसे कि जीआरपी, सेड, ऑक और पर्ल। चूंकि नियमित अभिव्यक्ति का उपयोग करने के लिए लगभग कोई सिंटैक्टिक ओवरहेड नहीं है, इसलिए जब वे करते हैं तो उनकी उत्पादकता बढ़ जाती है।

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


11
हाँ, मैंने लाइब्रेरी का उपयोग करके रेगेक्स सिंटैक्स क्रिया को बनाने के लिए पायथन को कभी नहीं माफ़ किया। मुझे लगता है कि यह पवित्रता से अधिक पवित्रता है।
slikts

7
मैं एक यूनिक्स बैकग्राउंड से आया हूं, जिसमें sed, awk & perl भार का उपयोग किया गया है, और निश्चित रूप से बहुत कुछ किया है, लेकिन यह जानते हैं कि जब मैं एक regex का उपयोग करता हूं, तो यह केवल लिखने के लिए हैक है जिसे मैं बनाए रखना पसंद करूंगा। यह शेल स्क्रिप्ट / वन-टाइमर्स के लिए अच्छा है, लेकिन असली काम के लिए, किसी भी चीज़ के लिए जो केवल कुछ डेटा-टू-सेव-सेव नहीं है, मैं अब स्पष्ट सिंटैक्स के साथ एक उचित टोकन / लेक्सर / पार्सर का उपयोग करता हूं। मेरा पसंदीदा सभी / कोई भी, सफाई से + स्व-अनुकूलन कर सकता है। मैंने कठिन तरीका सीखा है, और कई वर्षों से, कि शुरुआत में थोड़ा आत्म-अनुशासन का मतलब बाद में कम प्रयास है। एक regex कीबोर्ड पर एक पल है, और एक जीवन भर के लिए।
एंड्रयूज सेप

44

नियमित अभिव्यक्तियाँ आपको इनपुट के एक स्ट्रिंग को संसाधित करने के लिए एक कस्टम परिमित-राज्य मशीन (FSM) को एक कॉम्पैक्ट तरीके से लिखने की अनुमति देती हैं। नियमित अभिव्यक्ति का उपयोग करना कठिन होने के कम से कम दो कारण हैं:

  • पुराने स्कूल के सॉफ्टवेयर विकास में बहुत सारी योजनाएं, पेपर मॉडल, और सावधान विचार शामिल हैं। नियमित अभिव्यक्ति इस मॉडल में बहुत अच्छी तरह से फिट होती है, क्योंकि एक प्रभावी अभिव्यक्ति को ठीक से लिखने के लिए इसमें बहुत कुछ घूरना शामिल है, एफएसएम के रास्तों को देखते हुए।

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

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

    यह पढ़ने के लिए कठिन हो रही नियमित अभिव्यक्ति के बिंदु पर जाता है। बस एक नियमित अभिव्यक्ति को देखकर, सभी संभावित आदानों की कल्पना करने में बहुत अधिक एकाग्रता लगती है जिसे अस्वीकार कर दिया जाना चाहिए, लेकिन गलती से स्वीकार किए जाते हैं। कभी किसी और के नियमित अभिव्यक्ति कोड को डीबग करने का प्रयास करें ?

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


4
वहाँ regexps डिबग करने के लिए उत्कृष्ट उपकरण हैं: regexbuddy.com
जैस्पर

15
perl -Mre = debug -e "q [aabbcc] = ~ / ab * [cd] /"
ब्रैड गिल्बर्ट

15
मुझे नहीं लगता कि मैं कभी भी फ्लाइंग स्पेगेटी मॉन्स्टर के बारे में सोचे बिना "एफएसएम" का परिचय देख सकता हूं।
जर्बरीद

4
@ शब्बीरदारी: मेरा मतलब अपमान करना नहीं है। यदि आप चाहें, तो आप नियतात्मक परिमित ऑटोमोटन (डीएफए) का उपयोग कर सकते हैं।
बिल कार्विन

37

लोगों को लगता है कि नियमित अभिव्यक्ति कठिन है; लेकिन ऐसा इसलिए है क्योंकि वे उन्हें गलत उपयोग कर रहे हैं। किसी भी टिप्पणी के बिना जटिल वन-लाइनर्स लिखना, इंडेंट करना या नामांकित करना। (आप अपनी जटिल एसक्यूएल अभिव्यक्ति को एक पंक्ति में, टिप्पणियों, इंडेंटिंग या उपनाम के बिना नहीं करते हैं, क्या आप?)। तो हाँ, बहुत से लोगों के लिए, वे समझ में नहीं आता है।

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


2
खैर .. अंतर यह है कि कई रिक्त स्थान regex में अर्थ रखते हैं, जहां अन्य भाषाओं में वे नहीं करते हैं और यही कारण है कि वे आम तौर पर एक लाइनर होते हैं (जो कभी-कभी कई लाइनों में लपेटते हैं :)
राडो

14
@ राडो: पर्ल, उदाहरण के लिए, रेगीक्स के लिए xसंशोधक है जिसके कारण व्हॉट्सएप को अनदेखा किया जाता है। यह आपको रेगेक्स को कुछ लाइनों पर रखने और टिप्पणियों को जोड़ने की अनुमति देता है।
नाथन फेलमैन

9
इसी तरह पाइथन re.Xउर्फ है re.VERBOSE
क्रेग मैकक्यून

2
इसी तरह xtcl में संशोधक करें। मेरा मानना ​​है कि यह अन्य भाषाओं के विपरीत, tcl के बाद से काफी मानक है, PCRE का उपयोग नहीं करता है।
स्लीवेटमैन

2
@AndrewC यह इस पोस्ट को प्राप्त कर सकता है कि सबसे बड़ी गलत व्याख्याओं में से एक है।
जैस्पर बेकर्स

28

क्योंकि उनके पास आमतौर पर स्वीकृत आईडीई में सबसे लोकप्रिय शिक्षण उपकरण का अभाव है: कोई रेगेक्स विज़ार्ड नहीं है। स्वतः पूर्णता भी नहीं। आपको पूरी चीज़ को अपने आप से कोड करना होगा।


3
फिर आप गलत आईडीई का उपयोग कर रहे हैं ... यहां तक ​​कि मेरे पाठ संपादक regex संकेत प्रदान करता है।
कर्टनडॉग

1
एक साइड नोट पर, एक्सप्रेसो और द रेगेक्स कोच नियमित अभिव्यक्ति के निर्माण के लिए बहुत उपयोगी उपकरण हैं।
मुन

22
कैसे दुनिया में आप एक नियमित अभिव्यक्ति को स्वत: पूर्ण करेंगे?
एम्ब्रोसैचपेल

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

2
@AmbroseChapel - मुझे इस चर्चा में आने में कुछ साल हैं। लेकिन मैंने regexhero.net/tester में एक स्वत: पूर्णता तंत्र बनाया, यह गोल (), चौकोर []या घुंघराले {}कोष्ठकों के अंदर के सामान्य निर्माणों द्वारा शुरू किया गया है । यह भी बैकस्लैश का काम करेगा।
स्टीव वॉर्थम

17

" रेग्युलर एक्सप्रेशंस: नाउ यू हैव टू प्रॉब्लम्स " इस मामले पर जेफ एटवुड का एक शानदार लेख है। असल में, नियमित अभिव्यक्ति "कठिन" हैं! वे नई समस्याएं खड़ी कर सकते हैं। हालांकि, वे प्रभावी हैं।


16

मुझे नहीं लगता कि वे विवादास्पद हैं।

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

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

http://docs.python.org/howto/regex

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


2
यह पृष्ठ docs.python.org/howto/regex
Dominic K

@ मद्धम धन्यवाद। मैं अपना उत्तर प्रतिबिंबित करने के लिए संपादित करूँगा।
allyourcode

11

नियमित अभिव्यक्तियाँ हैं कि अंकगणितीय संचालकों की संख्या क्या है, और मैं उन्हें विवादास्पद नहीं मानता। मुझे लगता है कि खुद की तरह एक काफी मिलिटेंट OO एक्टिविस्ट (जो स्ट्रिंग्स के ऊपर अन्य वस्तुओं का चयन करना चाहते हैं) को अस्वीकार करना मुश्किल होगा।


7

समस्या यह है कि regexes संभावित रूप से इतने शक्तिशाली होते हैं कि आप उनके साथ ऐसी चीजें कर सकते हैं जिनके लिए आपको कुछ अलग उपयोग करना चाहिए।

एक अच्छे प्रोग्रामर को पता होना चाहिए कि उनका उपयोग कहां करना है, और कहां नहीं। सामान्य उदाहरण गैर-नियमित भाषाओं को पार्स कर रहा है (देखें कि कोई भाषा नियमित है या नहीं )।

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


5

आप लगभग यह भी पूछ सकते हैं कि गोटो विवादास्पद क्यों हैं।

असल में, जब आपको इतनी "स्पष्ट" शक्ति मिलती है, तो लोग उन स्थितियों के लिए उनका दुरुपयोग करने के लिए उपयुक्त होते हैं, जिनके लिए वे सबसे अच्छा विकल्प नहीं हैं। उदाहरण के लिए, CSVs या XML या HTML को regexes में पार्स करने के लिए कहने वाले लोगों की संख्या, मुझे चकित करती है। यह काम का गलत साधन है। लेकिन कुछ उपयोगकर्ता वैसे भी regexes का उपयोग करने पर जोर देते हैं।

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

ध्यान दें कि regexes का उपयोग अभी भी CSV, XML, HTML, आदि को पार्स करने के लिए किया जा सकता है, लेकिन आमतौर पर एक भी regex में नहीं।


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

4

मुझे नहीं लगता कि "विवादास्पद" सही शब्द है।

लेकिन मैंने ऐसे कई उदाहरण देखे हैं जहाँ लोग कहते हैं कि "मुझे इस तरह की स्ट्रिंग में हेरफेर करने के लिए नियमित अभिव्यक्ति की क्या आवश्यकता है?" जो XY समस्याएं हैं।

दूसरे शब्दों में, वे इस धारणा से शुरू हुए हैं कि एक रेग्क्स वह है जिसकी उन्हें आवश्यकता है, लेकिन वे एक विभाजन () के साथ बेहतर होगा, पर्ल का tr /// जैसा अनुवाद जहां वर्ण एक दूसरे के लिए प्रतिस्थापित किए जाते हैं, या सिर्फ एक सूचकांक ()।


4

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

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

इसके अलावा ऐसे कई कारण हैं जिनके कारण regexps की गलत आलोचना की जाती है, उदाहरण के लिए

  • regexp कुशल नहीं है, क्योंकि शीर्ष एक का निर्माण स्पष्ट नहीं है
  • कुछ प्रोग्रामर "भूल" को केवल एक बार रेकजैप का संकलन करने के लिए कई बार इस्तेमाल किया जा सकता है (जैसे जावा में एक स्थिर पैटर्न)
  • कुछ प्रोग्रामर ट्रायल और एरर स्ट्रेटेजी के लिए जाते हैं - रीजैक्स के साथ भी कम काम करता है!

4

मुझे लगता है कि रेगेक्स सीखना है और रेपेक्स को बनाए रखना अलोकप्रिय है, अधिकांश डेवलपर्स आलसी हैं या उनमें से ज्यादातर बाहरी पुस्तकालयों पर भरोसा करते हैं ताकि उनके लिए पार्सिंग काम किया जा सके ... वे उत्तर के लिए Google पर भरोसा करते हैं और यहां तक ​​कि मंचों के लिए भी पूछते हैं उनकी समस्या के लिए पूरा कोड। लेकिन जब रेगेक्स को लागू करने या संशोधित करने / बनाए रखने की बात आती है तो वे बस विफल हो जाते हैं।

एक लोकप्रिय कहावत है "फ्रेंड्स नॉट फ्रेंड्स फ्रेंड्स रेगेक्स फॉर पार्सिंग HTML"

लेकिन जहाँ तक मेरा सवाल है मैंने Regex का उपयोग करके पूर्ण HTML पार्सर बना लिए हैं और मुझे लगता है कि Regex HTML तार को गति-वार और मेमोरी-वार दोनों में बेहतर कर रहा है (यदि आपके पास एक आइडिया है जो आपको प्राप्त करना है :))


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

आप HTML में किनारे के मामलों को याद करेंगे क्योंकि HTML एक नियमित भाषा नहीं है। आप सुरक्षित हैं यदि आपका इरादा एचटीएमएल के एक ज्ञात सबसेट को
समेटना है

2

नियमित अभिव्यक्ति बहुत सारे लोगों के लिए एक गंभीर रहस्य है, जिसमें मैं भी शामिल हूं। यह बहुत अच्छा काम करता है लेकिन यह एक गणित समीकरण को देखने जैसा है। मुझे यह बताते हुए खुशी हो रही है कि किसी ने अंततः http://regexlib.com/ पर विभिन्न नियमित अभिव्यक्ति कार्यों का एक समेकित स्थान बनाया है । अब यदि Microsoft केवल एक नियमित अभिव्यक्ति वर्ग बनाएगा जो स्वचालित रूप से सामान्य सामग्री जैसे पत्र को समाप्त करने, या दिनांक को फ़िल्टर करने में बहुत कुछ करेगा।


2
आप बात याद कर रहे हैं। Regexes का विचार यह है कि आप उन्हें सीखने में कुछ समय का निवेश करते हैं और जब आप कर रहे होते हैं, तो आपको कुछ जादुई "डेट पढ़ने" की आवश्यकता नहीं होती है। इसके बजाय, यह उनके लिए बहुत कम प्रयास करता है। इसके अलावा, इसे "yyyy / mm / dd" के लिए लिखने के लिए बस इतना ही प्रयास करना होगा जितना कि "mm-dd-yyyy" के लिए एक लिखने के लिए, या "mm-yyyy / dd" के लिए भी ऐसा करना चाहिए (जो जीता 'अक्सर ऐसा नहीं होता है, लेकिन यह एक उदाहरण है कि आप ऐसी चीजें कैसे कर सकते हैं जो एक जादुई वर्ग कभी नहीं कर सकता ")।
जैस्पर

1

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

यदि आप दीवार में एक कील लगाना चाहते हैं, तो एक हथौड़ा का उपयोग न करें। हां, यह काम करेगा, लेकिन जब तक आप हथौड़ा नहीं लेंगे, तब तक मैं दीवार में 20 ढेर लगा सकता हूं।

नियमित अभिव्यक्तियों का उपयोग उनके लिए किया जाना चाहिए जो उनके लिए डिज़ाइन किए गए थे, और कुछ भी कम नहीं।


0

जबकि मुझे लगता है कि regexes एक आवश्यक उपकरण है, उनके बारे में सबसे कष्टप्रद बात यह है कि अलग-अलग कार्यान्वयन हैं। वाक्यविन्यास, संशोधक में मामूली अंतर, और अक्सर-"लालच" चीजों को वास्तव में अराजक बना सकता है, परीक्षण-और-त्रुटि की आवश्यकता होती है और कभी-कभी puzzling बग उत्पन्न करते हैं।


रेगेक्स कार्यान्वयन कैसे अधिकतम मिलान के लिए उनके दृष्टिकोण में भिन्न होता है, वह चीज जो मुझे लगता है कि आप "लालच" कह रहे हैं? क्या आपका मतलब है वाम-सबसे लंबे बनाम सबसे लंबे-वाम- शब्दार्थ के बीच का अंतर ? यही एकमात्र अंतर है जिससे मैं अवगत हूं; यानी, चाहे लालच उत्सुकता को छेड़े या इसके विपरीत
tchrist

0

कुछ मामलों में मुझे लगता है कि आप उनका उपयोग करना चाहते हैं। उदाहरण के लिए एक लेक्सर बनाने के लिए।

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


0

मुझे लगता है कि यह प्रोग्रामर्स के बीच कम ज्ञात तकनीक है। तो, इसके लिए व्यापक स्वीकृति नहीं है। और अगर आपके पास अपने कोड की समीक्षा करने या अपने काम की समीक्षा करने के लिए एक गैर-तकनीकी प्रबंधक है तो एक नियमित अभिव्यक्ति बहुत खराब है। आप एक सही नियमित अभिव्यक्ति लिखने में घंटे बिताएंगे, और आपको यह सोचकर मॉड्यूल के लिए कुछ अंक मिलेंगे कि उसने कोड की कुछ पंक्तियाँ लिखी हैं। साथ ही, जैसा कि अन्यत्र कहा गया है, नियमित अभिव्यक्ति पढ़ना बहुत मुश्किल काम है।


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

मुझे लगता है कि आपके प्रबंधक को यह नहीं पता है कि "प्रोग्रामिंग का वास्तविक नायक वह है जो नकारात्मक कोड लिखता है।"
राजीव

यदि आपका प्रबंधक आपको कोड के 3 लाइनों (regexps सहित) के साथ काम पूरा करने के लिए डिंग करने जा रहा है, तो कुछ डूफस सहकर्मी की प्रशंसा करते हुए, जिन्होंने इसे असेंबलर की 900 लाइनों में किया था ... मैं एक नई नौकरी खोजने का सुझाव देता हूं।
फिल पेरी

0

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


-4

रेगेक्स के लिए सबसे अच्छा वैध और सामान्य उपयोग ईमेल पता प्रारूप सत्यापन के लिए है।

वह इसका एक अच्छा अनुप्रयोग है।

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

अच्छी तरह से लिखा नियमित अभिव्यक्ति बहुत धीमी नहीं होनी चाहिए। आमतौर पर विकल्प, जैसे टन को प्रतिस्थापित करने के लिए बहुत धीमे विकल्प हैं। साथ ही एक पास में कर सकते हैं।

कई स्थितियां बिल्कुल नियमित अभिव्यक्ति के लिए बुलाती हैं और कुछ नहीं।

अहानिकर पात्रों के साथ विशेष गैर-मुद्रण वर्णों को प्रतिस्थापित करना एक और अच्छा उपयोग है।

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


10
अनुभव से पता चलता है कि regexes वास्तव में ईमेल पता प्रारूप सत्यापन के लिए एक बहुत खराब उपकरण हैं। एक रेगेक्स के रूप में लागू किया गया एक सही रूप से पूर्ण प्रारूप सत्यापनकर्ता एक बहु-सौ-वर्ण की संकीर्णता है, जबकि अधिकांश छोटे "अच्छे पर्याप्त" सत्यापनकर्ता हैं जो अधिकांश लोगों को बनाने में 5 मिनट लगते हैं, जो मान्य, वितरण योग्य पते की बड़ी श्रेणियों को अस्वीकार कर देंगे।
डेव शेरोमैन

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

2
मैंने ईमेल का पता खोजने के लिए \ w @ \ w +। \ W जैसे कुछ का उपयोग किया है, फाइलों की एक विशाल निर्देशिका में तेज़ी से ईमेल पता लगाने के लिए जहां गति महत्वपूर्ण थी और कुछ झूठी सकारात्मक या गलत नकारात्मक महत्वपूर्ण नहीं थी। लेकिन एक ईमेल पते को मान्य करने का सबसे अच्छा तरीका यह है कि इसे ईमेल भेजें।
रोसफैब्रेंट

हाँ ईमेल पते कल्पना एक बुरा गड़बड़ है stackoverflow.com/questions/611775/...
निक वान खामियाजा

@ निक, @Dave: मेल पते के सत्यापन के लिए एक गंदा गड़बड़ नहीं होना चाहिए।
tchrist
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.