रेजेक्स पैटर्न लाइब्रेरी
60+ उपयोग के लिए तैयार regex पैटर्न। खोजें, कॉपी करें और ऑनलाइन परीक्षण करें।
इस लाइब्रेरी के बारे में
यह 60 से अधिक सामान्य रूप से उपयोग किए जाने वाले नियमित अभिव्यक्ति पैटर्न का संगठित, खोज योग्य संग्रह है, श्रेणी के अनुसार वर्गीकृत।
सब कुछ आपके ब्राउज़र में चलता है · कोई पैटर्न या परीक्षण टेक्स्ट कहीं नहीं भेजा जाता। इन पैटर्न का JavaScript, Python, PHP में उपयोग करें।
यह कैसे काम करता है
- ब्राउज़ या खोजें: श्रेणी के अनुसार पैटर्न ब्राउज़ करें (सत्यापन, निष्कर्षण, फ़ॉर्मेटिंग) या नाम से खोजें।
- पैटर्न का पूर्वावलोकन करें: प्रत्येक प्रविष्टि regex, यह क्या कैप्चर करती है इसका विवरण, नमूना इनपुट दिखाती है।
- अपने डेटा के साथ परखें: अपनी खुद की परीक्षण स्ट्रिंग दर्ज करें यह सत्यापित करने के लिए कि पैटर्न अपेक्षित कैप्चर करता है।
- उपयोग के लिए कॉपी करें: अपने कोड के लिए JavaScript, Python या POSIX प्रारूप में regex पैटर्न कॉपी करें।
regex लाइब्रेरी क्यों इस्तेमाल करें?
शुरुआत से नियमित अभिव्यक्ति लिखना लंबा और त्रुटि-प्रवण है। ईमेल मान्य करने, खोज/प्रतिस्थापन के लिए आवश्यक पैटर्न।
पैटर्न श्रेणियाँ
- सत्यापन: ईमेल, URL, फ़ोन, क्रेडिट कार्ड, IP पता, पिन कोड
- निष्कर्षण: तिथियाँ, मुद्राएँ, हैशटैग, उल्लेख, डोमेन नाम
- फ़ॉर्मेटिंग: व्हाइटस्पेस सामान्यीकरण, संख्या फ़ॉर्मेटिंग, slug जनरेशन
- सुरक्षा: पासवर्ड मज़बूती, SQL इंजेक्शन पहचान, XSS पैटर्न
- कोड: HTML टैग, टिप्पणियाँ, वेरिएबल नाम, CSS मान
रेगुलर एक्सप्रेशन कहाँ से आते हैं
«रेगुलर सेट» के गणितीय विचार को स्टीफन कोल क्लीन ने 1951 में RAND अनुसंधान ज्ञापन Representation of Events in Nerve Nets and Finite Automata में औपचारिक रूप दिया था। इस पृष्ठ पर * ऑपरेटर को आज भी उनके सम्मान में क्लीन स्टार कहा जाता है। केन थॉम्पसन ने जून 1968 के Communications of the ACM पेपर Programming Techniques: Regular Expression Search Algorithm में सिद्धांत को एल्गोरिथम में बदल दिया, और बेल लैब्स में QED एडिटर में पहला रेगेक्स कार्यान्वयन भेजा। 1973 तक, उसी इंजन ने ed, फिर grep (शाब्दिक विस्तार «globally search for regular expression and print» है), sed, और awk को संचालित किया। लैरी वॉल की Perl (1987) और विशेष रूप से Perl 5 (1994) ने नामित समूह, lookaround, गैर-लालची क्वांटिफायर और Unicode संभाल जोड़ा जो PCRE के रूप में जाने जाने वाले वास्तविक बोली बन गए, फिलिप हेज़ल ने 1997 में इसे C में लाइब्रेरी के रूप में पोर्ट किया।
इंजन रूप और उनके बीच क्या बदलता है
एक पैटर्न जो JavaScript में स्वच्छ रूप से चलता है, वह Go में चुपचाप विफल हो सकता है और POSIX में बिल्कुल अस्वीकार हो सकता है। पाँच रूप जिनसे एक डेवलपर सबसे अधिक संभावना से मिलेगा:
- POSIX BRE / ERE (IEEE Std 1003.2-1992): एक स्टॉक यूनिक्स सिस्टम पर
grep,sed, औरawkकी बोली। कोई lookaround नहीं, कोई नामित समूह नहीं, कोई Unicode गुण एस्केप नहीं। BRE को अतिरिक्त रूप से(,),{,}, और|को एस्केप करने की आवश्यकता होती है। - PCRE2 (फिलिप हेज़ल, 1997, वर्तमान प्रमुख संस्करण 10.x): सबसे फ़ीचर-पूर्ण बोली। Lookaround, नामित समूह
(?<name>...), परमाणु समूह, स्वामित्व क्वांटिफायर, पुनरावृत्ति। PHPpreg_*, Apache, nginx, R द्वारा उपयोग किया जाता है। - ECMAScript रेगेक्स (ECMA-262, रेगेक्स खंड 22.2): JavaScript बोली। ES2018 ने नामित समूह, lookbehind, और
s(dotAll) औरu(Unicode) फ़्लैग जोड़े। ES2022 ने मैच इंडेक्स के लिएdफ़्लैग जोड़ा। ES2024 ने सेट-नोटेशन क्लास के साथvफ़्लैग जोड़ा। - Python
re: PCRE के करीब, लेकिन नामित समूहों के लिए(?P<name>...)का उपयोग करता है (PEP 433) और एक अलग वर्बोज़ मोडre.X। नया तृतीय-पक्ष मॉड्यूलregexपुनरावर्ती पैटर्न और POSIX सबसे लंबी मैच शब्दार्थ जोड़ता है। - RE2 (रस कॉक्स, 2010): Go के
regexpऔर Rust केregexcrate के पीछे का इंजन। कोई lookaround नहीं, कोई बैकरेफरेंस नहीं, कोई स्वामित्व क्वांटिफायर नहीं, जानबूझकर। ट्रेडऑफ़: गारंटीकृत रैखिक समय, कोई विनाशकारी बैकट्रैकिंग नहीं। यदि इस लाइब्रेरी से एक पैटर्न(?=...)या\1का उपयोग करता है, तो यह Go में संकलित नहीं होगा।
विनाशकारी बैकट्रैकिंग और ReDoS
मुख्यधारा की भाषाओं में अधिकांश रेगेक्स इंजन (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) बैकट्रैकिंग इंजन हैं। जब (a+)+ जैसे नेस्टेड क्वांटिफायर वाला पैटर्न लगभग मैच करने वाले इनपुट से टकराता है, तो इंजन हार मानने से पहले वैकल्पिक पथों की एक एक्सपोनेंशियल संख्या आज़मा सकता है। यह विनाशकारी बैकट्रैकिंग है, और यह OWASP द्वारा कैटलॉग किए गए ReDoS (Regular expression Denial of Service) हमले वर्ग का आधार है।
Stack Overflow, 20 जुलाई 2016: अग्रणी और अनुगामी सफेद स्थान को ट्रिम करने के लिए डिज़ाइन किया गया एक पैटर्न, 20 000 क्रमिक सफेद स्थान वर्णों वाले प्रश्न निकाय पर लागू किया गया, प्रति अनुरोध 11 मिनट CPU लिया और साइट को 34 मिनट के लिए अनुत्तरदायी बना दिया। आधिकारिक Stack Status ब्लॉग पर पोस्ट-मॉर्टम ने ट्रिम रेगेक्स को मूल स्ट्रिंग ट्रिम से बदलने की सिफारिश की।
Cloudflare, 2 जुलाई 2019: नेस्टेड-क्वांटिफायर पैटर्न .*(?:.*=.*) वाला एक WAF नियम विश्व स्तर पर तैनात किया गया था और हर एज सर्वर पर 27 मिनट के लिए 100% CPU उपभोग किया, जिससे सार्वजनिक इंटरनेट के बड़े हिस्से ऑफलाइन हो गए। Cloudflare के ब्लॉग पर पोस्ट-मॉर्टम ने Rust के regex crate (एक RE2-आधारित, रैखिक-समय इंजन) पर स्विच को पुनरावृत्ति को रोकने का श्रेय दिया।
रक्षात्मक सबक: नेस्टेड क्वांटिफायर से बचें ((a+)+, (a*)*, (a|aa)+); हमलावर-नियंत्रित इनपुट पर \s+$-शैली ट्रिम से बचें; PCRE में परमाणु समूह (?>...) या स्वामित्व क्वांटिफायर a++ को प्राथमिकता दें; और उच्च-थ्रूपुट सेवाओं के लिए RE2-आधारित इंजन पर विचार करें।
ईमेल, URL, फोन, तारीख, क्रेडिट कार्ड: रेगेक्स का उपयोग कब नहीं करें
ईमेल। RFC 5322 (अक्टूबर 2008) का पूरा व्याकरण लगभग 3 000 वर्णों का एक रेगेक्स में संकलित होता है। <input type="email"> सत्यापन के लिए W3C HTML5 विनिर्देशन एक बहुत छोटे «क्या यह संभावित रूप से एक ईमेल है» रेगेक्स का उपयोग करता है जो क्लाइंट-साइड संकेतों के लिए सही प्रारंभिक बिंदु है। RFC 6531 (फरवरी 2012) 用户@example.com जैसे गैर-ASCII पतों की अनुमति देता है, जिन्हें केवल-ASCII रेगेक्स गलत तरीके से अस्वीकार करेगा। RFC 6532 के बाद से उद्योग सहमति: ईमेल को रेगेक्स से सत्यापित न करें, बल्कि सत्यापन ईमेल भेजें।
URL। RFC 3986 (जनवरी 2005) URI सामान्य सिंटैक्स विनिर्देशन है, लेकिन WHATWG URL Living Standard जानबूझकर इससे विचलित होता है ताकि वह वास्तव में स्वीकार करने वाले ब्राउज़रों से मेल खा सके। एक त्वरित दृश्य जांच से परे किसी भी चीज़ के लिए रेगेक्स के बजाय JavaScript में new URL("...") या Python में urllib.parse का उपयोग करें।
फोन नंबर। ITU-T अनुशंसा E.164 (वर्तमान संशोधन नवंबर 2010) वैकल्पिक + उपसर्ग के साथ अधिकतम 15 अंकों की अनुमति देता है, लेकिन देश-विशिष्ट नियम बहुत भिन्न होते हैं। Google का ओपन-सोर्स libphonenumber लाइब्रेरी हर क्षेत्र के लिए प्रति-देश नियमों को एन्कोड करता है और एकमात्र विश्वसनीय क्रॉस-देश सत्यापनकर्ता है।
तारीखें। ^\d{4}-\d{2}-\d{2}$ जैसा रेगेक्स ISO 8601-1:2019 कैलेंडर प्रारूप से मेल खाता है, लेकिन यह 2026-02-31 को भी स्वीकार करता है। तारीख वैधता को कैलेंडर तर्क की आवश्यकता होती है, पैटर्न मिलान की नहीं; Date.parse() या एक तारीख लाइब्रेरी का उपयोग करें।
क्रेडिट कार्ड। एक रेगेक्स अंक लंबाई और IIN उपसर्ग से मेल खा सकता है (Visa 4 से शुरू होता है, Mastercard 51-55 या 2221-2720 से, Amex 34 या 37 से) लेकिन Luhn चेकसम को सत्यापित नहीं कर सकता (हंस पीटर लुह्न, IBM, अगस्त 1960 को प्रदान किया गया US पेटेंट 2 950 048)। Luhn को अंक-दर-अंक मॉड्यूलो 10 योग की आवश्यकता है।
डेवलपर इस लाइब्रेरी का उपयोग करने के सामान्य तरीके
- क्लाइंट-साइड फ़ॉर्म संकेत, इस समझ के साथ कि एक रेगेक्स कैच एक संकेत है, अंतिम सत्यापन नहीं।
- लॉग स्क्रैपिंग, एप्लिकेशन लॉग से टाइमस्टैम्प, IP, त्रुटि कोड और URL को एक पाइपलाइन में निकालना।
- एक बार का डेटा क्लीनअप: सफेद स्थान को सामान्य करना, HTML टैग को छीनना, तारीख प्रारूपों के बीच परिवर्तित करना, शीर्षकों को slugify करना।
- एडिटर खोजें-और-बदलें VS Code, Sublime, vim, IntelliJ में जहाँ रेगेक्स रूप PCRE के करीब है।
- राउटर और URL मिलान पैटर्न Express, Flask, FastAPI, Rails में।
- WAF और घुसपैठ-पहचान नियम, ReDoS के बारे में अत्यंत सावधानी के साथ जैसा कि Cloudflare 2019 घटना ने प्रदर्शित किया।
- तेज़ स्ट्रिंग परीक्षण इस पृष्ठ के नीचे-स्क्रीन परीक्षण पैनल में, पैटर्न को कोड में प्रतिबद्ध करने से पहले।
सामान्य गलतियाँ
- एंकर भूलना।
^और$के बिना (या PCRE में\Aऔर\z), एक सत्यापन रेगेक्स तब मेल खाता है जब पैटर्न स्ट्रिंग में कहीं भी प्रकट होता है।/\d{4}/«year 2026 was good»से मेल खाता है, जो लगभग कभी नहीं आप जो चाहते हैं। - कई चीज़ों पर
.*पर भरोसा करना। इनपुट<a href="a"><a href="b">पर<a href=".*">दोनों टैग पर कब्जा करता है क्योंकि.*लालची है। आलसी के लिए.*?का उपयोग करें, या बेहतर, असली पार्सर के साथ पार्स करें। - मान लेना कि बिंदु न्यूलाइन से मेल खाता है। डिफ़ॉल्ट रूप से
.लाइन टर्मिनेटर को छोड़कर सब कुछ से मेल खाता है। JS मेंs(dotAll) फ़्लैग का उपयोग करें, या Python मेंre.DOTALL, या PCRE में इनलाइन संशोधक(?s)। - मान लेना कि
\wमें गैर-ASCII अक्षर शामिल हैं। ASCII मोड में,\w[a-zA-Z0-9_]है। JS मेंuफ्लैग जोड़ें (ES2018+) और किसी भी Unicode अक्षर के लिए\p{L}का उपयोग करें; Python मेंre.UNICODEजोड़ें (Python 3 में डिफ़ॉल्ट)। - Go में बैकरेफरेंस। Go का
regexpRE2 है और संकलन समय पर\1को अस्वीकार करता है। त्रुटि«error parsing regexp: invalid escape sequence: \1»का अर्थ है कि पैटर्न को एक गैर-रेगेक्स दृष्टिकोण में विभाजित करने की आवश्यकता है। - रेगेक्स के साथ HTML पार्स करना। प्रसिद्ध रूप से असंभव: HTML एक नियमित भाषा नहीं है। एक DOM पार्सर (ब्राउज़र का अंतर्निहित
DOMParser, cheerio, BeautifulSoup, lxml) का उपयोग करें।
अधिक अक्सर पूछे जाने वाले प्रश्न
कुछ पैटर्न (...) के बजाय (?:...) का उपयोग क्यों करते हैं?
(?:...) एक गैर-कैप्चरिंग समूह है: यह पुनरावृत्ति या वैकल्पिकता के लिए समूहित करता है लेकिन एक बैकरेफरेंस स्लॉट आवंटित नहीं करता है। यह तेज़ है और परिणाम सरणी में $1, $2 को प्रदूषित करने से बचाता है। जब आपको कैप्चर किए गए पाठ को निकालने की आवश्यकता हो तो (...) का उपयोग करें; केवल समूहीकरण के लिए (?:...) का उपयोग करें।
सबसे आम रेगेक्स फ़्लैग क्या हैं?
i केस-असंवेदनशील, g वैश्विक (सभी खोजें, JS-विशिष्ट व्यवहार), m मल्टीलाइन (ताकि ^ और $ लाइन सीमाओं से मेल खाएँ), s dotAll (ताकि . न्यूलाइन से मेल खाए, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v सेट-नोटेशन क्लास (ES2024+)। /pattern/gimsu के रूप में संयोजित करें।
मैं एक अक्षर शाब्दिक विशेष वर्ण से कैसे मेल खाऊँ?
इसे बैकस्लैश से एस्केप करें। शाब्दिक मिलान के लिए एस्केप करने वाले रेगेक्स मेटाकैरेक्टर हैं: . ^ $ * + ? ( ) [ ] { } | \ /। एक चरित्र वर्ग [...] के अंदर विशेष वर्णों का सेट छोटा है: केवल ] \ ^ - को स्थिति के आधार पर एस्केप करने की आवश्यकता है।
क्या मैं शेल स्क्रिप्ट में इस लाइब्रेरी के पैटर्न का उपयोग कर सकता हूँ?
हाँ, चेतावनियों के साथ। grep डिफ़ॉल्ट रूप से POSIX BRE का उपयोग करता है; grep -E ERE का उपयोग करता है; grep -P उन सिस्टमों पर PCRE का उपयोग करता है जहाँ libpcre लिंक है (GNU grep, Homebrew के साथ macOS grep)। lookaround, नामित समूह, या Unicode एस्केप का उपयोग करने वाले पैटर्न को grep -P या ripgrep की आवश्यकता होती है (जो Rust के RE2-आधारित इंजन का उपयोग करता है और lookaround को अस्वीकार करता है)।
क्या ये पैटर्न सर्वर पर भेजे जाते हैं?
नहीं। इस पृष्ठ पर हर रेगेक्स, आप जो भी खोज टाइप करते हैं, और हर स्ट्रिंग जिसे आप त्वरित-परीक्षण पैनल में परीक्षण करते हैं, आपके ब्राउज़र के JavaScript इंजन में संसाधित होती है। कोई नेटवर्क कॉल नहीं की जाती। पैटर्न डेटा स्वयं पृष्ठ बंडल में एक स्थिर JSON फ़ाइल के रूप में भेजा जाता है। सत्यापन के लिए DevTools में नेटवर्क टैब खोलें।