क्या JSON सिंटैक्स किसी ऑब्जेक्ट में डुप्लिकेट कुंजियों की अनुमति देता है?

Question

क्या यह वैध जसन है?

{
    "a" : "x",
    "a" : "y"
}

http://jsonlint.com/ हाँ कहता है।

http://www.json.org/ इसे मना करने के बारे में कुछ नहीं कहता है।

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

Comments

अगर आप एकDictionary<string, string>

— सैम लीच

यदि कोई व्यक्ति JSON स्ट्रिंग्स में डुप्लिकेट मानों को खोजने के लिए एक समाधान की उम्मीद में यहां पहुंचता है, तो मुफ्त ऑनलाइन जॉन्स सत्यापनकर्ता

— पेपिज ओलिवियर

jsonlint.com हाँ कहता है। यह नहीं है, यह सभी लेकिन अंतिम कुंजी-मूल्य जोड़ी को निकालता है और फिर इसे मान्य करता है, जो इसे वैध बनाता है

— टिम

फिर मानक टूट गया है

— ब्रैड थॉमस

मैंने एक टिप्पणीकार के रूप में "-" नाम का उपयोग किया है और टिप्पणी के रूप में मान एक एकल पंक्ति है। इसलिए मुझे उम्मीद है कि कोई भी पार्सर इसकी शिकायत नहीं करेगा।

— लोथर

Answer 1

से मानक (पी ii।) :

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

आगे मानक (पृष्ठ 2) में नीचे, JSON ऑब्जेक्ट के लिए विनिर्देशन:

एक ऑब्जेक्ट संरचना को शून्य या अधिक नाम / मूल्य जोड़े के आसपास घुंघराले ब्रैकेट टोकन की एक जोड़ी के रूप में दर्शाया गया है। एक नाम एक स्ट्रिंग है। एक एकल कोलन टोकन प्रत्येक नाम का अनुसरण करता है, नाम को मूल्य से अलग करता है। एक एकल अल्पविराम टोकन निम्न नाम से एक मान को अलग करता है।

यह डुप्लिकेट कुंजियों के अमान्य या वैध होने का कोई उल्लेख नहीं करता है, इसलिए विनिर्देश के अनुसार मैं सुरक्षित रूप से यह मानूंगा कि उन्हें अनुमति है।

JSON पुस्तकालयों के अधिकांश कार्यान्वयन डुप्लिकेट कुंजियों को स्वीकार नहीं करते हैं, पहले उद्धरण के कारण मानक के साथ संघर्ष नहीं करते हैं।

यहाँ C ++ मानक पुस्तकालय से संबंधित दो उदाहरण दिए गए हैं। जब std::mapयह कुछ JSON ऑब्जेक्ट को डीरियलाइज़ करता है तो डुप्लिकेट कीज़ को मना करने का कोई मतलब होगा। लेकिन जब std::multimapयह कुछ JSON ऑब्जेक्ट को डीरियलाइज़ करता है तो डुप्लिकेट कीज़ को सामान्य रूप से स्वीकार करने का कोई मतलब होगा।

Comments

मुझे लगता है कि मैं इसे एक उत्तर के रूप में स्वीकार कर सकता हूं, हालांकि मुझे @PatrickGoley का उल्लेख पसंद है कि json.org पर इसे कुंजी / मूल्य-जोड़े का एक सेट कहा जाता है जो विशिष्टता का अर्थ है जो कि मान्य नहीं है।

— क्लैंप

@clamp json.org मानक नहीं है और, जहां तक ​​मैं बता सकता हूं, एम्का इंटरनेशनल द्वारा नहीं चलाया गया है। json.org गुमनाम रूप से प्रस्तुत किया गया लगता है। यह वह जगह है विनिर्देश: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf क्या यह json.org पर कहते हैं प्रासंगिक नहीं है।

— टिमोथी शील्ड

@clamp std::multimapउदाहरण मैं सिर्फ जोड़ा पर विचार करें । इसे संभावित डुप्लिकेट कुंजियों के साथ JSON ऑब्जेक्ट के रूप में क्रमबद्ध किया जा सकता है।

