ISO देश कोड के तीन रूप — कौन सा स्टोर करें और क्यों

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

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

देश कोड के तीन रूप

देश कोड के अंतरराष्ट्रीय मानक एक ही देशों और क्षेत्रों के समूह के लिए तीन समानांतर निरूपण तय करते हैं।

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

तीनों एक ही इकाइयों का वर्णन करते हैं। ठीक यही वजह है कि वे मुसीबत बनाते हैं — अर्थ में वे एक दूसरे के बदले चल सकते हैं, और मान की तुलना में बिल्कुल नहीं।

कोड मिलाने से जॉइन चुपचाप क्यों टूट जाते हैं

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

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

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

क्या उपप्रभाग कोड स्थानीय एजेंसियों वाले कोड जैसे हैं?

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

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

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

क्या कभी अपने कोड बनाने चाहिए?

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

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

पुराने या अज्ञात कोड कहां से आते हैं?

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

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

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

डेवलपर्स के लिए: संग्रह, सूची और फ़ॉलबैक

संग्रह के लिए एक मानक रूप चुनें — ज़्यादातर एप्लिकेशन के लिए दो अक्षरों वाला कोड — और अपनी प्रणाली के भीतर उस पर सख़्ती बरतें। रूपांतरण को एक ही सहायक फ़ंक्शन में रखें ताकि मन बदलने पर बदलाव एक ही जगह हो।

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

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

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

आगे के कदम

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