PostalAddress

• JSON काेड में दिखाना

डाक पते की जानकारी दिखाता है. उदाहरण के लिए, डाक से डिलीवरी करने या पेमेंट के पते के लिए. डाक पते की मदद से, डाक सेवा किसी प्रॉपर्टी, पीओ बॉक्स या ऐसी ही किसी जगह पर सामान डिलीवर कर सकती है. इसका मकसद, भौगोलिक जगहों (सड़कों, शहरों, पहाड़ों) को मॉडल करना नहीं है.

आम तौर पर, प्रोसेस के टाइप के हिसाब से, उपयोगकर्ता के इनपुट या मौजूदा डेटा को इंपोर्ट करके पता बनाया जाएगा.

पते को डालने या उसमें बदलाव करने के बारे में सलाह: - https://github.com/google/libaddressinput जैसे, अंतरराष्ट्रीय स्तर पर काम करने वाले पते के विजेट का इस्तेमाल करें. - उपयोगकर्ताओं को उन देशों के बाहर के फ़ील्ड में इनपुट करने या उनमें बदलाव करने के लिए, यूज़र इंटरफ़ेस (यूआई) एलिमेंट नहीं दिखाए जाने चाहिए जहां उस फ़ील्ड का इस्तेमाल नहीं किया जाता.

इस स्कीमा का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, यह देखें: https://support.google.com/business/answer/6397478.

JSON के काेड में दिखाना
{ "revision": integer, "regionCode": string, "languageCode": string, "postalCode": string, "sortingCode": string, "administrativeArea": string, "locality": string, "sublocality": string, "addressLines": [ string ], "recipients": [ string ], "organization": string }