— तीमुथियुस

@ क्लैंप कुंजी / मान जोड़े का एक सेट होने के नाते डुप्लिकेट नामों को शामिल नहीं करता है। {"a":1,"a":2}दो अलग-अलग कुंजी / मूल्य जोड़े का एक सेट है। वास्तव में, यहां तक {"a":1,"a":1}कि कुंजी / मूल्य जोड़े के एक सेट के रूप में सोचा जा सकता है जो केवल एक तत्व होता है। तथ्य यह है कि यह दोहराया जाता है सिर्फ एक सिंटैक्टिक क्विक के रूप में सोचा जा सकता है। एक बेहतर परिभाषा यह होगी, "एक वस्तु तार (नाम) से मूल्यों तक एक आंशिक कार्य है।"

— मार्सेलो कैंटोस

@TimothyShields और उस मानक को जो आपने कहा है, "JSON सिंटैक्स नाम के रूप में उपयोग किए गए स्ट्रिंग्स पर कोई प्रतिबंध नहीं लगाता है, इसके लिए नाम स्ट्रिंग्स अद्वितीय होने की आवश्यकता नहीं है, और नाम / मान जोड़े के क्रम के लिए कोई महत्व नहीं देता है"

— चार्ल्स

Answer 2

संक्षिप्त उत्तर: हां, लेकिन अनुशंसित नहीं है।
लंबा जवाब: यह इस बात पर निर्भर करता है कि आप वैध क्या कहते हैं ...

ECMA-404 "JSON डेटा इंटरचेंज सिंटैक्स" डुप्लिकेट किए गए नामों (कुंजियों) के बारे में कुछ नहीं कहता है।

हालाँकि, RFC 8259 "जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON) डेटा इंटरचेंज फॉर्मेट" कहता है:

किसी वस्तु के नाम अद्वितीय होने चाहिए।

इस सन्दर्भ में SHOULD को BCP 14 में निर्दिष्ट समझा जाना चाहिए :

चाहिए यह शब्द, या विशेषण "सुझाए गए", इसका मतलब यह है कि वहाँ विशेष परिस्थितियों में वैध कारण मौजूद हो सकता है किसी विशेष आइटम की अनदेखी करने के लिए, लेकिन पूर्ण निहितार्थ समझा जाना चाहिए और ध्यान से एक अलग पाठ्यक्रम चुनने से पहले तौला।

RFC 8259 बताते हैं कि अद्वितीय नाम (कुंजियाँ) अच्छे क्यों हैं:

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

---

साथ ही, जैसा कि सेरगई ने टिप्पणियों में बताया: ECMA-262 "ECMAScript® भाषा विनिर्देश", पढ़ता है:

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

दूसरे शब्दों में, अंतिम-मूल्य-जीत।

---

डगलस क्रॉकफोर्ड (JSON के निर्माता) द्वारा जावा कार्यान्वयन के साथ डुप्लिकेट नामों के साथ एक स्ट्रिंग को पार्स करने का प्रयास एक अपवाद में होता है :

org.json.JSONException: Duplicate key "status"  at
org.json.JSONObject.putOnce(JSONObject.java:1076)

Comments

JSON को मान्य जावास्क्रिप्ट माना जाता है, इसलिए यह जांचना प्रासंगिक है कि क्या डुप्लिकेट कुंजी जेएस को शाब्दिक रूप से मान्य है। V8 उन्हें स्वीकार करने लगता है: d8 -e 'x={"a":1,"a":2}; print(x.a);'यह प्रिंट 2.

— बेन क्रॉउल

इसके अलावा ECMA-262 कल्पना JSON.parse()स्पष्ट रूप से कहती है In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten.(दूसरे शब्दों में अंतिम-मूल्य-जीत)।

— सेरगुनी

