अंतरराष्ट्रीय पता प्रारूप — पंक्ति क्रम और फ़ील्ड नाम

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

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

पता लिखने की दो दिशाएं

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

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

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

क्या एक ही टेम्पलेट हर देश के लिए चल सकता है?

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

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

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

राज्य, प्रांत और प्रीफ़ेक्चर में क्या अंतर है?

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

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

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

लिपि, लिप्यंतरण और केवल लैटिन वाले फ़ील्ड की चुपचाप विफलता

बहुत से पते लैटिन के अलावा किसी और लिपि में लिखे जाते हैं। कुछ गंतव्य देश घरेलू डिलीवरी के लिए स्थानीय लिपि मांगते हैं और अंतरराष्ट्रीय मार्गनिर्देशन के लिए लिप्यंतरित रूप स्वीकार करते हैं; कुछ आने वाली डाक पर लिप्यंतरित रूप की अपेक्षा करते हैं। कोई भी व्यवस्था सार्वभौमिक नहीं है।

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

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

इमारत के नाम, यूनिट नंबर और ज़िले

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

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

डेवलपर्स के लिए: एक फ़ील्ड, एक अर्थ

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

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

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

अंत में, जोड़ाई से सावधान रहें। यदि किसी एपीआई कॉल के लिए एक पंक्ति का पता बनाते हैं, तो विभाजक को भी प्रदर्शन परिभाषा का हिस्सा बनाएं, क्योंकि हर जगह अल्पविराम से जोड़ने पर ऐसा पता बनता है जो सिर्फ़ उन देशों में ठीक पढ़ा जाता है जहां अल्पविराम का इस्तेमाल होता है।

आगे के कदम

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