ब्राज़ील के कर पहचानकर्ता दो आकारों में आते हैं, और किसी भी सत्यापन का पहला कदम उन दोनों को पहचानना है। CPF किसी प्राकृतिक व्यक्ति की पहचान करता है; CNPJ किसी कानूनी इकाई की। दोनों एक के बजाय दो चेक अंकों से बंद होते हैं, जिससे थोड़ा महत्वाकांक्षी अंकगणित टाइप की गलतियों की कहीं चौड़ी श्रेणी पकड़ लेता है।
यह जोड़ी अध्ययन के लिए अच्छा उदाहरण है, क्योंकि ये नंबर इतने छोटे हैं कि हाथ से जांचे जा सकें, इतने पुराने हैं कि उनके नियम हर जगह सार्वजनिक हैं, और एक दूसरे से इतने अलग हैं कि कोई लापरवाह रूटीन इनमें से कम से कम एक को ज़रूर गलत करेगा। यहां बताया गया है कि दोनों कैसे बने हैं और एक सत्यापनकर्ता उनके बारे में ईमानदारी से क्या कह सकता है।
CPF और CNPJ क्या हैं?
CPF व्यक्तिगत करदाता पंजीकरण है, वही नंबर जो किसी नागरिक से बैंक काउंटर, होटल के डेस्क या ऑनलाइन चेकआउट पर मांगा जाता है। CNPJ कॉर्पोरेट करदाता पंजीकरण है, वह नंबर जो किसी कंपनी द्वारा जारी हर बिल और हर बिज़नेस कार्ड पर छपा मिलता है। एक किसी व्यक्ति का है, दूसरा किसी संस्था का, और इनके पीछे चलने वाले रजिस्टर अलग हैं।
चूंकि दोनों की भूमिकाएं समानांतर हैं, इसलिए इनकी चर्चा अक्सर साथ होती है और इम्प्लीमेंटेशन भी साथ होता है, और यह साझा शब्दावली इस तथ्य को छिपा देती है कि दोनों का भीतरी ढांचा एक जैसा नहीं है। जो डेवलपर एक के बारे में पढ़कर मान लेता है कि दूसरा भी वैसे ही काम करता है, वह ऐसा रूटीन बनाएगा जो आधे मामलों में सही मानों को भी ठुकरा देगा।
इस लेख में दिखाई गई स्ट्रिंग केवल काल्पनिक उदाहरण हैं, जो इस बात को दिखाने के लिए बनाई गई हैं कि दोनों नंबर कैसे व्यवहार करते हैं। यहां किसी व्यक्ति या कंपनी का कोई वास्तविक पंजीकरण न दोहराया गया है और न उसका रूप बदला गया है, और किसी उदाहरण का चेक पास कर जाना किसी के बारे में कुछ भी नहीं बताता।
दोनों नंबरों के ढांचे में अंतर
सबसे साफ अंतर यह है कि कानूनी इकाई वाला नंबर दोनों में लंबा है, जो बड़े रजिस्टर और उसके भीतरी उपविभाजनों का नतीजा है। व्यक्ति वाला नंबर अधिक संक्षिप्त रूप है, जो बिना किसी शाखा वाले एक अकेले व्यक्ति के लिए नापा गया है।
ढांचे का अंतर लंबाई से ज़्यादा मायने रखता है। कानूनी इकाई का प्रारूप ऐसे हिस्सों से जुड़ा है जो कंपनी के पंजीकरण को एक से ज़्यादा स्तरों पर पहचानते हैं, इसलिए उसके भीतरी फ़ील्ड अंकों का एक समरूप ब्लॉक नहीं हैं। व्यक्ति का प्रारूप मूल रूप से सपाट है: एक क्रमिक भाग, एक क्षेत्र चिह्न और दो चेक अंक।
किसी भी प्रारूप का वर्णन उसके ठीक स्थान गिनकर नहीं करना चाहिए। प्रकाशित नियम ही सच्चाई का स्रोत हैं, और किसी पेज पर उतारी गई तालिका जल्दी पुरानी पड़ जाती है। ढांचे को उस डेटा की तरह देखें जिसे कोड पढ़ता है, उस ज्ञान की तरह नहीं जो तीन फ़ाइलों की टिप्पणियों में बिखरा रह जाता है।
चेक अंक का विचार: भारित जोड़, फिर मॉड्यूलस
दोनों प्रारूप अपने अंतिम अंक अंकगणित के एक ही परिवार से निकालते हैं, और वह प्रक्रिया दो बार चलती है। आखिरी दोनों स्थानों में से हर एक अपने पहले के अंकों से निकाला जाता है: हर अंक को उसकी जगह पर निर्भर वेट से गुणा करें, गुणनफल जोड़ें, जोड़ को मॉड्यूलस से भाग दें, और शेष को प्रकाशित मैपिंग के ज़रिए चेक अंक में बदल दें।
दूसरा अंक पहले के बाद निकाला जाता है, और उसकी गणना में पहला अंक भी एक इनपुट होता है। यही शृंखला वह वजह है कि दोनों को स्वतंत्र रूप से सत्यापित नहीं किया जा सकता: दूसरे अंक की गणना बदलकर पहले को शामिल न करना ऐसे मान बनाता है जो अलग-अलग देखने पर सही लगते हैं और मिलाकर विफल हो जाते हैं।
यह परिवार वही मॉड्यूलस आधारित परिवार है जिसका सर्वेक्षण चेक अंक एल्गोरिदम वाले लेख में किया गया है, और मैपिंग का चरण ही वह जगह है जहां सतही इम्प्लीमेंटेशन भटक जाते हैं। जब भाग देने से ऐसा शेष बचता है जो सीधे एक अंक में न बदले, तब प्रकाशित नियम बताता है कि उसका क्या करना है, और वह चरण छोड़ने वाला रूटीन इनपुट के एक छोटे पर दोहराए जाने योग्य हिस्से पर मानक से असहमत हो जाएगा।
सब एक जैसे अंकों वाले क्रम क्यों बाहर रखे जाते हैं?
दोहराए गए अंक किसी भी मॉड्यूलस जांच के सामने सबसे पुराने प्रति-उदाहरण हैं। एक ही अक्षर को दोहराकर बनी स्ट्रिंग साधारण अंकगणित को हरा देती है, क्योंकि वेट और दोहराए गए मान इस तरह मिलते हैं कि कुल जोड़ अपरिवर्तित रहता है और चेक अंक मेल खाता हुआ निकल आता है। इसीलिए प्रकाशित नियम ऐसी स्ट्रिंग को सीधे बाहर रख देते हैं, अंकगणित के भरोसे नहीं छोड़ते।
यह बहिष्करण एल्गोरिदम की कोई कमज़ोरी नहीं है; यह इस बात का जानबूझकर किया गया कथन है कि उस आकार का पंजीकरण नंबर कभी जारी नहीं किया जाएगा। जो सत्यापनकर्ता अंकगणित लागू करता है पर यह बहिष्करण छोड़ देता है, वह ऐसा मान स्वीकार कर लेगा जो रजिस्टर स्वयं कभी नहीं बनाता, और यही वह छेद है जिससे फ़ॉर्म में डाला गया नकली पाठ आराम से पार निकल जाता है।
यही तर्क सामान्य करने लायक है। जब भी कोई स्कीम कोई अपवाद तय करती है, वह अपवाद नियम का हिस्सा होता है, कोई वैकल्पिक जोड़ नहीं, और उसे लागू करने की जगह अंकगणित के ठीक बगल में है, कॉलर के पास नहीं।
प्रारूप जांच और रजिस्टर की स्थिति दो अलग बातें हैं
पास हुआ चेक इसका अर्थ रखता है कि दोनों अंतिम अंक भाग से सहमत हैं, इससे ज़्यादा कुछ नहीं। वह नंबर कभी जारी हुआ या नहीं, वह अब भी सक्रिय है या नहीं, वह उसी व्यक्ति का है जो उसे टाइप कर रहा है या नहीं — यह सब कर अधिकारी के रजिस्टर में रहता है, जिसे कोई ऑफ़लाइन रूटीन देख ही नहीं सकता।
यह रजिस्टर ऐसी चीज़ भी है जिससे आसानी से नहीं पूछा जाना चाहिए। किसी का कर-संबंधी दर्जा पूछना और किसी स्ट्रिंग का ढांचा जांचना दो अलग गतिविधियां हैं, और पहली के साथ कानूनी तथा निजता से जुड़े ऐसे परिणाम आते हैं जो फ़ॉर्म सत्यापन के साथ कभी नहीं आते। अंकगणित को स्थानीय रूप से रखना और रजिस्टर को एक अलग, जानबूझकर बनाया गया जोड़ मानना इन दोनों चिंताओं को एक दूसरे में रिसने से रोकता है।
त्रुटि संदेश की भाषा को यह अंतर उठाना पड़ता है। जिस उपयोगकर्ता से कहा जाए कि उसका नंबर अवैध है, वह यह मान सकता है कि उसके पंजीकरण में कोई दिक्कत है, जबकि असल में केवल स्ट्रिंग अंकगणित में विफल हुई है। संदेश में यह कहना चाहिए कि अंक आपस में मेल नहीं खाते, और पंजीकरण की स्थिति को उससे बाहर ही रखना चाहिए।
डेवलपर के लिए: सफ़ाई, मास्किंग और त्रुटि संदेश
कुछ आदतें इन दोनों स्कीमों को मुसीबत से बचाए रखती हैं।
- दोनों के लिए एक ही तरह से सामान्यीकरण करें: प्रस्तुति के चिह्न हटाएं, अंक रखें, और याद रखें कि सफ़ाई मरम्मत नहीं है।
- स्कीम का फ़ैसला संदर्भ से करें, अनुमान से नहीं। कॉलर से पूछें कि फ़ील्ड किस तरह के करदाता की अपेक्षा करता है, बजाय इसके कि केवल लंबाई से निष्कर्ष निकाला जाए।
- बताएं कि दो अंकों में से कौन विफल हुआ, या दोनों विफल हुए, क्योंकि विफलता की जगह ही बताती है कि टाइप की गलती कहां बैठी है।
- प्रोडक्शन टेलीमेट्री में पूरा मान कभी लॉग न करें। नतीजा दर्ज करें और एक मास्क किया हुआ रूप।
यही सावधानी उन लोगों पर भी लागू होती है जो नंबर पढ़ते हैं, कोड नहीं। मास्क किया हुआ रूप इतने शुरुआती अक्षर रखता है कि मालिक उसे पहचान सके, और इतने आखिरी अक्षर हटा देता है कि बाकी सबके लिए वह बेकार हो जाए। रजिस्टरों के बीच तुलना की चर्चा उस समय काम आती है जब कोई उत्पाद एक साथ कई क्षेत्राधिकार संभालता है। अगर आपका उत्पाद सीमा पार के खाता पहचानकर्ता भी स्वीकार करता है, तो IBAN संरचना वाला लेख दिखाता है कि एक दूसरी, स्वतंत्र जांच किस तरह एक ही स्ट्रिंग के भीतर सवार रहती है।
आगे के कदम
लिख लें कि आपके उत्पाद के हर फ़ील्ड में इन दोनों में से कौन सी स्कीम रखी जानी है, और फिर अपने रूटीन को ऐसे मान से परखें जिसका भाग वैध हो पर अंतिम अंक न हों। नंबर सत्यापन टूल दिखाएगा कि एक सत्यापनकर्ता को उस नतीजे का वर्णन कैसे करना चाहिए, और देश अनुसार राष्ट्रीय आईडी सत्यापन नियम वाला लेख इस जोड़ी को उन नंबरिंग प्रणालियों के व्यापक संदर्भ में रखता है जो एक दूसरे को ध्यान में रखे बिना बनी थीं।