@BenCrowell: जहां तक ​​मुझे पता है, JSON को मान्य जावास्क्रिप्ट नहीं माना जाता है और ऐसे मामले हैं जहां यह नहीं है, कालातीत repo.com/json-isnt-a-javascript-subset देखें । उस ने कहा, यह निश्चित रूप से जावास्क्रिप्ट से प्रेरित था (यह भी JSON विनिर्देशन में ऐसा कहता है)।

— साइमन टचटेक

यह ध्यान देने योग्य है कि जावास्क्रिप्ट "सख्त मोड" का उपयोग करते समय, यदि दो समान कुंजियाँ हैं तो दूसरी कुंजी-मूल्य जोड़ी का उपयोग करेंगे और पहले को अनदेखा करेंगे। IE11 एक अपवाद फेंक देगा।

— शाहर

Answer 3

JSON प्रारूप को निर्दिष्ट करने वाले 2 दस्तावेज़ हैं:

1. http://json.org/
2. https://tools.ietf.org/html/rfc7159

1 दस्तावेज़ से स्वीकृत उत्तर उद्धरण। मुझे लगता है कि 1 दस्तावेज़ अधिक स्पष्ट है, लेकिन 2 में अधिक विवरण शामिल हैं।

दूसरा दस्तावेज़ कहता है:

4. वस्तुओं

   एक ऑब्जेक्ट संरचना को शून्य या अधिक नाम / मूल्य जोड़े (या सदस्यों) के आसपास घुंघराले ब्रैकेट की एक जोड़ी के रूप में दर्शाया गया है। एक नाम एक स्ट्रिंग है। प्रत्येक नाम के बाद एक एकल बृहदान्त्र आता है, नाम को मूल्य से अलग करता है। एक एकल अल्पविराम निम्नलिखित नाम से एक मान को अलग करता है। किसी ऑब्जेक्ट के नाम अद्वितीय होने चाहिए।

इसलिए इसका डुप्लिकेट नाम रखने की मनाही नहीं है, लेकिन इसे हतोत्साहित किया जाता है।

Answer 4

मैं एक ऐसे ही प्रश्न के बारे में आया जब XML और JSON दोनों को स्वीकार करने वाले API के साथ काम कर रहा था, लेकिन दस्तावेज़ में यह नहीं लिखा है कि यह कैसे हैंडल करेगा कि आप JSON में डुप्लिकेट कुंजियों को स्वीकार करना चाहते हैं।

निम्नलिखित आपके नमूना JSON का एक वैध XML प्रतिनिधित्व है:

<object>
  <a>x</a>
  <a>y</a>
</object>

जब इसे JSON में परिवर्तित किया जाता है, तो आपको निम्नलिखित मिलते हैं:

{
  "object": {
    "a": [
      "x",
      "y"
    ]
  }
}

एक भाषा से एक प्राकृतिक मानचित्रण जो संभालती है कि आप डुप्लिकेट कुंजियों को दूसरे को क्या कह सकते हैं, यहां एक संभावित सर्वोत्तम अभ्यास संदर्भ के रूप में काम कर सकते हैं।

आशा है कि किसी की मदद करता है!

Answer 5

JSON कल्पना यह कहती है:

एक वस्तु नाम / मूल्य जोड़े का एक अनियंत्रित सेट है।

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

इसके अलावा, अधिकांश JSON लिबास, JSON ऑब्जेक्ट्स को हैश मैप्स / डिक्शनरी में डिस्क्रिबलाइज कर देंगे, जहां कुंजियों की अद्वितीय गारंटी दी जाती है। क्या होता है जब आप डुप्लिकेट कुंजियों के साथ JSON ऑब्जेक्ट को डिसेर्बलाइज करते हैं, लाइब्रेरी पर निर्भर करता है: ज्यादातर मामलों में, आपको या तो एक त्रुटि मिलेगी, या प्रत्येक डुप्लिकेट कुंजी के लिए केवल अंतिम मूल्य को ध्यान में रखा जाएगा।

उदाहरण के लिए, पायथन में, json.loads('{"a": 1, "a": 2}')रिटर्न {"a": 2}।

