मुफ़्त रेगेक्स चीट शीट

पैटर्न भाषा का संक्षिप्त इतिहास

रेगुलर एक्सप्रेशन सैद्धांतिक कंप्यूटर विज्ञान के एक टुकड़े के रूप में शुरू हुए। Stephen Kleene ने 1956 के एक न्यूरल नेटवर्क पेपर में «नियमित सेट» परिभाषित किए; Ken Thompson ने 1968 में grep के साथ इन्हें Unix में डाला। Henry Spencer की ओपन-सोर्स regex लाइब्रेरी (1980 के दशक का मध्य) कई बाद के क्रियान्वयनों का आधार बनी। Larry Wall ने Perl में सिंटैक्स को नाटकीय रूप से बढ़ाया, और उनके «Perl-compatible regular expressions» (PCRE) उस वास्तविक मानक बने जिसका अधिकांश आधुनिक भाषाओं ने अनुसरण किया। आज कई निकट संबंधित पर सूक्ष्म रूप से भिन्न regex स्वाद हैं, और एक इंजन में काम करने वाला पैटर्न दूसरे इंजन में हमेशा एक जैसा काम नहीं करता।

वह इंजन जिसमें आपका पैटर्न रहता है

एक ही सिंटैक्स का अलग-अलग इंजनों में अलग अर्थ हो सकता है। बड़े परिवार:

• POSIX BRE (Basic Regular Expressions), grep के डिफ़ॉल्ट मोड और sed द्वारा उपयोग किया जाता है। कई metacharacters को बैकस्लैश एस्केपिंग की आवश्यकता होती है: (, ), {, }, +, ?, | एस्केप न होने पर literal हैं।
• POSIX ERE (Extended Regular Expressions), egrep, awk द्वारा उपयोग किया जाता है। उपरोक्त metacharacters एस्केपिंग के बिना काम करते हैं।
• PCRE (Perl-Compatible Regular Expressions), ERE को lookarounds, atomic groups, named captures और backreferences के साथ बढ़ाता है। PHP और अधिकांश आधुनिक भाषाओं द्वारा उपयोग किया जाता है। Perl-व्युत्पन्न शॉर्टहैंड क्लास \d / \w / \s PCRE, JavaScript, .NET, Java और Python के लिए सामान्य हैं।
• JavaScript RegExp, PCRE के क़रीब पर उल्लेखनीय अंतरों के साथ। ES2018 ने lookbehinds, named capture groups, s dotall flag, और u flag के माध्यम से Unicode property escapes जोड़े। सेट नोटेशन के लिए v flag ES2024 में आया।
• Python re और Python regex, re मानक लाइब्रेरी में है; तृतीय-पक्ष regex मॉड्यूल Unicode-aware फ़ीचर, चर-चौड़ाई lookbehinds और अन्य PCRE-शैली संवर्धन जोड़ता है।
• RE2 (Google की लाइब्रेरी, Go में उपयोग), रैखिक समय की गारंटी देती है पर backreferences या lookarounds का समर्थन नहीं करती। समझौता: पूर्वानुमेय प्रदर्शन, कम सुविधाएँ।

इस चीटशीट का इंटरैक्टिव टेस्टर JavaScript में चलता है, इसलिए पैटर्न का मूल्यांकन ब्राउज़र के JS इंजन द्वारा होता है। यहाँ काम करने वाले पैटर्न Python या PHP में अलग व्यवहार कर सकते हैं। अधिकांश अंतर बुनियादी सिंटैक्स के बजाय उन्नत सुविधाओं (lookbehinds, Unicode property escapes, backreferences) में हैं।

मूल निर्माण ब्लॉक

लगभग हर regex पैटर्न इन तत्वों से बनता है:

