नंबर सत्यापन: कैरेक्टर सेट, लंबाई और चेक अंक की तीन परतें

नंबर सत्यापन वह रूटीन है जो तय करता है कि अक्षरों की कोई स्ट्रिंग किसी खाते, दस्तावेज़ या उत्पाद के प्रतिनिधि के रूप में स्वीकार की जा सकती है या नहीं। यह एक जांच नहीं, तीन जांचें हैं, और उनका क्रम तय है: क्या हर अक्षर वैध है, क्या स्ट्रिंग का आकार सही है, और क्या आखिरी अंक अपने पहले के अक्षरों के गणित से मेल खाता है।

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

नंबर सत्यापन क्या है?

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

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

इन दोनों को अलग रखना इस पूरे अभ्यास का उद्देश्य है। जो फ़ॉर्म पास हुई संरचना को प्रमाणित पहचान बताता है, वह बेतुके मान को भी पूरे भरोसे के साथ पार कर देगा, और उपयोगकर्ता उस पर विश्वास कर लेगा।

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

फ़िल्टर की तीन परतें: कैरेक्टर सेट, लंबाई और चेक अंक

तीनों परतें सस्ती हैं, और हर परत उन गलतियों के प्रति अंधी है जो बाकी परतें पकड़ लेती हैं।

क्रम का महत्व सामग्री जितना ही है। पहले सामान्यीकरण करें, फिर कैरेक्टर सेट जांचें, उसके बाद लंबाई, और अंत में गणित चलाएं। जो रूटीन स्पेस हटाने से पहले चेक अंक निकालता है, वह बिल्कुल सही मानों को भी ठुकरा देगा, और ऐसा करेगा उस संदेश के साथ जो उपयोगकर्ता को ऐसी समस्या की ओर भेजता है जो मौजूद ही नहीं है।

प्रारूप पास होने से नंबर असली क्यों नहीं हो जाता?

चेक अंक अपने पहले के अक्षरों का एक गणितीय सार है। यह केवल उन्हीं अक्षरों से बनता है, इसलिए यह आंतरिक सुसंगति साबित करता है और उसके आगे कुछ नहीं। जो भी व्यक्ति सार्वजनिक नियम समझ लेता है, वह ऐसी स्ट्रिंग बना सकता है जो उस नियम को पूरा करे — और जनरेटर ठीक यही काम जानबूझकर करता है।

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

नतीजे को स्ट्रिंग के बारे में कथन मानें, दुनिया के बारे में कभी नहीं। यह ढांचा त्रुटि संदेशों को ईमानदार रखता है और समीक्षकों को हरे निशान से उतना अर्थ निकालने से रोकता है जितना वह उठा ही नहीं सकता।

एक ही नंबर कई स्कीमों का सदस्य हो सकता है

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

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

नॉर्मलाइज़ेशन: स्पेस, हाइफ़न और केस

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

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

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

डेवलपर के लिए: सत्यापन पाइपलाइन कैसे व्यवस्थित करें

पाइपलाइन को शुद्ध चरणों के क्रम के रूप में बनाएं, जहां हर चरण नतीजे के साथ कारण भी लौटाता है, न कि एक ऐसे बूलियन के रूप में जो हर अंतर निगल जाता है।

1. कच्चे इनपुट का सामान्यीकरण करें और सामान्यीकृत रूप को मूल के साथ रखें।
2. कैरेक्टर सेट जांचें और गणित चलने से पहले उसके बाहर का सब कुछ अस्वीकार करें।
3. जिस स्कीम को कॉलर ने चुना है, उसके अनुसार लंबाई जांचें।
4. चेक अंक निकालें और उसकी तुलना करें।
5. ऐसा नतीजा लौटाएं जो विफल चेक को अपरिचित स्कीम से अलग रखता है।

केवल परिणाम नहीं, कारण भी रखें। जो फ़ील्ड केवल यह बताता है कि मान अवैध है, वह उपयोगकर्ता से अनुमान लगवाता है, जबकि जो यह बताता है कि प्रारूप मेल खाया पर आखिरी अक्षर नहीं, वह साफ बताता है कि क्या बदलना है। जहां मान के लिए कोई नियम ही मौजूद न हो, वहां विफलता की भाषा दोहराने के बजाय यह स्पष्ट कहें; चेक अंक एल्गोरिदम की तुलना वाला लेख दिखाता है कि आखिरी परत के पीछे कितनी विविधता बैठी है, और अगर उस फ़ील्ड में कार्ड नंबर रखा जाता है तो कार्ड के अपने नियम Luhn एल्गोरिदम वाले लेख में हैं, यहां नहीं।

अंत में नियमों को डेटा के रूप में रखें। जब कोई स्कीम अपनी लंबाई या अपना गणित बदले, तो अपडेट नियम के विवरण में बदलाव होना चाहिए, उस लॉजिक में नहीं जो उसे पढ़ता है।

आगे के कदम

अपने उत्पाद के किसी एक संख्यात्मक फ़ील्ड को चुनें और लिखें कि उसकी रक्षा फिलहाल तीन में से कौन सी परत कर रही है। फिर ऐसा मान डालें जो प्रारूप पूरा करता हो पर गणित में विफल होता हो, और नंबर सत्यापन टूल में लौटाया गया नतीजा पढ़ें; विफल चेक और अपरिचित स्कीम के बीच का अंतर वही है जिसे ज़्यादातर फ़ॉर्म अब भी धुंधला कर देते हैं।