Comments

असंयमित करता है विशिष्ट विशिष्टता? मुझे लगता है कि सेट ऑपरेटिव शब्द है

— पैट्रिक गोले

रंगों का एक अनियोजित संग्रह: नीला, हरा, हरा, नीला, लाल, नीला, हरा - इसमें डुप्लिकेट हैं।

— तीमुथियुस

जो पाठ वाक्यांश आप उद्धृत कर रहे हैं, "एक वस्तु नाम / मूल्य जोड़े का एक अनियंत्रित सेट है," JSON कल्पना में प्रकट नहीं होता है ...

— टिमोथी शील्ड

अब मैं देख रहा हूं कि आप json.org को उद्धृत कर रहे थे। यह आधिकारिक रूप से 'करीब' है, लेकिन यह विनिर्देश नहीं है। पृष्ठ के शीर्ष पर विनिर्देशन का एक लिंक है, जिसे json.org पर दोहराया जाता है। यदि आप कल्पना को खोजते हैं, तो "अनऑर्डर" शब्द प्रकट नहीं होता है, और "सेट" शब्द केवल JSON ऑब्जेक्ट्स से असंबंधित संदर्भों में प्रकट होता है।

— तीमुथियुस

ध्यान दें कि यह " नाम / मूल्य जोड़े का अनियंत्रित सेट" कहता है , जोड़े नाम नहीं। है यही कारण है, { (a,b), (a,c) } है एक अद्वितीय सेट। तो तकनीकी रूप से json.org परिभाषा के तहत {"a":1,"a":2}मान्य है, लेकिन {"a":1,"a":2,"a":1}नहीं है। यह भी ध्यान दें कि ECMA-404 (वास्तविक मानक) शब्द "सेट" का उपयोग करने से बचा जाता है:An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs.

— सेरगनी

Answer 6

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

[
  "div":
  {
    "p":"hello",
    "p":"universe"
  }
  "div":
  {
    "h1":"Heading 1",
    "p":"another paragraph"
  }
]

उदाहरण के लिए HTML को आसानी से पार्स कर सकता है

<body>
 <div>
  <p>hello</p>
  <p>universe</p>
 </div>
 <div>
  <h1>Heading 1</h1>
  <p>another paragraph</p>
 </div>
</body>

मैं सवाल के पीछे तर्क देख सकता हूं लेकिन जैसा कि यह खड़ा है ... मुझे इस पर भरोसा नहीं होगा।

Comments

आपके पहले उदाहरण के सरणी को अल्पविराम याद आ रहा है। इसके अलावा, यह खुद के साथ असंगत है। यदि आप एक शब्दकोश को एक आदेशित संग्रह के रूप में उपयोग करने जा रहे हैं, तो आपका बाहरी सरणी भी केवल एक वस्तु होना चाहिए। यानी, {"div":{"p":"hello","p":"universe"}, "div":{"h1":"Heading 1","p":"another paragraph"}}। अब, बहुत से लोग और चौखटे JSON वस्तुओं को अनियंत्रित शब्दकोशों के रूप में मानते हैं, लेकिन जावास्क्रिप्ट और उदाहरण के लिए MongoDB की एपीआई शब्दकोशों के भीतर कुंजियों के आदेश पर निर्भर करती है, इसलिए आप जो सुझाव दे रहे हैं (शब्दकोशों का आदेश दिया गया) अनसुना नहीं है। आपको बस एक विशेष पार्सर की आवश्यकता होगी।

— बिंकी

Answer 7

उद्देश्य के लिए पूछना, अलग-अलग उत्तर हैं:

JSON का उपयोग ऑब्जेक्ट्स (JavaScriptObjectNotation) को क्रमबद्ध करने के लिए करते हैं, प्रत्येक डिक्शनरी तत्व एक इंडिविजुअल ऑब्जेक्ट प्रॉपर्टी के लिए मैप करते हैं, इसलिए एक ही प्रॉपर्टी के लिए मान को परिभाषित करने वाली विभिन्न प्रविष्टियों का कोई मतलब नहीं है।

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