फ़ील्ड
revision	integer PostalAddress के स्कीमा में किया गया बदलाव. इसे 0 पर सेट करना चाहिए, जो कि सबसे नया बदलाव है. सभी नए बदलाव, पुराने बदलावों के साथ काम करने चाहिए.
regionCode	string ज़रूरी है. पते के देश/इलाके का CLDR कोड. इसकी जानकारी कभी भी अनुमानित नहीं की जाती. यह उपयोगकर्ता की ज़िम्मेदारी है कि वह यह पक्का करे कि वैल्यू सही हो. ज़्यादा जानकारी के लिए, https://cldr.unicode.org/ और https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html देखें. उदाहरण: स्विट्ज़रलैंड के लिए "CH".
languageCode	string ज़रूरी नहीं. इस पते के कॉन्टेंट का BCP-47 भाषा कोड (अगर पता हो). आम तौर पर, यह इनपुट फ़ॉर्म के यूज़र इंटरफ़ेस (यूआई) की भाषा होती है. इसके अलावा, यह पता है कि यह भाषा, पते के देश/इलाके में इस्तेमाल की जाने वाली किसी भाषा या ट्रांसलिटरेट की गई किसी भाषा से मेल खाती है. इससे कुछ देशों में फ़ॉर्मैटिंग पर असर पड़ सकता है. हालांकि, यह डेटा की सटीक जानकारी के लिए ज़रूरी नहीं है. साथ ही, इससे पुष्टि करने या फ़ॉर्मैटिंग से जुड़े अन्य कामों पर कभी असर नहीं पड़ेगा. अगर यह वैल्यू नहीं पता है, तो गलत डिफ़ॉल्ट वैल्यू देने के बजाय, इसे हटा दिया जाना चाहिए. उदाहरण: "zh-Hant", "ja", "ja-Latn", "en".
postalCode	string ज़रूरी नहीं. पते का पिन कोड. सभी देश, पिन कोड का इस्तेमाल नहीं करते या यह ज़रूरी नहीं होता कि पते में पिन कोड शामिल हो. हालांकि, जिन देशों में पिन कोड का इस्तेमाल किया जाता है वहां पते के अन्य हिस्सों की पुष्टि करने के लिए, पिन कोड की पुष्टि भी की जा सकती है. उदाहरण के लिए, अमेरिका में राज्य या पिन कोड की पुष्टि.
sortingCode	string ज़रूरी नहीं. देश के हिसाब से, क्रम से लगाने के लिए अतिरिक्त कोड. ज़्यादातर इलाकों में इसका इस्तेमाल नहीं किया जाता. जहां इसका इस्तेमाल किया जाता है, वहां वैल्यू "CEDEX" जैसी स्ट्रिंग होती है. इसके बाद, वैल्यू के तौर पर कोई संख्या भी हो सकती है. उदाहरण के लिए, "CEDEX 7". इसके अलावा, वैल्यू सिर्फ़ एक संख्या भी हो सकती है. यह संख्या, "सेक्टर कोड" (जमैका), "डिलीवरी एरिया इंडिकेटर" (मलावी) या "पोस्ट ऑफ़िस इंडिकेटर" (कोट डी आइवर) को दिखाती है.
administrativeArea	string ज़रूरी नहीं. किसी देश या इलाके के डाक पते के लिए इस्तेमाल होने वाला सबसे बड़ा एडमिन के तौर पर उपखंड. उदाहरण के लिए, यह कोई राज्य, प्रांत, ओब्लास्ट या प्रीफ़ेक्चर हो सकता है. स्पेन के लिए, यह प्रांत है, न कि ऑटोनोमस कम्यूनिटी (उदाहरण के लिए, "बार्सिलोना", न कि "कैटलोनिया"). कई देश, डाक पते में प्रशासनिक क्षेत्र का इस्तेमाल नहीं करते. उदाहरण के लिए, स्विट्ज़रलैंड में, इस फ़ील्ड को खाली छोड़ा जाना चाहिए.
locality	string ज़रूरी नहीं. आम तौर पर, इसका मतलब पते के शहर या कस्बे से होता है. उदाहरण: अमेरिका का शहर, इटली का कम्यून, यूनाइटेड किंगडम का पोस्ट टाउन. दुनिया के उन इलाकों में जहां स्थानीय जगहों की जानकारी ठीक से नहीं दी गई है या वे इस स्ट्रक्चर में सही से फ़िट नहीं होती हैं, वहां locality को खाली छोड़ें और addressLines का इस्तेमाल करें.
sublocality	string ज़रूरी नहीं. पते की उप-इलाका. उदाहरण के लिए, यह कोई मोहल्ला, नगर या जिला हो सकता है.
addressLines[]	string पते की निचली लाइनों की जानकारी देने वाली, बिना स्ट्रक्चर वाली लाइनें. addressLines में मौजूद वैल्यू के टाइप की जानकारी नहीं होती और कभी-कभी एक फ़ील्ड में कई वैल्यू हो सकती हैं. उदाहरण के लिए, "ऑस्टिन, टेक्सास". इसलिए, यह ज़रूरी है कि लाइन का क्रम साफ़ तौर पर दिखे. पते के देश या इलाके के हिसाब से, पते की लाइन का क्रम "एनवलप का क्रम" होना चाहिए. जिन देशों/इलाकों में भाषा के क्रम में बदलाव हो सकता है (जैसे, जापान), वहां address_language का इस्तेमाल करके भाषा के क्रम को साफ़ तौर पर बताया जाता है. उदाहरण के लिए, बड़े से छोटे क्रम के लिए "ja" और छोटे से बड़े क्रम के लिए "ja-Latn" या "en". इस तरह, भाषा के आधार पर पते की सबसे सटीक लाइन चुनी जा सकती है. पते के स्ट्रक्चर के तौर पर, कम से कम regionCode का इस्तेमाल किया जा सकता है. बाकी जानकारी addressLines में दी जा सकती है. ऐसे पते को जियोकोडिंग के बिना भी फ़ॉर्मैट किया जा सकता है. हालांकि, पते के किसी भी कॉम्पोनेंट के बारे में तब तक कोई सेमेटिक वजह नहीं बताई जा सकती, जब तक कि उसे कम से कम कुछ हद तक हल नहीं कर लिया जाता. पूरी तरह से अनियमित पतों को मैनेज करने के लिए, हमारा सुझाव है कि आप सिर्फ़ regionCode और addressLines वाला पता बनाएं और फिर उसे जियोकोड करें. ऐसा करने पर, आपको यह अनुमान लगाने की ज़रूरत नहीं पड़ेगी कि पते के कौनसे हिस्से इलाके या प्रशासनिक क्षेत्र के हैं.
recipients[]	string ज़रूरी नहीं. पते पर मौजूद व्यक्ति. कुछ मामलों में, इस फ़ील्ड में एक से ज़्यादा लाइन की जानकारी हो सकती है. उदाहरण के लिए, इसमें "किसके पास है" जानकारी शामिल हो सकती है.
organization	string ज़रूरी नहीं. पते पर मौजूद संगठन का नाम.