अमेरिकी पता जनरेटर: वैसे पते जो आपके अपने फ़ॉर्म से गुज़र जाएं

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

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

अमेरिकी पता असल में किन हिस्सों से बनता है?

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

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

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

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

राज्य, संघीय ज़िला और क्षेत्रों में क्या फ़र्क़ है?

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

क्षेत्र वाला हिस्सा ज़्यादा खामोश समस्या है। प्यूर्टो रिको का कोड PR है, गुआम का GU, संयुक्त राज्य वर्जिन आइलैंड्स का VI, अमेरिकन समोआ का AS और उत्तरी मारियाना आइलैंड्स का MP। कुछ शिपिंग और कर प्रणालियां इन्हें घरेलू गंतव्य मानती हैं और कुछ अंतरराष्ट्रीय, यानी वह फ़ॉर्म जो देश के फ़ील्ड में केवल US स्वीकार करता है और साथ में क्षेत्र का कोड रखता है, ऐसा संयोजन बनाएगा जिसे बाकी सिस्टम ठुकरा देगा।

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

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

ZIP कोड, शहर और राज्य एक साथ क्यों चलने चाहिए?

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

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

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

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

अमेरिकी पता जनरेटर के पीछे कवरेज का असल मतलब क्या है?

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

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

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

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

आपके फ़ॉर्म को कौन सी पता त्रुटियां पकड़नी चाहिए?

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

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

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

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

क्या बनाए गए अमेरिकी पते डिलीवरी योग्य होते हैं?

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

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

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

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

बाद में दोबारा इस्तेमाल के लिए नतीजा कैसे रखें?

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

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

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

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

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

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