• लिटरल, स्वयं से मेल खाते हैं। cat «cat» सबस्ट्रिंग से मेल खाता है।
• एंकर, ^ (स्ट्रिंग/लाइन की शुरुआत), $ (अंत), \b (शब्द सीमा), \B (ग़ैर-शब्द-सीमा)।
• वर्ण क्लास, [abc] a, b या c से मेल खाता है। [^abc] नकारता है। [a-z] एक रेंज है। शॉर्टहैंड: \d (अंक), \w (शब्द वर्ण: अक्षर, अंक, अंडरस्कोर), \s (व्हाइटस्पेस), और नकार के लिए बड़े अक्षर वाले संस्करण (\D, \W, \S)।
• क्वांटिफ़ायर, ? (0 या 1), * (0 या अधिक), + (1 या अधिक), {n}, {n,}, {n,m}। डिफ़ॉल्ट रूप से लालची (जितना संभव हो उतना मेल खाएँ); आलसी के लिए ? जोड़ें: *?, +?, ??।
• समूह, (...) कैप्चर करने वाला, (?:...) ग़ैर-कैप्चर करने वाला, (?<name>...) नामित (PCRE / JS / Python)।
• विकल्पन, cat|dog किसी एक से मेल खाता है।
• Lookarounds, (?=...) सकारात्मक lookahead, (?!...) नकारात्मक lookahead, (?<=...) सकारात्मक lookbehind, (?<!...) नकारात्मक lookbehind। उपभोग किए बिना मेल खाते हैं।
• Backreferences, \1, \2 (क्रमांकित), \k<name> (नामित)। उसी पाठ से मेल खाते हैं जिससे संगत कैप्चर मिला।
• Flags, g (global), i (case-insensitive), m (multiline: ^ और $ लाइन सीमाओं से मेल खाते हैं), s (dotall: . newline से भी मेल खाता है), u (Unicode), y (JS में sticky)।

याद रखने योग्य पैटर्न

मुट्ठी भर पैटर्न इतनी बार आते हैं कि उन्हें दिमाग़ में रखना सार्थक है:

ईमेल regex पर एक नोट: पूर्ण RFC 5322 ईमेल सत्यापन के लिए 6,000-वर्ण की दैत्य regex चाहिए। ऊपर का सरल रूप 99% वास्तविक ईमेल पते स्वीकार करता है और किसी वैध को अस्वीकार नहीं करता; प्रोडक्शन उपयोग के लिए सिंटैक्स को पूरी तरह सत्यापित करने का प्रयास करने के बजाय एक पुष्टिकरण ईमेल भेजें।

लालची vs आलसी: एक सामान्य आश्चर्य

डिफ़ॉल्ट रूप से, क्वांटिफ़ायर लालची होते हैं: वे जितना हो सके उतना मेल खाते हैं जबकि समग्र पैटर्न को मेल खाने की अनुमति देते हैं। तो <.+> <a>text</a> के विरुद्ध पूरी चीज़ मेल खाता है, केवल <a> नहीं, क्योंकि .+ जितना ले सकता है उतना लेता है। सबसे छोटी संभव स्ट्रिंग से मेल खाने के लिए, क्वांटिफ़ायर के बाद ? जोड़ें: <.+?> पहले <a> और फिर अलग से </a> से मेल खाता है। लालची/आलसी का चुनाव «मेरी regex वह क्यों मेल नहीं खा रही जो मैंने अपेक्षा की थी» बग के सबसे आम स्रोतों में से एक है।

विनाशकारी बैकट्रैकिंग और ReDoS

कुछ regex पैटर्न कुछ इनपुट पर विफल होने में घातांकीय समय ले सकते हैं, ReDoS (Regular Expression Denial of Service) नामक डिनायल-ऑफ़-सर्विस भेद्यता का एक वर्ग। शास्त्रीय अपराधी हैं नेस्टेड क्वांटिफ़ायर जैसे (a+)+ या (a|aa)+ जो as की लंबी स्ट्रिंग पर लागू होते हैं उसके बाद एक ग़ैर-मेल वर्ण। इंजन हार मानने से पहले स्ट्रिंग को विभाजित करने का हर संभव तरीक़ा आज़माता है, और तरीक़ों की संख्या घातांकीय है।

वास्तविक घटनाएँ: Cloudflare का 2019 का आउटेज WAF नियम में तैनात एक regex द्वारा ट्रिगर हुआ जो कुछ इनपुट पर विनाशकारी रूप से बैकट्रैक हुआ। Stack Overflow को जुलाई 2016 में एक समान घटना हुई: एक post-trim regex (^[\s‌]+|[\s‌]+$) लगभग 20,000 लगातार whitespace वर्णों वाले एक टिप्पणी पर घातांकीय बैकट्रैकिंग से टकराई और साइट को 34 मिनट के लिए बंद कर दिया। रक्षात्मक आदतें: नेस्टेड क्वांटिफ़ायर से बचें, समर्थित जगहों पर atomic groups ((?>...)) को प्राथमिकता दें, और अविश्वसनीय इनपुट के लिए RE2 / रैखिक-समय इंजन उपयोग करने पर विचार करें।