हमारे JSON नमूनों पर टिप्पणी करने के लिए डुप्लिकेट कुंजियों का उपयोग करें । उदाहरण:

{ "property1" : "value1", "REMARK" : "... prop1 controls ...", "property2" : "value2", "REMARK" : "... value2 raises an exception ...", }

JSON के धारावाहिक जो हम उपयोग कर रहे हैं, इन "REMARK" डुप्लिकेट के साथ कोई समस्या नहीं है और हमारा आवेदन कोड बस इस छोटे से ओवरहेड को अनदेखा करता है।

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

Comments

यह विचार अच्छा नहीं है। डुप्लिकेट कुंजियों को शामिल करके, भले ही आपको उनमें डेटा पढ़ने की आवश्यकता न हो, आप अपरिभाषित व्यवहार पर भरोसा कर रहे हैं। कुछ पार्कर्स, जैसे क्रॉकफोर्ड के JSON-java parser, अपवाद को फेंक देते हैं और डेटा को पार्स करने से इनकार करते हैं।

— रिचर्ड स्मिथ

वास्तव में हमारे वातावरण में पूरी तरह से काम कर रहा है, इसलिए मेरी जरूरतों को पूरा करते हुए, भले ही मैं आपसे सहमत हूं कि यह किसी तरह का है;)

— aknoepfel

@RichardSmith मैं कहूंगा कि पार्सर्स और नए ES स्पेक्स ने व्यवहार को परिभाषित किया है।

— बिंकी जू

Answer 8

पोस्टिंग और उत्तर क्योंकि मानकों के बारे में बहुत सारे पुराने विचार और भ्रम हैं। दिसंबर 2017 तक, दो प्रतिस्पर्धी मानक हैं:

RFC 8259 - https://tools.ietf.org/html/rfc8259

ECMA-404 - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

json.org पता चलता है ECMA-404 है मानक है, लेकिन इस साइट एक अधिकार होने के लिए प्रकट नहीं होता। जबकि मुझे लगता है कि ECMA पर विचार करना उचित है, यहाँ क्या महत्वपूर्ण है, मानकों (अद्वितीय कुंजी के बारे में) के बीच एकमात्र अंतर यह है कि RFC 8259 कहता है कि कुंजी अद्वितीय होनी चाहिए, और ECMA-404 का कहना है कि उन्हें होना आवश्यक नहीं है अद्वितीय।

RFC-8259:

"किसी वस्तु के नाम अद्वितीय होने चाहिए।"

