रेगुलर एक्सप्रेशन (Regex) शुरुआती गाइड

Step 1. Developer के pattern [A-Z]{2}\d{9}[A-Z]{2} में दो defects हैं, गाइड की गलतियों की सूची की दोनों दिशाओं में एक-एक। यह बहुत ज़्यादा मैच करता है क्योंकि इसमें anchors नहीं हैं: यह हर ऐसा input स्वीकार करता है जिसमें कहीं भी कोई valid number हो, इसलिए XRB123456789SAX, RB123456789SA123 और अंत में space वाला RB123456789SA सब पास हो जाते हैं। यह बहुत कम मैच करता है क्योंकि i flag के बिना [A-Z] rb123456789sa को reject करता है, जिसे FR-21 के अनुसार form को स्वीकार करना चाहिए। सुधारा हुआ pattern: i flag के साथ ^[A-Z]{2}\d{9}[A-Z]{2}$, JavaScript में /^[A-Z]{2}\d{9}[A-Z]{2}$/i; बिना flag ^[A-Za-z]{2}\d{9}[A-Za-z]{2}$ इसके बराबर है। दूसरा defect रिपोर्ट करने से पहले एक सावधानी: अगर form इस check से पहले input को upper case में बदल देता है, तो lower-case letters पहले ही पास हो जाते हैं। यह developer से पूछने का सवाल है, और test input rb123456789sa दोनों स्थितियों में इसे तय कर देता है।

Step 2. Match होने चाहिए: RB123456789SA, rb123456789sa (case) और CP987654321IN (दूसरा prefix और देश)। Match नहीं होने चाहिए: RB12345678SA (8 digits) और RB1234567890SA (10 digits), दोनों boundary lengths; RB123456789S (अंत में एक ही letter); R1123456789SA (letter की जगह digit); XRB123456789SAX और RB123456789SA123 (extra characters, जिन्हें सिर्फ़ anchors reject करते हैं); अंत में space वाला RB123456789SA (copy-paste के बाद आम); RB-123456789-SA (separators); और खाली input। हर invalid input नियम का ठीक एक हिस्सा तोड़ता है, इसलिए जब उनमें से कोई स्वीकार हो जाए तो आप जानते हैं कि pattern का कौन-सा हिस्सा ग़लत है। हर input का expected result "accepted" या "rejected" है, जैसे किसी भी validation test case में।

Step 3. FR-22 को पूरा करने वाला एक pattern: ^Parcel (?<id>[A-Z]{2}\d{9}[A-Z]{2}): (?<status>accepted|in transit|out for delivery|delivered) (?<date>\d{4}-\d{2}-\d{2}) (?<time>\d{2}:\d{2}) \((?<city>[^()]+)\)$। अहम बातें: status का alternation अपने ग्रुप के अंदर है, इसलिए उसका scope सिर्फ़ status है; ग्रुप के बिना लिखा accepted|in transit|… पूरे pattern को चार विकल्पों में बाँट देता और "in transit" वाले लगभग किसी भी टेक्स्ट से मैच कर जाता। City के आसपास के parentheses मेटाकैरेक्टर हैं, इसलिए लिटरल वाले \( और \) से एस्केप होते हैं। City \w+ नहीं बल्कि [^()]+ है: \w+ "Riyadh" से मैच करता है लेकिन space की वजह से "New Delhi" से नहीं, और जैसा गाइड चेतावनी देती है, page localised हो तो Arabic या Devanagari शहर के नाम से कभी नहीं; negated class, या u flag के साथ [\p{L}\p{M} ]+, दोनों को संभालता है। Anchors ^ और $ check को ऐसी line reject करने देते हैं जिसमें कुछ कम या ज़्यादा हो। पहली example line पर groups हैं: id = RB123456789SA, status = delivered, date = 2026-10-02, time = 14:05, city = Riyadh; दूसरी पर status = out for delivery और city = New Delhi। "delivred" वाली line बिल्कुल मैच नहीं होती, इसलिए check pass रिपोर्ट करने की बजाय fail होता है — ठीक वही जो test को चाहिए: ग़लत value स्वीकार करने वाला ढीला pattern test को तब pass करा देता है जब उसे fail होना चाहिए (false-negative result)। Test में हर group की तुलना expected value से करें, जैसे m.groups.status === "delivered"। Date group \d{4}-\d{2}-\d{2} यहाँ काफ़ी है क्योंकि test value की ही तुलना करता है; गाइड का सख़्त ISO date pattern तभी इस्तेमाल करें जब test का मकसद format ही हो। Automated check में pattern एक ही status line पर चलता है और उसे किसी flag की ज़रूरत नहीं; Regex टेस्टर में पूरे material पर आज़माने के लिए m flag चालू करें, जिसकी वजह step 4 में बताई गई है।