जानने योग्य प्रति-भाषा विशेषताएँ

• JavaScript: स्ट्रिंग लिटरल में बैकस्लैश को डबल-एस्केप की ज़रूरत होती है ("\\d") पर regex लिटरल में नहीं (/\d/)। जब संभव हो regex लिटरल फ़ॉर्म का उपयोग करें।
• Python: बैकस्लैश समस्याओं से बचने के लिए कच्चे स्ट्रिंग्स (r"\d+") का उपयोग करें। re मॉड्यूल मानक लाइब्रेरी में है; PyPI पर regex अतिरिक्त सुविधाएँ जोड़ता है।
• Java: बैकस्लैश को quadruple-एस्केपिंग की ज़रूरत होती है ("\\\\d" \d के लिए) क्योंकि Java स्ट्रिंग लिटरल \ को एस्केप के रूप में उपयोग करते हैं और regex कंपाइलर फिर \\d देखता है।
• Bash: [[ string =~ pattern ]] में regex मैचिंग POSIX ERE का उपयोग करती है। उद्धरण नियम मुश्किल हैं; man bash देखें।
• Go: RE2 का उपयोग करता है, इसलिए backreferences और lookarounds उपलब्ध नहीं हैं। समझौता: रैखिक-समय गारंटी।

regex का उपयोग कब न करें

Jamie Zawinski की प्रसिद्ध 1997 पंक्ति: «Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems.»

• HTML / XML को regex से न पार्स करें। असली पार्सर का उपयोग करें (ब्राउज़र में DOMParser, Python में BeautifulSoup, Java में jsoup, आदि)। HTML की नेस्टेड संरचना मूलभूत रूप से उससे आगे है जो regex साफ़-साफ़ अभिव्यक्त कर सकती है।
• JSON को regex से न पार्स करें। JSON.parse / मानक लाइब्रेरी JSON पार्सर का उपयोग करें।
• regex से ईमेल को सख़्ती से सत्यापित न करें। एक पुष्टिकरण ईमेल भेजें; यही एकमात्र विश्वसनीय परीक्षण है।
• regex के रूप में CSV पार्सर न लिखें। embedded कॉमा वाले उद्धृत फ़ील्ड, escaped उद्धरण और बहु-पंक्ति मान जल्दी ही उससे आगे बढ़ जाते हैं जो regex साफ़-साफ़ संभालती है।
• संतुलित कोष्ठकों से मेल खाने का प्रयास न करें। मानक regex नहीं कर सकती (यह एक context-free भाषा है); कुछ PCRE इंजनों में पुनरावर्तन सुविधाएँ हैं जो धोखा देती हैं, पर एक असली पार्सर साफ़ है।

सामान्य ग़लतियाँ

1. विशेष वर्णों को एस्केप करना भूल जाना। ., *, ?, +, (, ), [, ], {, }, \, ^, $, |, / सभी के विशेष अर्थ हैं। उन्हें literal रूप से मेल खाने के लिए, बैकस्लैश के साथ उपसर्ग करें।
2. लालची क्वांटिफ़ायर बहुत अधिक खा रहे हैं। जब आप सबसे छोटी संभव मेल चाहते हैं, तो आलसी मेल खाने के लिए ? जोड़ें।
3. global flag भूल जाना और सोचना कि केवल पहला मेल क्यों दिखता है। JavaScript का String.prototype.match() g flag के बिना केवल पहला मेल लौटाता है।
4. लंबे इनपुट पर विनाशकारी बैकट्रैकिंग। (a+)+ जैसे नेस्टेड क्वांटिफ़ायर कुछ इनपुट पर लटक सकते हैं। edge cases के साथ परीक्षण करें।
5. यह मानना कि एक ही regex हर भाषा में समान व्यवहार करती है। Lookbehinds, Unicode escapes, और character class shortcut सभी भिन्न होते हैं।
6. ईमेल को बहुत सख़्ती से सत्यापित करने का प्रयास। तकनीकी रूप से सही RFC 5322 regex unmaintainable है; एक सरल regex प्लस साइनअप पर पुष्टिकरण ईमेल काम करने वाला पैटर्न है।
7. HTML, JSON या CSV पर regex उपयोग करना। उचित पार्सर का उपयोग करें; जो समय आप शुरू में बचाते हैं उसे bug में खो देंगे।