उस तरह के सभी कैप्स में "चाहिए" शब्द का आरएफसी दुनिया के भीतर एक अर्थ है, जिसे विशेष रूप से एक और मानक (बीसीपी 14, आरएफसी 2119 - https://tools.ietf.org/html/rfc2119 ) के रूप में परिभाषित किया गया है ,

3. इस शब्द या विशेषण "तर्क" का अर्थ यह है कि किसी विशेष आइटम को अनदेखा करने के लिए विशेष परिस्थितियों में मान्य कारण मौजूद हो सकते हैं, लेकिन एक अलग पाठ्यक्रम चुनने से पहले पूर्ण निहितार्थों को समझना और ध्यान से तौलना चाहिए।

ECMA-404:

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

तो, कोई फर्क नहीं पड़ता कि आप इसे कैसे स्लाइस करते हैं, यह वाक्यात्मक रूप से वैध JSON है ।

RFC 8259 में अद्वितीय प्रमुख सिफारिश के लिए कारण दिया गया है,

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

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

Comments

json.org वास्तव में ECMA मानकीकरण से पहले है। मेरा मानना ​​है कि यह वास्तव में क्रॉकफोर्ड द्वारा स्वयं सेटअप किया गया था (यही वजह है कि इसमें उनकी पुस्तक के लिए एक बेशर्म प्लग है)। उस समय यह JSON के लिए प्राधिकरण था।

— अधिकतम

Answer 9

यह ECMA JSON मानक में परिभाषित नहीं है । और आम तौर पर, एक मानक अर्थ में परिभाषा की कमी, "हर जगह इसी तरह काम करने पर भरोसा मत करो।"

यदि आप एक जुआरी हैं, तो "कई" JSON इंजन दोहराव की अनुमति देंगे और बस अंतिम-निर्दिष्ट मान का उपयोग करेंगे। यह:

var o = {"a": 1, "b": 2, "a": 3}

यह बन जाता है:

Object {a: 3, b: 2}

लेकिन अगर आप एक जुआरी नहीं हैं, तो उस पर भरोसा मत करो!

Answer 10

मानक यह कहता है:

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

बग नोड में है। कम से कम। यह कोड node.js. में सफल होता है

try {
     var json = {"name":"n","name":"v"};
     console.log(json); // outputs { name: 'v' }
} catch (e) {
     console.log(e);
}

Comments

यह एक बग नहीं है, और आपके द्वारा उद्धृत अनुभाग बताता है कि यह क्यों नहीं है: विभिन्न भाषाएं अलग-अलग व्यवहार करती हैं, और JSON पार्सर वही करेगा जो उस भाषा के लिए सबसे स्वाभाविक है। किसी भी स्थिति में, यह उत्तर कुछ भी नहीं जोड़ता है जो user454322 ने पहले ही ऊपर नहीं कहा है।

— रिचर्ड स्मिथ

Answer 11

RFC-7159 के अनुसार, इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) द्वारा प्रकाशित JSON के लिए मौजूदा मानक में कहा गया है, "किसी वस्तु के नाम अद्वितीय होने चाहिए"। हालांकि, RFC-2119 के अनुसार जो IETF दस्तावेजों में प्रयुक्त शब्दावली को परिभाषित करता है, शब्द "वास्तव में" का अर्थ है "... किसी विशेष आइटम की अनदेखी करने के लिए विशेष परिस्थितियों में वैध कारण मौजूद हो सकते हैं, लेकिन पूर्ण निहितार्थ को समझना चाहिए और एक अलग कोर्स चुनने से पहले सावधानी से तौला गया। ” अनिवार्य रूप से इसका मतलब यह है कि अद्वितीय कुंजी होने की सिफारिश की जाती है, लेकिन यह जरूरी नहीं है। हमारे पास JSON ऑब्जेक्ट में डुप्लिकेट कुंजियाँ हो सकती हैं, और यह अभी भी मान्य होगा।

व्यावहारिक अनुप्रयोग से, मैंने देखा है कि JSON में डुप्लिकेट कुंजियाँ मिलने पर अंतिम कुंजी से मान पर विचार किया जाता है।

Answer 12

C # में यदि आप इसके लिए डिसरिसेलाइज़ करते हैं Dictionary<string, string>तो अंतिम कुंजी मान युग्म लेता है:

string json = @"{""a"": ""x"", ""a"": ""y""}";
var d = JsonConvert.DeserializeObject<Dictionary<string, string>>(json);
// { "a" : "y" }

यदि आप deserialise करने की कोशिश करते हैं

class Foo
{
    [JsonProperty("a")]
    public string Bar { get; set; }

    [JsonProperty("a")]
    public string Baz { get; set; }
}

var f = JsonConvert.DeserializeObject<Foo>(json);

आपको एक Newtonsoft.Json.JsonSerializationExceptionअपवाद मिलता है।

Comments

मुझे लगता है कि सबसे अधिक (यदि सभी नहीं) कार्यान्वयन करते हैं, लेकिन यह मेरे सवाल का जवाब नहीं देता है यदि यह JSON के विनिर्देशन के रूप में मान्य है।

— क्लैंप

@svidgen: यह Microsoft का कार्यान्वयन भी नहीं है ... यह एक तृतीय-पक्ष लाइब्रेरी है।

— BoltClock

@BoltClock आह, टौच।

— 13