राष्ट्रीय आईडी लंबाई: हर देश का प्रारूप अलग क्यों होता है

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

यह लेख बताता है कि देशों के बीच पहचान संख्याएं किन-किन तरीकों से अलग होती हैं, एक ही देश समय के साथ अपना प्रारूप क्यों बदल सकता है, और ऐसा सत्यापन रास्ता कैसे बनाया जाए जो दोनों समस्याओं के बीच टिका रहे।

कोई सार्वभौमिक लंबाई क्यों नहीं है

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

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

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

पहचान संख्या के कुल

संख्याओं को देश के बजाय डिज़ाइन के आधार पर बांटना सबसे उपयोगी सोच है, क्योंकि सत्यापन पर पड़ने वाले नतीजे डिज़ाइन से निकलते हैं, नक्शे से नहीं।

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

क्या फ़ील्ड की लंबाई तय होनी चाहिए?

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

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

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

देश प्रारूप बदल दे तो क्या होता है?

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

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

व्यवहार में इसका मतलब दो बातें हैं: सत्यापन नियमों को कालातीत नहीं, तारीख़ के साथ रखिए, और अस्वीकार करने वाला संदेश यह बताए कि मान में गड़बड़ क्या है, यह घोषित करने के बजाय कि व्यक्ति की संख्या मौजूद ही नहीं है। जो फ़ॉर्म किसी वैध धारक पर नकली संख्या होने का इलज़ाम लगाता है, वह सपोर्ट का बोझ बनाता है।

चेक अंक असल में कहां काम आते हैं?

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

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

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

जिस देश को आपने मॉडल नहीं किया उसे कैसे संभालें?

एक ईमानदार विकल्प रास्ता रखिए। जब देश अज्ञात हो, या ज्ञात हो पर मॉडल न किया गया हो, तो अक्षरों और लंबाइयों की चौड़ी रेंज स्वीकार कीजिए, मान के साथ देश भी दर्ज कीजिए, और उस रिकॉर्ड को असत्यापित चिह्नित कीजिए, चुपचाप ठीक मान लेने के बजाय।

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

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

डेवलपर्स के लिए: पहचानकर्ता फ़ील्ड का डिज़ाइन

फ़ील्ड तय करते समय चार फ़ैसले सारा भार उठाते हैं: कॉलम का प्रकार, अधिकतम लंबाई, अक्षर समूह, और यह कि सत्यापन कहां रहेगा। पहले तीन सही कर लीजिए तो चौथा अपने आप सरल हो जाता है।

• प्रकार: बदलती लंबाई वाला टेक्स्ट, हमेशा, और सामान्यीकरण केवल विभाजक हटाने तक सीमित।
• लंबाई: ठीक नाप के बजाय उदार ऊपरी सीमा, ऐसी चुनी गई कि सबसे लंबा ज्ञात राष्ट्रीय प्रारूप भी जगह बचाकर समा जाए।
• अक्षर समूह: वह जो मॉडल किए गए देशों के समूह से बने, यानी व्यवहार में अक्षर और अंक, बिंदु-चिह्न हटाकर सामान्य कर दिए गए।
• सत्यापन: मॉडल किए हर देश के लिए एक शाखा, जो देश के मान पर चुनी जाए, साथ में एक दर्ज किया हुआ विकल्प रास्ता जो मॉडल किए नियम को कभी न लांघे।

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

अगले कदम

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