चेक अंक रहित नंबर: केवल प्रारूप और असत्यापनीय मान

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

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

किन नंबरों का कोई प्रकाशित चेक अंक नहीं होता?

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

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

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

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

कुछ पहचानकर्ताओं की जांच अंकगणित से क्यों नहीं हो सकती

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

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

बाकी का कुछ हिस्सा निजता समझाती है। प्रकाशित चेक नियम एक सार्वजनिक तथ्य है और किसी व्यक्ति के बारे में कुछ नहीं खोलता, इसलिए इस कारण वह शायद ही रोका जाता है — पर उसके आसपास का प्रारूप कभी-कभी रोका जाता है, और जिस योजना का प्रारूप ही प्रकाशित न हो, उसका कोई प्रकाशित चेक भी नहीं होता।

नतीजा यह है कि कवरेज में असली विविधता दिखती है। वही विविधता देश अनुसार तस्वीर का विषय है, जहां हर आकार के रजिस्टरों में वही तीन स्तर बार-बार लौटते हैं।

केवल प्रारूप का मतलब वास्तव में क्या है?

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

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

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

केवल प्रारूप वाले नंबर की जांच कैसे करनी चाहिए?

जितना दस्तावेज़ समर्थन देता है उतना जांचें, और वहीं रुक जाएं।

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

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

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

प्रारूप जांच कहां अपनी जगह बनाती है

प्रारूप जांच सस्ती है, और वह ठीक उन्हीं गलतियों को पकड़ती है जो असली ट्रैफ़िक पर छाई रहती हैं: कॉपी करते समय छूटा कोई अक्षर, गलत कॉलम से चिपकाया गया कोई मान, किसी अंकीय फ़ील्ड में चिपकाई गई वर्णमाला वाली स्ट्रिंग। इन विफलताओं के सामने आकृति की जांच उत्पादन में इस्तेमाल के एक दिन के भीतर अपना खर्च निकाल लेती है।

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

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

डेवलपर के लिए: चार नतीजे और उनके शब्द

इस विचार को एक प्रकार दें, और हर शाखा को उसके अपने शब्द दें।

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

आगे के कदम

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