अधिक अक्सर पूछे जाने वाले प्रश्न

मेरा पैटर्न यहाँ क्यों काम करता है पर मेरे कोड में विफल होता है?

सबसे आम कारण इंजन के अंतर हैं। JavaScript का RegExp कुछ ऐसी सुविधाओं का समर्थन नहीं करता जो PCRE करता है (और इसके विपरीत)। आम जाल: lookbehinds JS में देर से जोड़े गए (ES2018), named groups सिंटैक्स थोड़ा भिन्न है, Unicode property escapes को u flag चाहिए, और [[:alpha:]] जैसी POSIX वर्ण क्लास JS में काफ़ी हद तक अनुपस्थित हैं। उस इंजन में परीक्षण करें जिसमें आप तैनात करेंगे।

क्या कई पंक्तियों में मेल खाने का «global» तरीक़ा है?

दो flags एक साथ काम करते हैं। m (multiline) flag ^ और $ को पूरी स्ट्रिंग के बजाय हर पंक्ति की शुरुआत और अंत से मेल खाने देता है। s (dotall) flag . को newline वर्णों से भी मेल खाने देता है। global के लिए g के साथ संयुक्त, आप ऐसे पैटर्न लिख सकते हैं जो पंक्तियों में फैले होते हैं और हर मेल खोजते हैं: /^foo.+$/gms।

क्या मेरे पैटर्न और परीक्षण पाठ कहीं भेजे जाते हैं?

नहीं। पैटर्न मैचिंग ब्राउज़र के निर्मित JavaScript RegExp इंजन का उपयोग करती है; कुछ भी किसी सर्वर पर अपलोड नहीं किया जाता। यह तब मायने रखता है जब आप वास्तविक production log डेटा, आंतरिक API प्रतिक्रियाओं या संवेदनशील सामग्री के विरुद्ध पैटर्न का परीक्षण कर रहे हों।

क्या मुझे lookbehinds सीखने चाहिए?

उपयोगी पर अनिवार्य नहीं। Lookbehinds आपको कुछ से पहले के पाठ से मेल खाने देते हैं उस «कुछ» को मेल में शामिल किए बिना। उदाहरण: (?<=\$)\d+ डॉलर चिह्न के बाद के अंकों से मेल खाता है डॉलर चिह्न को उपभोग किए बिना। वे PCRE, आधुनिक JavaScript (ES2018+) और Python के regex मॉड्यूल में समर्थित हैं। यदि आप पोर्टेबल पैटर्न लिख रहे हैं, तो पहले लक्ष्य इंजन की जाँच करें।

(?:...) का उपयोग (...) के बजाय क्यों करें?

ग़ैर-कैप्चरिंग समूह ((?:...)) थोड़े तेज़ हैं, capture array में स्लॉट नहीं लेते, और आपके मैच परिणामों को साफ़ रखते हैं। जब भी आपको alternation या quantification के लिए grouping की ज़रूरत हो पर मेल खाए पाठ को निकालने की ज़रूरत न हो, तब इन्हें उपयोग करें। (http|https):// एक capture बनाता है जिसकी आपको ज़रूरत न हो; (?:http|https):// नहीं बनाता।

Unicode वर्णों से मेल खाने का सही तरीक़ा क्या है?

JavaScript में, u flag जोड़ें और Unicode property escapes का उपयोग करें: /\p{Letter}+/gu किसी भी लिपि में अक्षरों के अनुक्रमों से मेल खाता है। u flag के बिना, \w केवल ASCII शब्द वर्णों से मेल खाता है। Python का re मॉड्यूल Python 3 में डिफ़ॉल्ट रूप से Unicode-aware है। Java को Pattern.UNICODE_CHARACTER_CLASS चाहिए। अधिकांश इंजनों में Unicode-aware होने का कुछ तरीक़ा है; अपने वाले के दस्तावेज़ देखें।