रेगेक्स टेस्टर
रेगुलर एक्सप्रेशन लाइव बनाएँ और डीबग करें। एक पैटर्न टाइप करें, फ्लैग टॉगल करें, और हर मैच
आपके टेस्ट टेक्स्ट में उसके नंबर वाले और नामित कैप्चर ग्रुप के साथ नीचे सूचीबद्ध होकर जगमगा उठता है।
$1 प्रतिस्थापन का पूर्वावलोकन देखने के लिए रिप्लेस मोड चालू करें, कोई आम-पैटर्न प्रीसेट
लोड करें, और चीटशीट पास रखें। ब्राउज़र के मूल JavaScript RegExp इंजन का उपयोग करता है,
इसलिए यह बिलकुल आपके कोड की तरह व्यवहार करता है — और कुछ भी कभी अपलोड नहीं होता।
कोई आम पैटर्न आज़माएँ
किसी प्रीसेट पर क्लिक करके उसका पैटर्न, फ्लैग और एक नमूना स्ट्रिंग लोड करें, फिर उसे बदलें।
रेगेक्स टेस्टर का उपयोग कैसे करें
- अपना पैटर्न टाइप करें एक्सप्रेशन बॉक्स में — आसपास स्लैश की ज़रूरत नहीं, बस रेगेक्स का मुख्य हिस्सा।
- अपनी ज़रूरत के फ्लैग चुनें। हर मैच देखने के लिए
gचालू रखें; केस-असंवेदनशील मैचिंग के लिएiजोड़ें। - अपना टेक्स्ट पेस्ट करें टेस्ट बॉक्स में। मैच तुरंत हाइलाइट होते हैं, बारी-बारी रंगों में ताकि पास-पास के मैच आसानी से अलग पहचाने जा सकें।
- ग्रुप पढ़ें — हर मैच अपने नंबर वाले और नामित कैप्चर ग्रुप सूचीबद्ध करता है ताकि आप पुष्टि कर सकें कि आप सही टुकड़े निकाल रहे हैं।
- प्रतिस्थापन का पूर्वावलोकन करें — "रिप्लेस दिखाएँ" चालू करें और टेक्स्ट फिर से बनाने के लिए
$1,$<name>या$&का उपयोग करें। - परिणाम कॉपी करें और पैटर्न को सीधे अपने JavaScript, TypeScript या Node.js कोड में डालें।
रेगेक्स चीटशीट
| टोकन | किससे मैच होता है |
|---|---|
. | न्यूलाइन को छोड़कर कोई भी वर्ण (s फ्लैग के साथ न्यूलाइन से भी मैच)। |
\d \D | एक अंक 0–9 / कोई भी ग़ैर-अंक। |
\w \W | एक शब्द-वर्ण [A-Za-z0-9_] / कोई भी ग़ैर-शब्द-वर्ण। |
\s \S | कोई भी खाली जगह (स्पेस, टैब, न्यूलाइन) / कोई भी ग़ैर-खाली-जगह। |
[abc] [^abc] | a, b, c में से कोई एक / a, b, c को छोड़कर कोई भी वर्ण। |
[a-z] | एक रेंज — कोई भी छोटा अक्षर। रेंज जोड़ें: [A-Za-z0-9]। |
^ $ | स्ट्रिंग का आरंभ / अंत (या m फ्लैग के साथ हर पंक्ति का)। |
\b \B | एक शब्द-सीमा / ऐसी स्थिति जो शब्द-सीमा नहीं है। |
* + ? | पिछले टोकन के 0 या अधिक / 1 या अधिक / 0 या 1। |
{n} {n,} {n,m} | ठीक n / n या अधिक / n और m के बीच पुनरावृत्तियाँ। |
*? +? ?? | Lazy (non-greedy) — जितने कम वर्ण संभव हो उतने मैच करें। |
a|b | Alternation — a या b मैच करें। |
( ) | एक नंबर वाला कैप्चर ग्रुप। |
(?<name> ) | एक नामित कैप्चर ग्रुप, $<name> के रूप में संदर्भित। |
(?: ) | एक non-capturing ग्रुप (कैप्चर बनाए बिना समूहित करता है)। |
(?= ) (?! ) | Positive / negative lookahead। |
(?<= ) (?<! ) | Positive / negative lookbehind। |
\p{L} \p{N} | यूनिकोड प्रॉपर्टी एस्केप (letter / number) — u फ्लैग चाहिए। |
भरोसेमंद रेगुलर एक्सप्रेशन लिखने के लिए सुझाव
- विशेष वर्ण एस्केप करें — एक शाब्दिक डॉट, प्लस या प्रश्नचिह्न को
\.,\+,\?लिखना चाहिए। किसी कैरेक्टर क्लास के भीतर अधिकांश मेटा-वर्ण अपना अर्थ खो देते हैं। - ग्रीडी से बेहतर विशिष्ट —
"[^"]*"किसी उद्धृत स्ट्रिंग को".*"की तुलना में ज़्यादा सुरक्षित पढ़ता है, जो एक ही पंक्ति में कई स्ट्रिंग निगल सकता है। - जहाँ संभव हो एंकर करें —
^और$(या\bसीमाएँ) जोड़ना आंशिक मैच रोकता है और इंजन को जल्दी विफल होने में मदद करता है। - नामित ग्रुप का उपयोग करें —
(?<id>\d+)को बनाए रखना$1के लिए कोष्ठक गिनने की तुलना में कहीं आसान है। - नेस्टेड क्वांटिफ़ायर पर ध्यान दें —
(a+)+जैसे पैटर्न catastrophic backtracking का कारण बन सकते हैं; इन्हें एक ही कैरेक्टर क्लास में समतल करें। - एज-केस टेस्ट करें — खाली इनपुट, प्रति पंक्ति कई मैच, और सबसे लंबी वास्तविक स्ट्रिंग। एक अच्छा रेगेक्स वह है जो सही ढंग से विफल होता है, न कि सिर्फ़ वह जो एक बार पास होता है।
रेगुलर एक्सप्रेशन का संक्षिप्त इतिहास
रेगुलर एक्सप्रेशन की शुरुआत प्रोग्रामिंग से नहीं, बल्कि शुद्ध गणित से हुई। 1951 में अमेरिकी
तर्कशास्त्री Stephen Cole Kleene ने प्रतीकों के अनुक्रमों में सरल पैटर्न वर्णित
करने का एक तरीक़ा औपचारिक रूप दिया, जिन्हें उन्होंने regular events (आज हम
regular languages कहते हैं) कहा। उनके संकेतन ने वह संचालक पेश किया जो आज भी उनके नाम से
जाना जाता है — Kleene star, जिसे * लिखा जाता है, जिसका अर्थ है
"पिछले तत्व के शून्य या अधिक"। यही एक विचार — एक छोटी, परिमित अभिव्यक्ति से स्ट्रिंगों के असीमित
समूह का वर्णन — वह नींव है जिस पर हर रेगेक्स इंजन टिका है।
रेगुलर एक्सप्रेशन कंप्यूटरों तक Ken Thompson के माध्यम से पहुँचे, जो Unix के
सह-निर्माता थे। 1960 के दशक के अंत में उन्होंने Kleene के संकेतन को QED टेक्स्ट एडिटर में और बाद
में Unix एडिटर ed में डाला ताकि उपयोगकर्ता फ़ाइलों को पैटर्न से खोज सकें। सबसे प्रसिद्ध
वंशज grep है, जिसका नाम सीधे ed कमांड g/re/p से आता है —
“globally search for a regular expression
and print the matching lines”। Thompson ने 1968 में एक रेगुलर एक्सप्रेशन को
तेज़ खोज-कोड में संकलित करने का एल्गोरिथ्म भी प्रकाशित किया, ऐसा काम जो आज भी आधुनिक उच्च-प्रदर्शन
इंजनों को आधार देता है।
वहाँ से रेगेक्स Unix टूलचेन में फैला — sed, awk, lex — और
फिर Perl भाषा के साथ लोकप्रियता में विस्फोट हुआ, जिसने शक्तिशाली पैटर्न मैचिंग को
एक प्रथम-श्रेणी सुविधा बना दिया। Perl की बोली इतनी प्रभावशाली हुई कि 1997 में Philip Hazel ने
PCRE (Perl Compatible Regular Expressions) बनाया, एक C लाइब्रेरी जो अब PHP,
Apache और Nginx वेब सर्वरों तथा अनगिनत अन्य टूलों में समाहित है। समानांतर में, 1992 के
POSIX.2 मानक ने दो पोर्टेबल फ़्लेवर परिभाषित किए — Basic और Extended Regular
Expressions — जिनका Unix यूटिलिटी आज भी पालन करती हैं। आपके ब्राउज़र का इंजन, ECMAScript का
RegExp, फिर से एक अलग वंश है, जिसे JavaScript के हिस्से के रूप में मानकीकृत किया गया।
इंजन के पीछे का सिद्धांत
एक “regular” भाषा ठीक वही है जिसे एक परिमित ऑटोमेटन (finite automaton) — नियत संख्या में अवस्थाओं और बिना किसी अतिरिक्त मेमोरी वाली मशीन — पहचान सकती है। हर रेगुलर एक्सप्रेशन को ऐसी मशीन में बदला जा सकता है, और वापस भी; दोनों गणितीय रूप से समतुल्य हैं। Thompson’s construction किसी पैटर्न को एक nondeterministic finite automaton (NFA) में बदलता है, जिसे फिर एक deterministic finite automaton (DFA) में रूपांतरित किया जा सकता है जो हर इनपुट वर्ण को ठीक एक बार पढ़ता है।
यह सिद्धांत समझाता है कि रेगेक्स इंजन के दो बहुत अलग परिवार क्यों मौजूद हैं।
ऑटोमेटन (DFA-शैली) इंजन — जिन्हें grep, Google का RE2 और Rust का
regex crate इस्तेमाल करते हैं — पैटर्न कितना भी बुरा क्यों न हो, रैखिक समय में मैचिंग
की गारंटी देते हैं, पर कुछ सुविधाजनक विशेषताएँ नहीं दे पाते। बैकट्रैकिंग इंजन —
जिन्हें Perl, PCRE, Python, Java, .NET और JavaScript इस्तेमाल करते हैं — संभावनाओं को आज़माइश और
त्रुटि से खोजते हैं, जिससे वे backreferences और lookaround का समर्थन कर पाते हैं, पर कभी-कभी
catastrophic धीमेपन की क़ीमत पर (नीचे देखें)। जब आप यहाँ कोई पैटर्न टेस्ट करते हैं तो आप एक
बैकट्रैकिंग इंजन चला रहे होते हैं, और इसे समझना ऐसे पैटर्न लिखने की कुंजी है जो तेज़ बने रहें।
रेगेक्स फ़्लेवर: JavaScript कैसे भिन्न है
कोई एक अकेली रेगुलर-एक्सप्रेशन भाषा नहीं है — कई निकट-संबंधी बोलियाँ हैं, और एक पैटर्न जो एक में बढ़िया काम करता है वह दूसरे में अलग व्यवहार कर सकता है, या विफल हो सकता है। यह टेस्टर ECMAScript (JavaScript) इंजन चलाता है, वही जो Node.js और हर ब्राउज़र में है, इसलिए आप यहाँ जो देखते हैं वही आपका JavaScript या TypeScript कोड करेगा।
| फ़्लेवर | यह कहाँ मिलता है | उल्लेखनीय विशेषताएँ |
|---|---|---|
| POSIX BRE / ERE | grep, sed, शेल टूल | BRE को ग्रुप के लिए \( चाहिए; ERE बिना एस्केप किए + ? | जोड़ता है। |
| PCRE / Perl | PHP, Nginx, कई एडिटर | सबसे समृद्ध बोली: atomic groups, possessive quantifiers, recursion। |
Python re | Python स्क्रिप्ट | इनलाइन फ्लैग और नामित ग्रुप (?P<name>…) के रूप में लिखे जाते हैं। |
| .NET / Java | C#, Java एप्लिकेशन | अतिरिक्त सुविधाओं के साथ बैकट्रैकिंग; .NET प्रति-मैच टाइमआउट का समर्थन करता है। |
| ECMAScript | यह टूल, ब्राउज़र, Node.js | कोई atomic groups या possessive quantifiers नहीं; नामित ग्रुप (?<name>…) का उपयोग करते हैं। |
JavaScript का इंजन तेज़ी से परिपक्व हुआ है। u (unicode) और y (sticky)
फ्लैग ES2015 में आए। ES2018 एक ऐतिहासिक रिलीज़ थी जिसने नामित कैप्चर ग्रुप (?<name>…), lookbehind assertions (?<=…) और
(?<!…), s (dotAll) फ्लैग, और यूनिकोड प्रॉपर्टी एस्केप
जैसे \p{L} जोड़े। हाल ही में match indices के लिए d फ्लैग
(ES2022) और विस्तारित यूनिकोड सेट के लिए v फ्लैग (ES2024) जोड़े गए। PCRE की तुलना में
JavaScript में अब भी जो कमी है वह है possessive quantifiers (a++)
और atomic groups ((?>…)) — वही उपकरण जो अन्य भाषाएँ भागते हुए
बैकट्रैकिंग को रोकने के लिए इस्तेमाल करती हैं, यही कारण है कि अगला भाग JS डेवलपरों के लिए इतना
मायने रखता है।
ग्रीडी, लेज़ी और मैचिंग कैसे आगे बढ़ती है
यह समझना कि इंजन आपके टेक्स्ट से कैसे गुज़रता है, रेगेक्स को अनुमान से एक पूर्वानुमेय
उपकरण में बदल देता है। डिफ़ॉल्ट रूप से हर क्वांटिफ़ायर ग्रीडी (greedy) होता है:
*, + और ? जितना टेक्स्ट हो सके उतना पकड़ लेते हैं, फिर
एक-एक करके वर्ण वापस देते हैं (यह वापस देना ही बैकट्रैकिंग है) जब तक बाक़ी पैटर्न मैच न कर सके।
इसलिए ".*" जब he said "one" then "two" पर लगाया जाता है तो पहले उद्धरण
से अंतिम उद्धरण तक का पूरा हिस्सा मैच करता है, क्योंकि ग्रीडी .* झुकने से पहले सब कुछ
निगल लेता है।
किसी क्वांटिफ़ायर को लेज़ी (lazy, non-greedy) बनाने के लिए उसमें ?
जोड़ें: ".*?" जितना कम संभव हो उतना मैच करता है, पहले बंद उद्धरण पर रुककर, इसलिए यह
केवल "one" पकड़ता है। अक्सर साफ़-सुथरा हल एक निषेधित कैरेक्टर क्लास
(negated character class) होता है: "[^"]*" कहता है “एक उद्धरण, फिर
ग़ैर-उद्धरण वर्णों की कोई श्रृंखला, फिर एक उद्धरण”, जो अस्पष्टता-रहित भी है और तेज़ भी क्योंकि
इसे कभी बैकट्रैक नहीं करना पड़ता। ग्रीडी बनाम लेज़ी बनाम निषेधित क्लास चुनना वास्तविक पैटर्न में
सबसे आम निर्णयों में से एक है, और ऊपर की लाइव हाइलाइटिंग इस अंतर को देखना आसान बना देती है।
Catastrophic backtracking और ReDoS
चूँकि JavaScript एक बैकट्रैकिंग इंजन इस्तेमाल करता है, एक लापरवाह पैटर्न कुछ इनपुट पर
घातांकीय (exponential) समय ले सकता है — एक असली सुरक्षा दोष जिसे
regular-expression denial of service (ReDoS) कहते हैं। मुसीबत तब सामने आती है जब
कोई दोहराया गया ग्रुप एक ही टेक्स्ट को कई ओवरलैप करते तरीक़ों से मैच कर सकता है और फिर पूरा मैच
विफल हो जाता है। पाठ्यपुस्तक का उदाहरण (a+)+$ है, जिसे a वर्णों की एक
लंबी स्ट्रिंग के विरुद्ध टेस्ट किया जाए जिसके बाद एक ऐसा वर्ण हो जो मैच न कर सके: इंजन
a-ओं को भीतरी और बाहरी + के बीच बाँटने का हर तरीक़ा आज़माता है, और
संयोजनों की संख्या हर अतिरिक्त वर्ण के साथ लगभग दोगुनी हो जाती है। कुछ दर्जन वर्ण एक टैब को — या
किसी सर्वर पर, एक पूरे रिक्वेस्ट थ्रेड को — जाम कर सकते हैं।
Perl और PCRE जैसी भाषाएँ इसे atomic groups और possessive quantifiers से निष्क्रिय कर देती हैं जो इंजन को किसी ग्रुप में वापस बैकट्रैक करने से रोकते हैं। JavaScript के पास दोनों में से कोई नहीं है, इसलिए आपको ख़तरे को डिज़ाइन से ही हटाना होता है:
- ओवरलैप करते टेक्स्ट पर कभी क्वांटिफ़ायर नेस्ट न करें।
(a+)+को एक अकेलेa+के रूप में, और(\w+\s?)+को[\w\s]+के रूप में फिर से लिखें। - दोहराए गए हिस्सों को परस्पर-अनन्य बनाएँ। किसी
(.*a)-शैली के लूप को([^a]*a)में बदलना उस ओवरलैप को हटा देता है जो बैकट्रैकिंग को हवा देता है। - एंकर करें और विशिष्ट बनें। सीमाएँ (
^,$,\b) और सख़्त कैरेक्टर क्लास इंजन को मृत रास्ते खोजने के बजाय जल्दी विफल होने देती हैं। - अपने इनपुट को सीमित करें। जिन स्ट्रिंगों के विरुद्ध आप अविश्वसनीय पैटर्न टेस्ट करते हैं उनकी लंबाई सीमित करें, और उपयोगकर्ता-आपूर्ति पैटर्न की सर्वर-साइड मैचिंग के लिए रैखिक-समय लाइब्रेरी (Google का RE2, Rust का
regexcrate) को प्राथमिकता दें।
एक उपयोगी नियम: यदि कोई पैटर्न इस टेस्टर में धीमा महसूस होता है, तो यह प्रोडक्शन में भी धीमा — और शोषण-योग्य — होगा। यहाँ का मैच काउंटर पेज को उत्तरदायी रखने के लिए अपनी पुनरावृत्तियों को सीमित करता है, पर वह सुरक्षा-जाल आपके एप्लिकेशन कोड में मौजूद नहीं होता।
रेगुलर एक्सप्रेशन किसमें अच्छे हैं (और किसमें बुरे)
रेगेक्स सपाट, पंक्ति-उन्मुख टेक्स्ट को खोजने, मान्य करने, निकालने और बदलने के लिए सही उपकरण है: किसी लॉग में हर ईमेल-आकार की स्ट्रिंग खोजना, किसी रिपोर्ट से तिथियाँ निकालना, किसी सीमांकित पंक्ति को विभाजित करना या एक टोकन को दूसरे से बदलना। यह तब उत्कृष्ट होता है जब संरचना स्थानीय और पूर्वानुमेय हो।
यह किसी गहराई से नेस्टेड या पुनरावर्ती (recursive) चीज़ के लिए ग़लत उपकरण है। वही
सिद्धांत जो रेगुलर भाषाओं को तेज़ बनाता है, उन्हें मनमानी नेस्टिंग गिनने में भी असमर्थ बना देता है —
एक परिमित ऑटोमेटन के पास यह ट्रैक करने की मेमोरी नहीं होती कि कितने ब्रैकेट अब भी खुले हैं। यही असली
वजह है उस प्रसिद्ध चेतावनी के पीछे कि रेगुलर एक्सप्रेशन से कभी HTML पार्स न करें: HTML, XML
और JSON नेस्टेड व्याकरण हैं, और एक पैटर्न जो काम करता दिखता है वह पहले कमेंट, नेस्टेड टैग या एज-केस
पर टूट जाएगा। इसके बजाय किसी समर्पित पार्सर का उपयोग करें (ब्राउज़र का DOMParser, या
JSON के लिए JSON.parse)।
ईमेल क्लासिक अति-पहुँच है। एक पैटर्न जो RFC 5322 पता व्याकरण को पूरी तरह लागू करता है वह सैकड़ों
वर्ण लंबा होता है और फिर भी पुष्टि नहीं कर सकता कि कोई पता वास्तव में मेल प्राप्त करता है। व्यवहार
में [^@\s]+@[^@\s]+\.[^@\s]+ जैसी एक सरल जाँच और एक वास्तविक पुष्टिकरण ईमेल किसी भी
राक्षसी रेगेक्स से बेहतर है। यह सीख सामान्यीकृत होती है: रेगेक्स तब उठाएँ जब पैटर्न सचमुच रेगुलर हो,
और जब न हो तो किसी पार्सर या उद्देश्य-निर्मित लाइब्रेरी की ओर जाएँ।
Lookaround और backreferences: संदर्भ में मैचिंग
दो विशेषताएँ किसी पैटर्न को उसके परिवेश का निरीक्षण करने देती हैं बिना उसे उपभोग किए। एक
lookahead यह दावा करता है कि आगे जो है वह मैच करता है ((?=…)) या नहीं
करता ((?!…)), और एक lookbehind पहले जो है उसके लिए वही करता है
((?<=…) और (?<!…))। उदाहरण के लिए, \d+(?= kg) किसी
संख्या को केवल तब मैच करता है जब उसके बाद “ kg” हो, फिर भी “ kg” स्वयं मैच
से बाहर रहता है — तब उपयोगी जब आप कोई मान खोजना चाहें पर उसकी इकाई को पकड़े गए टेक्स्ट से बाहर रखना
चाहें। JavaScript ES2018 से lookbehind का समर्थन करता है, इसलिए इस टेस्टर में दोनों दिशाएँ काम करती
हैं।
एक backreference उसे फिर से इस्तेमाल करता है जो किसी पहले वाले ग्रुप ने पकड़ा।
पैटर्न के भीतर, \1 का अर्थ है “वही टेक्स्ट जो ग्रुप 1 ने अभी मैच किया”,
इसलिए (\w+)\s+\1 “the the” जैसा दोहराया गया शब्द खोजता है, और
\k<name> किसी नामित ग्रुप के लिए वही करता है। Backreferences उन विशेषताओं में से
एक हैं जो एक शुद्ध ऑटोमेटन इंजन नहीं दे सकता, यही ठीक वजह है कि JavaScript एक बैकट्रैकिंग इंजन
इस्तेमाल करता है — और यही वजह है कि ऊपर दी catastrophic-backtracking चेतावनियाँ उस हर चीज़ पर लागू
होती हैं जो आप शिप करते हैं।
अक्सर पूछे जाने वाले सवाल
यह टेस्टर कौन-सा रेगेक्स सिंटैक्स इस्तेमाल करता है?
यह ब्राउज़र के मूल JavaScript (ECMAScript) रेगुलर-एक्सप्रेशन इंजन का उपयोग करता है — ठीक वही RegExp कार्यान्वयन जिसमें आपका कोड Node.js, Deno और हर आधुनिक ब्राउज़र में चलता है। इसका मतलब है कि यहाँ आप जो पैटर्न टेस्ट करते हैं वे प्रोडक्शन JavaScript में बिलकुल वैसा ही व्यवहार करते हैं। JavaScript रेगेक्स PCRE (PHP/Perl), Python के re, Java और .NET से छोटे-छोटे तरीक़ों में भिन्न है — उदाहरण के लिए JavaScript में इनलाइन (?i) मॉडिफ़ायर नहीं हैं, कोई possessive क्वांटिफ़ायर नहीं है, और नामित ग्रुप (?<name>…) सिंटैक्स का उपयोग करते हैं। यदि आप किसी दूसरी भाषा के लिए लिख रहे हैं तो इन एज-केसों की दोबारा जाँच करें, पर JS/TypeScript के लिए यह प्रामाणिक है।
फ्लैग g, i, m, s, u और y का क्या मतलब है?
g (ग्लोबल) पहले मैच पर रुकने के बजाय हर मैच खोजता है। i (इग्नोर केस) पैटर्न को केस-असंवेदनशील बना देता है। m (मल्टीलाइन) ^ और $ को पूरी स्ट्रिंग के बजाय हर पंक्ति के आरंभ और अंत से मैच कराता है। s (dotAll) . को न्यूलाइन वर्णों से भी मैच करने देता है। u (यूनिकोड) पूर्ण यूनिकोड हैंडलिंग सक्षम करता है, जिसमें \p{…} प्रॉपर्टी एस्केप और सही surrogate-pair मैचिंग शामिल हैं। y (स्टिकी) हर मैच को ठीक पिछले मैच के बाद वाली स्थिति (lastIndex) पर एंकर करता है। आप इनमें से किन्हीं को भी जोड़ सकते हैं — g या y चालू होने पर यह टेस्टर सभी मैच दिखाता है, अन्यथा केवल पहला मैच, ठीक वैसे ही जैसे RegExp.prototype.exec वास्तव में व्यवहार करता है।
कैप्चर ग्रुप और नामित ग्रुप कैसे काम करते हैं?
कोष्ठक ( ) एक नंबर वाला कैप्चर ग्रुप बनाते हैं; हर ग्रुप ने जो टेक्स्ट मैच किया वह हर परिणाम के नीचे Group 1, Group 2 इत्यादि के रूप में उसी क्रम में दिखाया जाता है जिस क्रम में खुलने वाले कोष्ठक आते हैं। किसी ग्रुप को नाम देने के लिए (?<year>\d{4}) का उपयोग करें — नामित ग्रुप परिणामों में नाम से दिखते हैं और किसी प्रतिस्थापन में $<year> के रूप में संदर्भित किए जा सकते हैं। एक non-capturing ग्रुप (?:…) पैटर्न के किसी हिस्से को किसी क्वांटिफ़ायर या alternation के लिए बिना नंबर वाला कैप्चर बनाए समूहित करता है, जिससे आपके ग्रुप नंबर साफ़ रहते हैं और यह थोड़ा तेज़ भी होता है।
मैं रिप्लेस सुविधा का उपयोग कैसे करूँ?
"रिप्लेस दिखाएँ" चालू करें और एक प्रतिस्थापन स्ट्रिंग टाइप करें। नंबर वाले कैप्चर ग्रुप डालने के लिए $1, $2 …, नामित ग्रुप के लिए $<name>, पूरे मैच के लिए $&, और एक शाब्दिक डॉलर चिह्न के लिए $$ का उपयोग करें। उदाहरण के लिए, पैटर्न (\w+)\s(\w+) के साथ प्रतिस्थापन $2 $1 दो शब्दों को आपस में बदल देता है। प्रतिस्थापन आपके फ्लैग का सम्मान करता है: g फ्लैग के बिना केवल पहला मैच बदला जाता है। आउटपुट String.prototype.replace से गणना किया जाता है, इसलिए यह आपके कोड से बिलकुल मेल खाता है।
मेरा रेगेक्स "Catastrophic backtracking" क्यों दिखा रहा है या धीमा क्यों चल रहा है?
ओवरलैप करते टेक्स्ट पर नेस्टेड क्वांटिफ़ायर वाले पैटर्न — क्लासिक रूप से (a+)+, (.*)*, या किसी लंबी न-मैच-होने वाली स्ट्रिंग के विरुद्ध (\w+\s?)+ — इंजन को घातांकीय (exponential) संख्या में रास्ते आज़माने पर मजबूर कर सकते हैं, जिससे टैब जम जाता है। इसे catastrophic backtracking कहते हैं और यह प्रोडक्शन में एक वास्तविक denial-of-service जोखिम (ReDoS) है। इसे ठीक करें: पैटर्न को एंकर करें, नेस्टेड ग्रुप को एक ही कैरेक्टर क्लास से बदलें (जैसे (\w+\s?)+ के बजाय [\w\s]+), या सीमाएँ जोड़ें ताकि इंजन जल्दी विफल हो सके। यह टेस्टर उत्तरदायी बने रहने के लिए पुनरावृत्ति (iteration) की सीमा तय करता है, पर जो पैटर्न यहाँ धीमा है वह आपके ऐप में भी धीमा रहेगा।
क्या मेरा पैटर्न या टेस्ट टेक्स्ट कहीं अपलोड होता है?
नहीं। सब कुछ मूल RegExp इंजन का उपयोग करते हुए आपके ब्राउज़र में स्थानीय रूप से चलता है — आपका पैटर्न, फ्लैग और टेस्ट स्ट्रिंग कभी पेज से बाहर नहीं जाते और कुछ भी किसी सर्वर पर नहीं भेजा जाता और न ही संग्रहित होता है। आप इंटरनेट से डिस्कनेक्ट कर सकते हैं और टेस्टर फिर भी काम करता रहेगा। इससे किसी पैटर्न को बनाते समय लॉग लाइनें, नमूना डेटा या कोई संवेदनशील चीज़ पेस्ट करना सुरक्षित रहता है।