PostalAddress

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

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

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

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

जेएसओएन के काेड में दिखाना
{
  "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 कोड. इसका कभी भी अनुमान नहीं लगाया जा सकता और यह पक्का करना उपयोगकर्ता की ज़िम्मेदारी है कि वैल्यू सही हो. जानकारी के लिए http://cldr.unicode.org/ और http://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") या सिर्फ़ एक संख्या होती है जो "सेक्टर कोड" (जमैका), "डिलीवरी क्षेत्र इंडिकेटर" (Malawi) या "पोस्ट ऑफ़िस इंडिकेटर" (उदाहरण के लिए, "कोटे डीवर") को दिखाती है.

administrativeArea

string

ज़रूरी नहीं. सबसे बड़ा प्रशासनिक उप-क्षेत्र, जिसका इस्तेमाल किसी देश या इलाके के डाक पतों के लिए किया जाता है. उदाहरण के लिए, यह राज्य, प्रांत, ऑब्लास्ट या प्रीफ़ेक्चर हो सकता है. खास तौर पर, स्पेन के लिए यह प्रांत है और स्वायत्त प्रांत नहीं है (उदाहरण के लिए, "बार्सलोना" न कि "कैटलोनिया"). कई देश, डाक पतों के लिए राज्य का इस्तेमाल नहीं करते हैं. उदाहरण के लिए, स्विट्ज़रलैंड में इसे ऐसे ही छोड़ा जाना चाहिए.

locality

string

ज़रूरी नहीं. आम तौर पर, यह पते के शहर/शहर का हिस्सा होता है. उदाहरण: यूएस सिटी, आईटी कम्यून, यूके पोस्ट टाउन. दुनिया के उन इलाकों के लिए जहां शहर अच्छी तरह से तय नहीं किए गए हैं या इस स्ट्रक्चर में ठीक से फ़िट नहीं होते. साथ ही, शहर को खाली छोड़ें और पतों की लाइन का इस्तेमाल करें.

sublocality

string

ज़रूरी नहीं. पते का उप-क्षेत्र. उदाहरण के लिए, इसके आस-पड़ोस, नगर, ज़िले हो सकते हैं.

addressLines[]

string

किसी पते के लोअर लेवल की जानकारी देने वाली, स्ट्रक्चर नहीं की गई पते की लाइनें.

क्योंकि AddressLine के मानों में टाइप की जानकारी नहीं होती, लेकिन कभी-कभी एक ही फ़ील्ड में एक से ज़्यादा वैल्यू शामिल हो सकती हैं.उदाहरण के लिए, "Austin, TX". इसलिए, यह ज़रूरी है कि लाइन का ऑर्डर साफ़ हो. पता पंक्तियों का क्रम, पते के देश/इलाके के लिए "एन्वेलप ऑर्डर" होना चाहिए. जिन जगहों में यह अलग-अलग हो सकती है (उदाहरण के लिए, जापान में), उन्हें आसानी से समझने के लिए, address_language का इस्तेमाल किया जाता है (उदाहरण के लिए, बड़े से छोटे ऑर्डर के लिए "ja" या छोटे-से-बड़े ऑर्डर के लिए "en". इस तरह, भाषा के आधार पर, पते की सबसे खास लाइन चुनी जा सकती है.

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

ऐसा पता बनाना जिसमें सिर्फ़ AreaCode और addressLines शामिल हों. इसके बाद, जियोकोड करने का सुझाव दिया जाता है. इसके लिए, पूरी तरह से स्ट्रक्चर न किए गए पतों का इस्तेमाल किया जाता है. इसके अलावा, यह अनुमान भी नहीं लगाया जा सकता कि पते का कौनसा हिस्सा शहर या प्रशासनिक इलाके का होना चाहिए.

recipients[]

string

ज़रूरी नहीं. पते पर मौजूद पाने वाला. कुछ मामलों में, इस फ़ील्ड में एक से ज़्यादा लाइन की जानकारी हो सकती है. उदाहरण के लिए, इसमें "केयर ऑफ़" जानकारी हो सकती है.

organization

string

ज़रूरी नहीं. पते पर संगठन का नाम.