Step 4. Parcel paths पर सिर्फ़ दो 5xx responses ढूँढने वाला pattern: m flag के साथ ^\S+ \S+ /api/v2/parcels(?:/\S*)? 5\d\d \d+ms$, ताकि ^ और $ line boundaries पर मैच करें, और tester में हर match देखने के लिए g flag; JavaScript regex literal में slashes \/ लिखे जाते हैं। बाएँ से दाएँ पढ़ें: timestamp, method, path /api/v2/parcels जिसके बाद वैकल्पिक / और कुछ और non-space characters (/RB123456789SA या /RB123456789SA/events), 5 से शुरू होने वाला status, और duration। यह ठीक दो lines से मैच करता है: 503 वाली GET और 502 वाली POST। अकेला 5\d\d सात में से छह lines पर नौ matches देता है, क्योंकि यह digits कहीं भी ढूँढ लेता है: दो lines में RB123456789SA के अंदर 567, CP512345678IN के अंदर 512 और फिर 567, duration 512ms में फिर 512, EE500000000SA के अंदर 500, और /api/v2/rates पर 500, जो parcel path नहीं है; नौ में से सिर्फ़ 503 और 502 वे responses हैं जो आपको चाहिए। Status के दोनों ओर space, \s5\d\d\s, tracking number और duration के false matches हटा देता है लेकिन rates वाली line रह जाती है; path की शर्त उसे भी हटा देती है। m flag के बिना pattern कुछ भी मैच नहीं करता, क्योंकि तब ^ और $ का मतलब पूरे टेक्स्ट की शुरुआत और अंत होता है। यह वही नियम है जो form में था: context और anchors के बिना regex बहुत ज़्यादा मैच करता है।

Step 5. Product owner या developer के लिए खुले सवाल: form upper case में बदलने से पहले validate करता है या बाद में, और क्या input trim होता है (copy-paste से आया trailing space आम है)? Arabic keyboard पर Arabic-Indic digits में टाइप किए अंक स्वीकार होने चाहिए या convert? JavaScript में \d सिर्फ़ 0–9 से मैच करता है, इसलिए RB١٢٣٤٥٦٧٨٩SA reject होता है। FR-22 की status सूची पूरी है, और जब parcel का अभी कोई city न हो तो line कैसी दिखती है? और हर rejected input पर form कौन-सा error message दिखाता है, ताकि test उसे assert कर सके?

अगर आपके patterns अलग हैं, तो उन्हें Regex टेस्टर में जाँचें। Form pattern को step 2 के हर input पर (या सब पर एक साथ, हर line में एक, m flag के साथ) आज़माने पर वह तीनों valid inputs स्वीकार करे और बाकी सब reject करे। m flag के साथ material पर status-line pattern तीनों status lines को सही group values के साथ मैच करे और ग़लत spelling वाली line जोड़ने पर उसे reject करे, और log pattern ठीक दो log lines highlight करे। अलग लेकिन बराबर pattern ठीक है — \d{2} और [0-9]{2} एक ही हैं — जब तक वह जहाँ validate करता है वहाँ anchored हो, हर लिटरल मेटाकैरेक्टर को एस्केप करे और alternation को ग्रुप के अंदर रखे। इनमें से कोई pattern गाइड के (a+)+ की तरह ऐसे ग्रुप पर दोहराने वाला quantifier नहीं लगाता जिसके अंदर पहले से quantifier हो: quantifier वाला अकेला ग्रुप, (?:/\S*)?, optional है और ज़्यादा से ज़्यादा एक बार चलता है, इसलिए catastrophic backtracking का ख़तरा कम है; पक्का करने के लिए एक लंबा input paste करें। फिर status-line pattern को Regex एक्सप्लेनर में डालें और token-by-token पढ़ें: जो गलती आपको नहीं दिखती उसे ढूँढने का यह एक तेज़ तरीका है।