क्या JSON में टिप्पणियों का उपयोग किया जा सकता है?

Question

क्या मैं JSON फ़ाइल के अंदर टिप्पणियों का उपयोग कर सकता हूं? यदि हां, तो कैसे?

Comments

@StingyJack: उन चीजों की व्याख्या करने के लिए जो स्पष्ट नहीं हो सकती हैं, या जो कुछ भी हो वह टिप्पणियों के साथ कर सकता है। मैं अक्सर डेटा फ़ाइलों में टिप्पणी करता हूं। XML, ini फाइलें, और कई अन्य स्वरूपों में टिप्पणियों के लिए प्रावधान शामिल हैं।

— माइकल बूर

यदि आप, मेरी तरह, सोच //commentsरहे थे कि क्या एक उदात्त पाठ कॉन्फ़िगरेशन फ़ाइल के विशिष्ट उपयोग के मामले के लिए ठीक है, तो इसका उत्तर हां (संस्करण 2 के रूप में) है। उदात्त पाठ इसके बारे में शिकायत नहीं करेगा, कम से कम, जबकि यह {"__comment": ...}कंसोल के बारे में शिकायत करेगा , क्योंकि यह एक अप्रत्याशित क्षेत्र है।

— बहाव

और शायद यही एक कारण है कि TOML बनाया गया था ..

— एलेक्स

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

— सिड

JSON5 टिप्पणियों का समर्थन करता है: stackoverflow.com/a/7901053/108238

— schoetbi

Answer 1

नहीं।

JSON सभी डेटा होना चाहिए, और यदि आप एक टिप्पणी शामिल करते हैं, तो यह डेटा भी होगा।

आपके पास एक निर्दिष्ट डेटा तत्व हो सकता है जिसे "_comment"(या कुछ) कहा जाता है जो JSON डेटा का उपयोग करने वाले ऐप्स द्वारा अनदेखा किया जाएगा।

आप संभवतः JSON बनाने / प्राप्त करने वाली प्रक्रियाओं में टिप्पणी करने से बेहतर होंगे, क्योंकि उन्हें पता होना चाहिए कि JSON डेटा पहले से क्या होगा, या कम से कम इसकी संरचना क्या होगी।

लेकिन अगर आपने तय किया है:

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}

Comments

यह वास्तविक टिप्पणी पर किसी प्रकार के उपसर्ग का भुगतान करने की स्थिति में हो सकता है यदि टिप्पणी नाम का कोई मान्य क्षेत्र है:"__comment":"comment text goes here...",

— रोब फोंसेका-एंसर

BTW, जावा google-gson के लिए json लाइब्रेरी में टिप्पणियों के लिए समर्थन है।

— centic

क्या होगा अगर मैं Accronymऔर Abbrevगुणों पर एक अलग टिप्पणी चाहता हूं ? मैंने पहले भी इस पैटर्न का उपयोग किया है, लेकिन जब से यह मुझे ऐसा करने की अनुमति नहीं देता है, तब तक रुक गया। यह एक हैक है। हो सकता है कि अगर मैं __comment__इसके बजाय एक प्रॉपर्टी के नाम को प्रस्तुत करता हूं । वह "__comment__Abbrev" है, अभी भी एक हैक है, लेकिन मुझे सभी भविष्यवाणियों पर टिप्पणी करने देगा

— जुआन मेंडेस

आप "//" का भी उपयोग कर सकते हैं: यह अधिक मूल दिखता है और अभी भी एक ही माता

— smnbbrv

जब JSON का उपयोग मानव-इच्छित कॉन्फ़िगरेशन फ़ाइलों के लिए किया जाता है, तो उन्हें मानव को बेहतर समझने के लिए एनोटेट किया जाना चाहिए। एनोटेट, ऐसी फ़ाइल अब JSON मान्य नहीं है, लेकिन समाधान हैं। उदाहरण के लिए, Google की GYP # -स्टाइल टिप्पणियों का समर्थन करती है। JSON.Minify आपको अपनी इनपुट फ़ाइल से C / C ++ शैली टिप्पणियों को छोड़ने में मदद करेगा।

— Пет16р Петров

Answer 2

नहीं , फॉर्म की टिप्पणियां //…या /*…*/JSON में अनुमति नहीं है। यह उत्तर इस पर आधारित है:

• http://www.json.org
• RFC 4627 : application/jsonजावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON) के लिए मीडिया प्रकार
• RFC 8259 जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON) डेटा इंटरचेंज फॉर्मेट (सुपर RFC 4627, 7158, 7159)

Comments

यदि आप अपने JSON को टिप्पणियों के साथ एनोटेट करना चाहते हैं (इस प्रकार इसे अमान्य JSON बना रहे हैं), तो पार्स करने या प्रसारित करने से पहले इसे छोटा करें। 2012 में कॉन्फ़िगरेशन फ़ाइलों के संदर्भ में क्रोकफोर्ड ने खुद इस बात को स्वीकार किया।

— टूलबार

@alkuzad: यह औपचारिक व्याकरण की बात आती है, वहाँ कुछ स्पष्ट रूप से कहा गया है कि है कि वे होना चाहिए रहे हैं , की अनुमति नहीं दूसरी तरह के आसपास। उदाहरण के लिए, अपनी पसंद की प्रोग्रामिंग भाषा लें: सिर्फ इसलिए कि कुछ वांछित (लेकिन लापता) सुविधा स्पष्ट रूप से अस्वीकृत नहीं है, इसका मतलब यह नहीं है कि आपका कंपाइलर जादुई रूप से इसे पहचान लेगा।

— stakx - अब

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

— त्रिनको

यद्यपि आपका उत्तर बिल्कुल सही है, यह कहा जाना चाहिए कि यह बी.एस. इतने सारे अंत उपयोगकर्ताओं को जोंस कॉन्फ़िगरेशन की आवश्यकता के साथ आने के बाद, फिर टिप्पणियां अत्यधिक मददगार होती हैं। सिर्फ इसलिए कि कुछ टिन-पन्नी टोपियों ने फैसला किया कि JSON है और हमेशा मशीन पठनीय होनी चाहिए , इस तथ्य को अनदेखा करते हुए कि मनुष्यों को इसे पढ़ने की आवश्यकता है, यह छोटे दिमाग की एक त्रासदी है।

— cmroanirgo

@cmroanirgo: आप स्पष्ट रूप से JSON की उस सीमा के बारे में शिकायत करने वाले पहले व्यक्ति नहीं हैं ... यही कारण है कि हमारे पास पार्सर्स हैं जो चुपचाप टिप्पणियों की अनुमति देते हैं, और अन्य प्रारूप जैसे YAML और JSON5। हालाँकि यह इस तथ्य को नहीं बदलता है कि JSON क्या है। बल्कि, मुझे यह दिलचस्प लगता है कि लोगों ने JSON का उपयोग उन उद्देश्यों के लिए करना शुरू कर दिया जहां यह स्पष्ट रूप से पहली जगह में पर्याप्त नहीं था, प्रश्न में सीमा को देखते हुए। JSON प्रारूप को दोष न दें; अपने आप को इसका उपयोग करने पर जोर देने के लिए दोषी ठहराएं जहां यह विशेष रूप से अच्छा फिट नहीं है।

— stakx - अब

Answer 3

यदि आप चुनते हैं तो टिप्पणियों को शामिल करें; उन्हें पार्स करने या प्रसारित करने से पहले एक मिनिफायर के साथ पट्टी करें।

मैंने अभी JSON.minify () जारी किया है जो JSON के एक ब्लॉक से टिप्पणियों और व्हाट्सएप को निकालता है और इसे JSON को वैध बनाता है जिसे पार्स किया जा सकता है। तो, आप इसका उपयोग कर सकते हैं जैसे:

JSON.parse(JSON.minify(my_str));

जब मैंने इसे जारी किया, तो मुझे इसके विचार से भी असहमत लोगों का भारी समर्थन मिला, इसलिए मैंने फैसला किया कि मैं एक व्यापक ब्लॉग पोस्ट लिखूंगा कि क्यों टिप्पणियाँ JSON में समझ में आती हैं । इसमें JSON के निर्माता की यह उल्लेखनीय टिप्पणी शामिल है:

मान लीजिए कि आप JSON का उपयोग विन्यास फाइल रखने के लिए कर रहे हैं, जिसे आप एनोटेट करना चाहेंगे। आगे बढ़ें और अपनी पसंद की सभी टिप्पणियाँ डालें। फिर इसे अपने JSON पार्सर को सौंपने से पहले JSMin के माध्यम से पाइप करें। - डगलस क्रॉकफोर्ड, 2012

उम्मीद है कि जो JSON.minify () उपयोगी हो सकता है से असहमत होने वालों के लिए उपयोगी है।

Comments

JSON.minify () के साथ मेरी एकमात्र समस्या यह है कि यह वास्तव में बहुत धीमी है। इसलिए मैंने अपना खुद का कार्यान्वयन किया जो समान काम करता है: gist.github.com/1170297 । कुछ बड़ी परीक्षण फ़ाइलों पर आपके कार्यान्वयन में 74 सेकंड और मेरा 0.06 सेकंड का समय लगता है।

— विज्किड

यह बहुत अच्छा होगा यदि आप JSON.minify () के लिए गिथब रेपो को सुझाए गए वैकल्पिक एल्गोरिदम को प्रस्तुत कर सकते हैं, ताकि इसे सभी समर्थित लंग्स पर पोर्ट किया जा सके: github.com/getify/json.minify

— काइल सिम्पसन

@MiniGod मैंने पहले ही इस विषय पर डौग के विचारों को कई बार सुना है। मैंने उन्हें अपने ब्लॉग पोस्ट में बहुत पहले संबोधित किया: blog.getify.com/json-comments

— काइल सिम्पसन

@ MarnenLaibow-Koser अभी भी डेटा स्ट्रीम (या यहां तक ​​कि पैकेट) के उपयोग के लिए टिप्पणियों के लिए मान्य उपयोग हैं: निर्माण समय या स्रोतों जैसे डायग्नोस्टिक्स मेटाडाटा को शामिल करना एक्सएमएल के साथ आम उपयोग है, और जेबी डेटा के लिए पूरी तरह से समझदार भी है। टिप्पणियों के विरूद्ध तर्क उथले हैं, और किसी भी पाठ्य डेटा प्रारूप में टिप्पणियों के लिए अनुमति दी जानी चाहिए, चाहे उनका उद्देश्य किसी भी तरह का उपयोग न हो (कुछ भी सुझाव नहीं है कि JSON का उपयोग कहीं और नहीं किया जा सकता है, fwiw)

— StaxMan

यदि JSON को सार्वभौमिक स्वीकृति प्राप्त करना है (जो कि यह मूल रूप से करता है) तो इसका सार्वभौमिक अनुप्रयोग होना चाहिए। उदाहरण: JSON एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल के रूप में काम कर सकता है। इस एप्लिकेशन को टिप्पणियों की इच्छा होगी।

— अंडामट्टर्स

Answer 4

JSON द्वारा डिज़ाइन द्वारा टिप्पणियां हटा दी गईं।

मैंने JSON से टिप्पणियों को हटा दिया क्योंकि मैंने देखा कि लोग उन्हें पार्सिंग निर्देशों का उपयोग करने के लिए उपयोग कर रहे थे, एक अभ्यास जो अंतर्संचालनीयता को नष्ट कर देता था। मुझे पता है कि टिप्पणियों की कमी कुछ लोगों को दुखी करती है, लेकिन ऐसा नहीं होना चाहिए।

मान लीजिए कि आप JSON का उपयोग विन्यास फाइल रखने के लिए कर रहे हैं, जिसे आप एनोटेट करना चाहेंगे। आगे बढ़ें और अपनी पसंद की सभी टिप्पणियाँ डालें। फिर इसे अपने JSON पार्सर को सौंपने से पहले JSMin के माध्यम से पाइप करें।

स्रोत: जी + पर डगलस क्रॉकफोर्ड द्वारा सार्वजनिक बयान

Comments

मैंने सोचा कि JSON को कहना चाहिए कि XML क्या कहना चाहिए? टिप्पणियाँ पठनीयता के लिए हैं।

— intrepidis

वैसे भी, आप शरारती हो सकते हैं और JSON में पार्सिंग निर्देश जोड़ सकते हैं: {"__directives": {"# n #": "DateTime.Now"}, "मान्य": "# n #"} ... यह YAML जैसा दिखता है। आगे का रास्ता तब है ...

— intrepidis

व्यक्तिगत राय: टिप्पणियों को लंगड़ा नहीं होने देना। मेरे पास एक गैर-मानक JSON पार्सर बनाने के अलावा कोई विकल्प नहीं था जो मेरी कॉन्फिग फाइलों को डिकोड करने के लिए टिप्पणियों की अनदेखी करता है।

— caiosm1005

@ArturCzajka मैं अभी भी इस तथ्य को नापसंद करता हूं कि JSON टिप्पणियों का समर्थन नहीं करता है, लेकिन मैंने INI को एक कोशिश दी और मुझे यह स्वीकार करना चाहिए कि कॉन्फ़िगर फ़ाइलों के लिए JSON पर उनका उपयोग करने के लिए यह बहुत अधिक समझ में आता है। प्रतिक्रिया के लिए धन्यवाद और उम्मीद है कि इस बातचीत को पढ़ते हुए अधिक लोग अपना दिमाग बदल लेंगे। (एक पार्सर बनाना वैसे भी एक अभ्यास का अधिक था :)

— caiosm1005

यही कारण है कि सभी साइकिलों को प्रशिक्षण पहियों की आवश्यकता होती है क्योंकि कुछ लोग साइकिल की सवारी नहीं कर सकते हैं। एक महत्वपूर्ण विशेषता को हटाना क्योंकि बेवकूफ लोग इसका दुरुपयोग करते हैं यह खराब डिजाइन है। एक डेटा प्रारूप को बेवकूफ-प्रूफ होने पर प्रयोज्यता को प्राथमिकता देना चाहिए।

— फिल गोएट्ज़

Answer 5

अस्वीकरण: आपका वारंटी शून्य है

जैसा कि बताया गया है, यह हैक युक्ति के कार्यान्वयन का लाभ उठाता है। सभी JSON पार्सर्स JSON के इस प्रकार को नहीं समझेंगे। विशेष रूप से पार्सर्स को स्ट्रीम करना चोक होगा।

यह एक दिलचस्प जिज्ञासा है, लेकिन आपको वास्तव में किसी भी चीज़ के लिए इसका उपयोग नहीं करना चाहिए । नीचे मूल उत्तर है।

---

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

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

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

यदि हम इस तकनीक को लागू करते हैं, तो आपकी टिप्पणी JSON फाइल इस तरह दिख सकती है:

{
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

  "retry_interval" : "The interval in seconds between retrying failed API calls",
  "retry_interval" : 10,

  "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
  "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",

  "favorite_numbers": "An array containing my all-time favorite numbers",
  "favorite_numbers": [19, 13, 53]
}

उपरोक्त कोड JSON मान्य है । यदि आप इसे पार्स करते हैं, तो आपको इस तरह की एक वस्तु मिलेगी:

{
    "api_host": "hodorhodor.com",
    "retry_interval": 10,
    "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
    "favorite_numbers": [19,13,53]
}

जिसका अर्थ है कि टिप्पणियों का कोई निशान नहीं है, और उनके अजीब दुष्प्रभाव नहीं होंगे।

हैप्पी हैकिंग!

Comments

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

— क्वेंटिन

"सभी कार्यान्वयन इसे एक ही संभालते हैं" - यह साबित करना एक मुश्किल बात है।

— क्वेंटिन

JSON में तत्वों के आदेश की गारंटी नहीं है। इसका मतलब है कि "अंतिम" आइटम बदल सकता है!

— 14:32 पर sep332

यह स्पष्ट रूप से युक्ति का उल्लंघन करता है (टिप्पणियों के ऊपर देखें), ऐसा न करें। ietf.org/rfc/rfc4627.txt?number=4627

— voidlogic

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

— deanWombourne

Answer 6

JSON टिप्पणियों का समर्थन नहीं करता है। यह भी कभी नहीं किया गया था कि कॉन्फ़िगरेशन फ़ाइलों के लिए उपयोग किया जाए जहां टिप्पणियों की आवश्यकता होगी।

Hjson मनुष्यों के लिए एक कॉन्फ़िगरेशन फ़ाइल स्वरूप है। आराम से वाक्य रचना, कम गलतियाँ, अधिक टिप्पणियाँ।

JavaScript, Java, Python, PHP, Rust, Go, Ruby और C # पुस्तकालयों के लिए hjson.org देखें ।

Comments

Upvoted। यह स्पष्ट रूप से एक अच्छा बदलाव है, जो बिना खुले रूढ़िवादी लोग सिर्फ नफरत करना पसंद करेंगे। मुझे उम्मीद है कि आपके कार्यान्वयन को आगे भी जाना जाता है - और शायद मूल से भी अधिक लोकप्रिय हो जाता है;) मुझे उम्मीद है कि किसी को इसे रूबी के साथ भी लागू करना होगा। @adelphus भाषा को अच्छी तरह से परिभाषित किया जाना आपका अपना दृष्टिकोण या राय है। एक रूढ़िवादी "डेवलपर" होने के नाते यदि आप एक हैं तो यह साबित नहीं होता है कि आप बेहतर हैं और आप खुद को सीमित स्थानों में बंद रखने से भी बदतर हो सकते हैं। आसानी से भयानक डेवलपर्स के रूप में लोगों को पहचानने मत जाओ।

— konsolebox

इसके बारे में क्षमा करें, @konsolebox शायद आप अपने "अच्छी तरह से परिभाषित JSON पर पुनर्विचार कर सकते हैं" ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf पढ़ने के बाद यह एक वास्तविक मानक है और अपने "विशेष" संस्करणों को लागू करने वाले देवता हैं विखंडन, भ्रम और बहुत समय बर्बाद होता है। मेस वेब डेवलपर्स को देखो जब कोड लिखने के साथ छोड़ दिया जाता है क्योंकि प्रत्येक ब्राउज़र मानकों के थोड़े अलग संस्करणों को लागू करता है। JSON भाषा सही नहीं हो सकती है, लेकिन विखंडन बदतर है। और हाँ, यह सिर्फ एक राय है और आप इससे सहमत नहीं हैं।

— एडेलफस

मैं आपके गम की प्रशंसा करता हूं, लेकिन आप थोड़े फिर से आविष्कार कर रहे हैं। यदि आप बहुत अधिक लचीलापन और मानवीय पठनीयता चाहते हैं, तो YAML का उपयोग करें (वास्तव में नहीं: stackoverflow.com/questions/450399/… ) या क्युमुडीजनी के साथ छड़ी, अभी तक अस्पष्ट JSON।

— टूलबेयर

मुझे लगता है कि सबसे उपयोगकर्ता के अनुकूल विन्यास प्रारूप अभी भी INI है। यह सीधा है और भारी नहीं है। यह उपयोगकर्ताओं को विन्यास तालाब में अपने पैर की उंगलियों को डुबोने से कम भयभीत करता है।

— मैट

जब भी आपको config के रूप में json की आवश्यकता होती है (जहाँ टिप्पणियों की आवश्यकता होती है) - अपनी फ़ाइल का नाम ".js" के बजाय ".json" करें .. js निश्चित रूप से किसी भी वैध json वस्तु को संभाल सकती है और इसके अतिरिक्त टिप्पणियों को संभाल सकती है .. यही कारण है कि "webpack.config.js" और नहीं "webpack.config.json" (वैसे वेबपैक में भी इसके लिए बहुत अधिक कारण हैं: P)

— jebbie

Answer 7

YAML का उपयोग करने पर विचार करें। यह लगभग JSON (लगभग सभी वैध JSON मान्य YAML है) का एक सुपरसेट है और यह टिप्पणियों की अनुमति देता है।

Comments

@ g33kz0r सही है, इसलिए JSON के निकट सुपरसेट के रूप में यमल का मेरा विवरण।

— मार्नेन लाइबो-कोसेर

@ नेट्स कई लोगों ने पहले ही बताया था कि उत्तर नहीं था। मैंने ओपी के लक्ष्य को हासिल करने का बेहतर तरीका सुझाया। यह एक जवाब है।

— मार्नेन लाईबो-कोसर

डाउनसाइड: yamlलाइब्रेरी को पायथन के साथ शिप नहीं किया गया है।

— ब्लीडिंग फिंगर्स

@ marnen-laibow-koser: हाँ, यह जावा और पर्ल के लिए उपलब्ध YAML पुस्तकालयों का उपयोग करने के लिए अक्षमता रही होगी और प्रत्येक द्वारा उत्पादित YAML को बिना किसी त्रुटि के उपभोग करने की उम्मीद होगी। वह YAML इंटरॉप एक मुद्दा था, लेकिन JSON इंटरॉप पूरी तरह से मेरे ज्ञान की कमी से समझाया गया है।

— टूलबार

@ marnen-laibow-koser, एक प्रारूप जो एक साधारण चीज़ के साथ एक ही चीज़ को पूरा करता है, बेहतर है। सही कार्यान्वयन के साथ एक व्यावहारिक प्रारूप अपूर्ण कार्यान्वयन के साथ एक आदर्श प्रारूप से बेहतर है। दोषपूर्ण कामों के लिए सभी दोष कार्यान्वयनकर्ताओं के कंधों पर नहीं हैं; YAML युक्ति लंबे, घने और मोटे है। इसकी विकिपीडिया प्रविष्टि अस्पष्टता के दो उदाहरणों का हवाला देती है; यदि किसी को मानव और उन्हें अस्पष्टताओं से बचाने के लिए प्रारूप के बीच एक एमिटर लगाना चाहिए, तो प्रारूप अपने मानव के अनुकूल दावे को खो देता है। JSON कम दावा करता है और ज्यादातर सफल होता है जहां YAML अधिक दावा करता है और कम गिरता है।

— टूलबार

Answer 8

आप नहीं कर सकते। कम से कम json.org पर एक त्वरित नज़र से मेरा अनुभव है ।

JSON ने उस पृष्ठ पर इसके सिंटैक्स की कल्पना की है। टिप्पणियों के बारे में कोई नोट नहीं है।

Answer 9

टिप्पणियाँ एक आधिकारिक मानक नहीं हैं, हालांकि कुछ पार्सर C ++ शैली टिप्पणियों का समर्थन करते हैं। एक है कि मैं उपयोग JsonCpp है । उदाहरणों में यह एक है:

// Configuration options
{
    // Default encoding for text
    "encoding" : "UTF-8",

    // Plug-ins loaded at start-up
    "plug-ins" : [
        "python",
        "c++",
        "ruby"
        ],

    // Tab indent size
    "indent" : { "length" : 3, "use_space": true }
}

jsonlint इसे मान्य नहीं करता है। इसलिए टिप्पणियां एक विशिष्ट विशिष्ट विस्तार हैं न कि मानक।

एक अन्य पार्सर JSON5 है ।

JSON TOML का एक विकल्प ।

एक और विकल्प jsonc है ।

Comments

ग्रूवी के पास JSON से निपटने के लिए कुछ अंतर्निहित कक्षाएं हैं । JsonSlurper टिप्पणियों को संभाल सकता है। बेशक, आधिकारिक कल्पना में टिप्पणियों की अनुमति नहीं है, इसलिए किसी भी पार्सर में यह व्यवहार गैर-मानक और गैर-पोर्टेबल है।

— इज़्रिक

Newtonsoft Json.NET भी बिना किसी समस्या के C- स्टाइल टिप्पणियों का समर्थन करता है

— अधिकतम

Answer 10

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

उदाहरण:

{
    "description":"A person",
    "type":"object",
    "properties":
        {
            "name":
                {
                    "type":"string"
                },
            "age":
                {
                    "type":"integer",
                    "maximum":125
                }
        }
}

आप विवरण स्कीमा विशेषता का उपयोग करके प्रलेखन प्रदान कर सकते हैं ।

Comments

क्या JSON स्कीमा जीवित है? यह मौजूद है लेकिन क्या यह किसी ज्ञात पुस्तकालय द्वारा समर्थित है?

— मुंशित्सु

हां, json-schema google group काफी सक्रिय है और मैं JSV की सिफारिश करूंगा एक JSON स्कीमा सत्यापनकर्ता का एक अच्छा जावास्क्रिप्ट कार्यान्वयन के लिए।

— राफेल

यह केवल संरचित प्रलेखन में मदद करता है, तदर्थ प्रलेखन नहीं

— जुआन मेंडेस

यदि आप क्लोजर का उपयोग करते हैं (और मुझे यकीन है कि आप नहीं करते हैं) तो यहां एक यथोचित रूप से खुला स्रोत JSON स्कीमा पार्सर है: github.com/bigmlcom/closchema

— charleslparker 15'13

@Munhitsu Manatee.Json (.Net) बड़े पैमाने पर JSON स्कीमा का समर्थन करती है।

— Gregsdennis

Answer 11

यदि आप जैक्सन को अपने JSON पार्सर के रूप में उपयोग कर रहे हैं तो यह है कि आप टिप्पणियों को अनुमति देने के लिए इसे कैसे सक्षम करते हैं:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

तो आप इस तरह की टिप्पणी कर सकते हैं:

{
  key: "value" // Comment
}

और आपके पास #सेटिंग के साथ शुरू होने वाली टिप्पणियाँ भी हो सकती हैं :

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

लेकिन सामान्य तौर पर (जैसा पहले बताया गया है) विनिर्देश टिप्पणियों की अनुमति नहीं देता है।

Answer 12

यहाँ मैंने Google Firebase प्रलेखन में पाया है जो आपको JSON में टिप्पणी करने की अनुमति देता है:

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project's sender ID",
  "gcm_sender_id": "1234567890"
}

Comments

FYI करें, फायरबेस रियलटाइम डेटाबेस एक कुंजी में '/' के उपयोग की अनुमति नहीं देता है। तो यह आपके स्वयं के उपयोग के लिए एक अच्छा सम्मेलन हो सकता है, लेकिन आप इसे Firebase में नहीं कर सकते हैं

— gutte

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

— MovGP0

अच्छी टिप्पणी है, मुझे यह सवाल SO पर मिला ... यह हिस्सा युक्ति stackoverflow.com/questions/21832701// से कवर नहीं लगता है

— man

मैं आजकल इसका उपयोग इस प्रकार करता हूं: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} आप कई टिप्पणियों के लिए एक सरणी का उपयोग कर सकते हैं: {"// foo": ["फू टिप्पणी 1", "फू टिप्पणी 2"], "फू": '' फू मूल्य "}

— MovGP0

Answer 13

सं । JSON टिप्पणियों का समर्थन करता था, लेकिन उनका दुरुपयोग किया गया था और मानक से हटा दिया गया था।

JSON के निर्माता से:

मैंने JSON से टिप्पणियों को हटा दिया क्योंकि मैंने देखा कि लोग उन्हें पार्सिंग निर्देशों का उपयोग करने के लिए उपयोग कर रहे थे, एक अभ्यास जो अंतर्संचालनीयता को नष्ट कर देता। मुझे पता है कि टिप्पणियों की कमी कुछ लोगों को दुखी करती है, लेकिन ऐसा नहीं होना चाहिए। - डगलस क्रॉकफोर्ड, 2012

आधिकारिक JSON साइट JSON.org पर है । JSON को ECMA इंटरनेशनल द्वारा एक मानक के रूप में परिभाषित किया गया है । मानकों को संशोधित करने के लिए हमेशा एक याचिका प्रक्रिया होती है। यह संभावना नहीं है कि एनोटेशन को कई कारणों से JSON मानक में जोड़ा जाएगा।

JSON डिज़ाइन द्वारा XML के लिए एक आसानी से रिवर्स-इंजीनियर (मानव पार्स) विकल्प है। यह इस बिंदु पर भी सरल है कि एनोटेशन अनावश्यक हैं। यह मार्कअप लैंग्वेज भी नहीं है। लक्ष्य स्थिरता और अंतरसंयंत्र है।

जो कोई भी वस्तु अभिविन्यास के "है-ए" संबंध को समझता है वह किसी भी JSON संरचना को समझ सकता है - यह संपूर्ण बिंदु है। यह नोड टैग्स (की / वैल्यू पेयर) के साथ सिर्फ एक निर्देशित चक्रीय ग्राफ (DAG) है, जो कि एक सार्वभौमिक डेटा संरचना है।

यह केवल एनोटेशन आवश्यक हो सकता है "// ये डीएजी टैग हैं"। प्रमुख नाम आवश्यक रूप से सूचनात्मक हो सकते हैं, जिससे मनमाने ढंग से शब्दार्थ हो सकता है।

कोई भी मंच कोड की कुछ पंक्तियों के साथ JSON को पार्स कर सकता है। XML को जटिल OO पुस्तकालयों की आवश्यकता होती है जो कई प्लेटफार्मों पर व्यवहार्य नहीं होते हैं।

एनोटेशन सिर्फ JSON को कम इंटरऑपरेबल बना देगा। बस जोड़ने के लिए और कुछ नहीं है, जब तक कि आपको वास्तव में एक मार्कअप लैंग्वेज (एक्सएमएल) की आवश्यकता न हो, और यह ध्यान न रखें कि आपका सस्पेंडेड डेटा आसानी से पार्स हो गया है या नहीं।

लेकिन JSON के निर्माता के रूप में भी मनाया गया, टिप्पणियों के लिए हमेशा जेएस पाइपलाइन समर्थन रहा है:

आगे बढ़ें और अपनी पसंद की सभी टिप्पणियाँ डालें। फिर इसे अपने JSON पार्सर को सौंपने से पहले JSMin के माध्यम से पाइप करें। - डगलस क्रॉकफोर्ड, 2012

Answer 14

यदि आपकी टेक्स्ट फ़ाइल, जो JSON स्ट्रिंग है, किसी प्रोग्राम द्वारा पढ़ी जाने वाली है, तो इसे उपयोग करने से पहले C या C ++ स्टाइल कमेंट्स को स्ट्रिप करना कितना मुश्किल होगा?

उत्तर: यह एक लाइनर होगा। यदि आप ऐसा करते हैं तो JSON फाइल को विन्यास फाइल के रूप में इस्तेमाल किया जा सकता है।

Comments

संभवतः अब तक का सबसे अच्छा सुझाव, हालाँकि अभी भी फाइलों को इंटरचेंज फॉर्मेट के रूप में रखने का एक मुद्दा है, क्योंकि उपयोग से पहले उन्हें पूर्व-प्रसंस्करण की आवश्यकता होती है।

— 11

मैं सहमत हूँ और जावा में एक JSON पार्सर लिखा है, जो www.SoftwareMonkey.org पर उपलब्ध है, जो वास्तव में ऐसा करता है।

— लॉरेंस Dol

मेरे विचार से, JSON का विस्तार करना (इसे अलग विनिमय प्रारूप कहे बिना) एक अच्छा विचार नहीं है: स्ट्रिंग्स के भीतर "टिप्पणियों" को अनदेखा करना सुनिश्चित करें। {"foo": "/ * यह एक टिप्पणी नहीं है। * /"}

— stofl

"" एक लाइनर होगा "उम, नहीं, वास्तव में, JSON एक नियमित व्याकरण नहीं है, जहां एक नियमित अभिव्यक्ति बस / * के मिलान जोड़े पा सकती है। आपको यह पता लगाने के लिए फ़ाइल को पार्स करना होगा कि क्या कोई / * एक स्ट्रिंग के अंदर दिखाई देता है (और इसे अनदेखा करें), या यदि वह बच गया है (और इसे अनदेखा करें), आदि। इसके अलावा, आपका जवाब अप्रभावी है क्योंकि आप केवल प्रदान करने के बजाय (गलत तरीके से) अनुमान लगाते हैं। कोई भी समाधान।

— काइल सिम्पसन

क्या @ काइल-सिम्पसन ने कहा। इसके अलावा, वह JSON.minify को तदर्थ regexps के विकल्प के रूप में उपयोग करने के बारे में अपने स्वयं के उत्तर के लिए पाठकों को निर्देशित करने के लिए बहुत मामूली है। ऐसा करो, यह नहीं।

— टूलबार

Answer 15

यदि आप पढ़ने के लिए ASP.NET के साथ Newtonsoft.Json पुस्तकालय का उपयोग कर रहे हैं / आप JSON में टिप्पणियों का उपयोग कर सकते हैं / deserialize:

// "नाम": "स्ट्रिंग"

//"मैंने नहीं किया

या

/* यह है एक

टिप्पणी उदाहरण * /

पुनश्च: एकल-पंक्ति टिप्पणियों को केवल न्यूटनसॉफ्ट जसन के 6+ संस्करणों के साथ समर्थित किया गया है।

उन लोगों के लिए अतिरिक्त नोट जो बॉक्स से बाहर नहीं सोच सकते हैं: मैं अपने द्वारा बनाई गई ASP.NET वेब एप्लिकेशन में बुनियादी सेटिंग्स के लिए JSON प्रारूप का उपयोग करता हूं। मैंने फ़ाइल पढ़ी, इसे न्यूटनसॉफ्ट लाइब्रेरी के साथ सेटिंग ऑब्जेक्ट में कनवर्ट करें और आवश्यक होने पर इसका उपयोग करें।

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

मुझे लगता है कि यह एक अलग 'सेटिंग.README' फ़ाइल बनाने और उसमें सेटिंग्स को समझाने की तुलना में 'उपयोग करने / समझने में आसान' है।

यदि आपको इस तरह के उपयोग की समस्या है; क्षमा करें, जिन्न दीपक से बाहर है। लोगों को JSON प्रारूप के लिए अन्य उपयोग मिलेंगे, और ऐसा कुछ भी नहीं है जो आप इसके बारे में कर सकते हैं।

Comments

यह समझना कठिन है कि किसी को तथ्य बताने में समस्या क्यों होगी।

— DVDMn

मुझे लगता है कि किसी ने अपवाद लिया क्योंकि ऊपर अब JSON नहीं है, या JSON अमान्य है। शायद एक छोटे से डिस्क्लेमर जोड़कर अपील की जाएगी।

— टूलबार

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

— जॉन

बिंदु एक फाइल है जिसमें टिप्पणी JSON नहीं है और कई JSON पुस्तकालयों द्वारा पार्स होने में विफल हो जाएगी। बेझिझक आप अपने कार्यक्रम में जो चाहें कर सकते हैं लेकिन टिप्पणियों वाली फाइल JSON नहीं है। यदि आप यह दावा करते हैं तो लोग इसे अपनी भाषा / पसंद की लाइब्रेरी के साथ पार्स करने का प्रयास करेंगे और यह विफल हो जाएगा। यह पूछने जैसा है कि क्या आप XML में कोण कोष्ठक के बजाय वर्ग कोष्ठक का उपयोग कर सकते हैं। आप जो चाहें कर सकते हैं लेकिन यह XML नहीं होगा।

— gman

Answer 16

JSON के पीछे का विचार अनुप्रयोगों के बीच सरल डेटा विनिमय प्रदान करना है। ये आमतौर पर वेब आधारित हैं और भाषा जावास्क्रिप्ट है।

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

सभी ने कहा कि, यह इरादा नहीं है कि JSON फ़ाइल में पारंपरिक अर्थों में टिप्पणियां होनी चाहिए। यह सिर्फ डेटा होना चाहिए।

पर एक नज़र डालें JSON वेबसाइट और अधिक विस्तार के लिए।

Comments

यह सच है कि JSON प्रारूप में टिप्पणियां नहीं हैं। व्यक्तिगत रूप से मुझे लगता है कि यह एक महत्वपूर्ण गलती है - मेटाडेटा (डेटा नहीं) के रूप में टिप्पणी करने की क्षमता xml के साथ एक बहुत ही उपयोगी चीज है। JSON विनिर्देशन के पहले ड्राफ्ट संस्करणों में टिप्पणियां शामिल थीं, लेकिन किसी कारण से उन्हें छोड़ दिया गया था। : - /

— स्टेक्समैन

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

— कैमिलो मार्टिन

मेटाडेटा मेटाडेटा कंस्ट्रक्शन (उदाहरण के लिए HTML <मेटा> टैग) में है, टिप्पणी नहीं। मेटाडेटा के लिए अपमानजनक टिप्पणियां केवल एक हैक का उपयोग किया जाता है, जहां कोई वास्तविक मेटाडेटा निर्माण मौजूद नहीं है।

— मर्नेन लाईबो-कोसर

यही कारण है कि इसे गिरा दिया गया था: मेटाडेटा के रूप में इस्तेमाल की जाने वाली टिप्पणियां अंतर-अस्थिरता को तोड़ देती हैं। आपको अपना मेटा-डेटा केवल JSON के रूप में संग्रहीत करना चाहिए।

— विशाल

यह उत्तर बेहतर लिखित, उच्च उत्कीर्ण उत्तरों के साथ बेमानी है, जो अनिवार्य रूप से एक ही बात कहते हैं, भले ही यह पहले लिखा गया हो। Cest la Vie।

— टूलबार

Answer 17

मैं सिर्फ विन्यास फाइल के लिए यह मुठभेड़ है। मैं XML का उपयोग नहीं करना चाहता (क्रिया, रेखांकन, बदसूरत, पढ़ने में कठिन), या "ini" प्रारूप (कोई पदानुक्रम, कोई वास्तविक मानक नहीं, आदि) या जावा "गुण" प्रारूप (जैसे .ini)।

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

मुझे लगता है कि कोई "#": "comment""वैध" JSON के लिए उपयोग कर सकता है ।

Comments

कॉन्फिग फाइलों के लिए, मैं सुझाव दूंगा, कि नहीं JSON। यह (लगभग) JSON का एक अधिक शक्तिशाली सुपरसेट है, लेकिन टिप्पणियों सहित अधिक पठनीय निर्माणों का समर्थन करता है।

— मार्नेन लाइबो-कोसर

आपको क्या लगता है कि जुबान की तुलना में आप बॉक्स से बाहर कितनी भाषाओं का समर्थन करते हैं?

— mmm

@ हमीदाम एक दर्जन से अधिक भाषाओं में yaml: yaml.org का समर्थन करता है - लेकिन आप यह पूछने के लिए सही हैं कि तीसरे पक्ष के पुस्तकालय की निर्भरता की आवश्यकता के बिना कितने में अंतर्निहित समर्थन है। रूबी 1.9.2 की तरह दिखता है। किसी को दूसरों का पता है? और डिफ़ॉल्ट रूप से कौन सी भाषाएं जोंस के लिए समर्थन करती हैं?

— nealmcb

YAML इंटरॉप एक झूठ है: stackoverflow.com/questions/450399/… । यदि आपकी वृत्ति कॉन्फ़िगरेशन फ़ाइलों के लिए JSON का उपयोग करना है, तो इसका पालन करें।

— टूलबार

यह पुराना है, लेकिन मेरा मानना ​​है कि # का उपयोग करना एक अच्छा विचार नहीं है। जसन एक जावास्क्रिप्ट लैटरल के सिंटैक्स के करीब है। जावास्क्रिप्ट 2 प्रकार की टिप्पणी का समर्थन करता है: // और / * ... * / अगर मैं तुम होते तो मैं एक या दोनों प्रकार की टिप्पणियों के साथ रहता।

— पास्कल गनेय

Answer 18

JSON मूल रूप से टिप्पणियों का समर्थन नहीं करता है, लेकिन आप टिप्पणियों को अलग करने के लिए अपना डिकोडर या कम से कम प्रीप्रोसेसर बना सकते हैं, यह पूरी तरह से ठीक है (जब तक आप टिप्पणियों को अनदेखा करते हैं और उनका उपयोग करने के लिए मार्गदर्शन नहीं करते हैं कि आपके आवेदन को JSON डेटा कैसे संसाधित करना चाहिए )।

JSON में टिप्पणियां नहीं हैं। एक JSON एनकोडर जरूरी आउटपुट टिप्पणी नहीं करता है। एक JSON डिकोडर MAY को स्वीकार करता है और टिप्पणियों को अनदेखा करता है।

कुछ भी सार्थक प्रसारित करने के लिए टिप्पणियों का उपयोग कभी नहीं किया जाना चाहिए। यही JSON के लिए है।

Cf: डगलस क्रॉकफोर्ड, JSON कल्पना के लेखक ।

Comments

क्रॉकफोर्ड ने बाद में लिखा: "मान लीजिए कि आप कॉन्फ़िगरेशन फ़ाइलों को रखने के लिए JSON का उपयोग कर रहे हैं, जिसे आप एनोटेट करना चाहते हैं। आगे बढ़ें और अपनी पसंद की सभी टिप्पणियाँ डालें। फिर इसे अपने JSON पेपर को सौंपने से पहले JSMin के माध्यम से पाइप करें।" अधिक जानकारी के लिए JSON.minify के बारे में @ kyle-simpson का जवाब देखें।

— टूलबार

Answer 19

यह आपके JSON लाइब्रेरी पर निर्भर करता है। Json.NET , जावास्क्रिप्ट वाली शैली में टिप्पणियां का समर्थन करता है /* commment */।

एक और ढेर अतिप्रवाह सवाल देखें ।

Comments

और मेरा मानना ​​है कि इसी कारण मुझे इस ASP.NET vNext पूर्वावलोकन पृष्ठ (पैकेज के तहत jjson ) पर एक स्क्रीनशॉट में एक टिप्पणी दिखाई दे रही है: blogs.msdn.com/b/webdev/archive/2014/06/03// हालांकि मैं हेवन टी अभी तक कल्पना में कुछ भी नहीं मिला।

— webXL

Answer 20

JSON कॉन्फ़िगर फ़ाइलों और अन्य स्थानीय उपयोग के लिए बहुत मायने रखता है क्योंकि यह सर्वव्यापी है और क्योंकि यह XML की तुलना में बहुत सरल है।

यदि डेटा संचार करते समय लोग JSON में टिप्पणी करने के खिलाफ मजबूत कारण हैं (चाहे वैध हो या नहीं), तो संभवतः JSON को इसमें विभाजित किया जा सकता है:

• JSON-COM: JSON तार पर, या नियम जो JSON डेटा संचार करते समय लागू होते हैं।
• JSON-DOC: JSON दस्तावेज़, या JSON फ़ाइलों या स्थानीय रूप से। नियम जो एक वैध JSON दस्तावेज़ को परिभाषित करते हैं।

JSON-DOC टिप्पणियों की अनुमति देगा, और अन्य छोटे अंतर मौजूद हो सकते हैं जैसे कि व्हाट्सएप को संभालना। पार्सर्स आसानी से एक कल्पना से दूसरे में बदल सकते हैं।

इस मुद्दे पर डगलस क्रॉकफोर्ड द्वारा की गई टिप्पणी के संबंध में (@Artur Czajka द्वारा संदर्भित)

मान लीजिए कि आप JSON का उपयोग विन्यास फाइल रखने के लिए कर रहे हैं, जिसे आप एनोटेट करना चाहेंगे। आगे बढ़ें और अपनी पसंद की सभी टिप्पणियाँ डालें। फिर इसे अपने JSON पार्सर को सौंपने से पहले JSMin के माध्यम से पाइप करें।

हम एक जेनेरिक कॉन्फ़िग फ़ाइल समस्या (क्रॉस भाषा / प्लेटफ़ॉर्म) के बारे में बात कर रहे हैं, और वह एक जेएस विशिष्ट उपयोगिता के साथ उत्तर दे रहा है!

निश्चित रूप से एक JSON विशिष्ट minify को किसी भी भाषा में लागू किया जा सकता है, लेकिन इसे मानकीकृत करें ताकि यह सभी भाषाओं और प्लेटफार्मों में पार्सर्स में सर्वव्यापी हो जाए, ताकि लोग अपना समय बर्बाद न करें और इस सुविधा का अभाव हो क्योंकि उनके पास इसके लिए अच्छे उपयोग के मामले हैं, इस मुद्दे को देख रहे हैं। ऑनलाइन फ़ोरम, और लोगों को यह बताना कि यह एक बुरा विचार है या यह सुझाव देना आसान है कि पाठ फ़ाइलों से अलग हटकर टिप्पणियों को लागू करना आसान है।

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

Comments

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

— टूलबार

json5.org json-doc के लिए एक समाधान है

— माइकल फ्रीजिम

Answer 21

यदि आप JSON5 का उपयोग करते हैं तो आप टिप्पणियां शामिल कर सकते हैं।

---

JSON5 JSON का एक प्रस्तावित विस्तार है जिसका उद्देश्य मनुष्यों के लिए हाथ से लिखना और बनाए रखना आसान बनाना है। यह ECMAScript 5 से सीधे कुछ न्यूनतम वाक्यविन्यास सुविधाओं को जोड़कर करता है।

Comments

क्या आप एक उदाहरण जोड़ सकते हैं? तब आपको वास्तव में उन अतिरिक्त पात्रों की आवश्यकता हो सकती है।

— dgilperez

वास्तविक उत्तर प्रदान करने के लिए एसओ दिशानिर्देशों की आवश्यकता है। लिंक-केवल उत्तर वांछित नहीं हैं। आप दिशानिर्देशों की जांच कर सकते हैं stackoverflow.com/help/how-to-answer

— dgilperez

SO को उसके उपयोगकर्ताओं द्वारा संचालित किया जाता है। इसका मतलब है कि अगर मैं दिशा-निर्देशों का पालन नहीं करता हूं तो मैं आपको इसका जवाब दे सकता हूं। इस तरह एसओ को एक बेहतरीन संसाधन मिल जाता है।

— dgilperez

Answer 22

Dojo टूलकिट जावास्क्रिप्ट टूलकिट (संस्करण 1.4 के रूप में कम से कम), आपको अपने JSON में टिप्पणियों को शामिल करने की अनुमति देता है। टिप्पणियाँ /* */प्रारूप की हो सकती हैं । Dojo टूलकिट dojo.xhrGet()कॉल के माध्यम से JSON का उपभोग करता है ।

अन्य जावास्क्रिप्ट टूलकिट इसी तरह काम कर सकते हैं।

अंतिम विकल्प चुनने से पहले वैकल्पिक डेटा संरचनाओं (या यहां तक ​​कि डेटा सूचियों) के साथ प्रयोग करते समय यह मददगार हो सकता है।

Comments

नहीं, यह नहीं। JSON में टिप्पणियां नहीं हैं। यदि आप टिप्पणियों के साथ अपने JSON को एनोटेट करना चुनते हैं, तो पार्स करने या प्रसारित करने से पहले इसे छोटा करें। यह रिसीवर की जिम्मेदारी नहीं होनी चाहिए।

— टूलबार

मैंने यह नहीं कहा कि JSON में टिप्पणियां हैं। न ही मेरा मतलब यह था कि उन्हें अपने JSON में शामिल करना उचित है, विशेष रूप से उत्पादन प्रणाली में। मैंने कहा कि डोजो टूलकिट आपको उन्हें जोड़ने की अनुमति देता है, जो कि (या कम से कम,) तथ्यात्मक रूप से सच है। आपके परीक्षण चरण में ऐसा करने के लिए बहुत उपयोगी उपयोग-मामले हैं।

— डेविड

यह टिप्पणी करने के लिए बुरा व्यवहार है, और इस तरह अमान्य JSON, जो dojo.xhrGet()स्पष्ट रूप से स्वीकार करके प्रोत्साहित करता है।

— टूलबार

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

— क्रेग

Answer 23

JSON एक फ़्रेमयुक्त प्रोटोकॉल नहीं है । यह एक भाषा मुक्त प्रारूप है । तो JSON के लिए एक टिप्पणी के प्रारूप को परिभाषित नहीं किया गया है।

जैसा कि कई लोगों ने सुझाव दिया है, कुछ चालें हैं, उदाहरण के लिए, डुप्लिकेट कुंजी या एक विशिष्ट कुंजी _commentजिसे आप उपयोग कर सकते हैं। यह आप पर निर्भर करता है।

Answer 24

आप JSONP में टिप्पणी कर सकते हैं , लेकिन शुद्ध JSON में नहीं। मैंने अपने कार्यक्रम को Highcharts से इस उदाहरण के साथ काम करने में केवल एक घंटा बिताया है: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

यदि आप लिंक का अनुसरण करते हैं, तो आप देखेंगे

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

चूंकि मेरे स्थानीय फ़ोल्डर में एक समान फ़ाइल थी , इसलिए समान-मूल नीति के साथ कोई समस्या नहीं थी , इसलिए मैंने शुद्ध JSON का उपयोग करने का निर्णय लिया ... और, ज़ाहिर है,$.getJSON टिप्पणियों के कारण चुपचाप विफल हो रहा था।

आखिरकार मैंने अभी उपरोक्त पते पर एक मैनुअल HTTP अनुरोध भेजा और महसूस किया कि सामग्री-प्रकार तब text/javascriptसे था , ठीक है, JSONP शुद्ध जावास्क्रिप्ट देता है। इस मामले में टिप्पणियों की अनुमति है । लेकिन मेरे आवेदन ने सामग्री-प्रकार लौटा दिया application/json, इसलिए मुझे टिप्पणियों को हटाना पड़ा।

Answer 25

यह एक "आप कर सकते हैं" सवाल है। और यहाँ एक "हाँ" है उत्तर है।

नहीं, आपको डुप्लिकेट ऑब्जेक्ट सदस्यों को साइड चैनल डेटा को JSON एन्कोडिंग में सामान करने के लिए उपयोग नहीं करना चाहिए। ( RFC में "किसी वस्तु के नाम अद्वितीय होने चाहिए" देखें )।

और हाँ, आप JSON के चारों ओर टिप्पणियां डाल सकते हैं , जिसे आप पार्स कर सकते हैं।

लेकिन यदि आप वैध JSON के लिए मनमाना साइड-चैनल डेटा सम्मिलित करने और निकालने का एक तरीका चाहते हैं, तो यहां एक जवाब है। हम JSON एन्कोडिंग में डेटा के गैर-अद्वितीय प्रतिनिधित्व का लाभ उठाते हैं। यह अनुमति दी है ^* तहत आरएफसी "खाली स्थान के पहले या छह संरचनात्मक वर्णों के किसी भी के बाद अनुमति दी है" की धारा दो में।

^* RFC केवल कहता है कि "व्हाट्सएप को छह संरचनात्मक वर्णों में से किसी के पहले या बाद में अनुमति दी गई है", स्पष्ट रूप से तार, संख्या, "झूठे", "सच" और "अशक्त" का उल्लेख नहीं है। सभी कार्यान्वयनों में इस चूक को अनदेखा किया जाता है।

---

सबसे पहले, इसे छोटा करके अपने JSON को रद्द करें:

$jsonMin = json_encode(json_decode($json));

फिर बाइनरी में अपनी टिप्पणी एनकोड करें:

$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);

फिर अपना बाइनरी स्टेप करें:

$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);

यहाँ आपका उत्पादन है:

$jsonWithComment = $steg . $jsonMin;

Comments

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

— विलियम एंट्रीकेन

अधिक से अधिक टिप्पणी घनत्व के लिए, आप अपनी टिप्पणी को टर्नरी में नहीं लिख सकते हैं और इसे स्टेप करने के लिए स्पेस, टैब और न्यूलाइन का उपयोग कर सकते हैं?

— क्लेयर नीलसन

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

— जेफ के।

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

— विलियम एंट्रीकेन

Answer 26

अस्वीकरण: यह बहुत है

वास्तव में टिप्पणियों को जोड़ने का एक तरीका है, और युक्ति के भीतर रहना (कोई अतिरिक्त पार्सर आवश्यक नहीं)। हालांकि यह किसी भी प्रकार के पार्सिंग के बिना मानव-पठनीय टिप्पणियों में परिणत नहीं होगा।

आप निम्नलिखित का दुरुपयोग कर सकते हैं:

किसी भी टोकन से पहले या बाद में महत्वहीन व्हाट्सएप की अनुमति है। व्हॉट्सएप निम्नलिखित कोड बिंदुओं में से एक या अधिक का कोई अनुक्रम है: चरित्र सारणीकरण (यू + 0009), लाइन फीड (यू + 000 ए), गाड़ी वापसी (यू + 000 डी), और अंतरिक्ष (यू + 0020)।

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

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threeASCII में) लेकिन 0 उपयोग स्थान के बजाय, 1 उपयोग लाइन फीड के लिए और 2 उपयोग गाड़ी वापसी के लिए।

यह आपको बहुत सारे अपठनीय व्हाट्सएप के साथ छोड़ देगा (जब तक कि आप आईडीई प्लग इन को एनकोड करने / इसे उड़ने के लिए डिकोड नहीं करते)।

मैंने कभी भी स्पष्ट कारणों के लिए यह कोशिश नहीं की और न ही आपको करना चाहिए।

Answer 27

हम strip-json-commentsअपने प्रोजेक्ट के लिए उपयोग कर रहे हैं । यह कुछ इस तरह का समर्थन करता है:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

बस npm install --save strip-json-commentsइसे स्थापित करने और उपयोग करने के लिए जैसे:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

Comments

ध्यान दें कि jsonयह एक वैध JSON नहीं है, जब इसमें ये प्रॉपर कमेंट शामिल हैं।

— रॉय

Answer 28

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

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

Answer 29

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

आप (का उपयोग करते हुए टिप्पणी डाल करने का प्रयास करें //या /* */या #उदाहरण के लिए), तो कुछ पारसर्स असफल हो जायेगी क्योंकि इस सख्ती से नहीं है JSON विनिर्देश के भीतर। इसलिए आपको ऐसा कभी नहीं करना चाहिए ।

उदाहरण के लिए, जहाँ मेरी छवि हेरफेर प्रणाली ने छवि संकेतन और उनसे संबंधित कुछ मूलभूत स्वरूपित (टिप्पणी) जानकारी को बचाया है (नीचे):

{
    "Notations": [
        {
            "anchorX": 333,
            "anchorY": 265,
            "areaMode": "Ellipse",
            "extentX": 356,
            "extentY": 294,
            "opacity": 0.5,
            "text": "Elliptical area on top",
            "textX": 333,
            "textY": 265,
            "title": "Notation 1"
        },
        {
            "anchorX": 87,
            "anchorY": 385,
            "areaMode": "Rectangle",
            "extentX": 109,
            "extentY": 412,
            "opacity": 0.5,
            "text": "Rect area\non bottom",
            "textX": 98,
            "textY": 385,
            "title": "Notation 2"
        },
        {
            "anchorX": 69,
            "anchorY": 104,
            "areaMode": "Polygon",
            "extentX": 102,
            "extentY": 136,
            "opacity": 0.5,
            "pointList": [
                {
                    "i": 0,
                    "x": 83,
                    "y": 104
                },
                {
                    "i": 1,
                    "x": 69,
                    "y": 136
                },
                {
                    "i": 2,
                    "x": 102,
                    "y": 132
                },
                {
                    "i": 3,
                    "x": 83,
                    "y": 104
                }
            ],
            "text": "Simple polygon",
            "textX": 85,
            "textY": 104,
            "title": "Notation 3"
        }
    ],
    "imageXW": 512,
    "imageYW": 512,
    "imageName": "lena_std.ato",
    "tinyDocs": {
        "c01": "JSON image notation data:",
        "c02": "-------------------------",
        "c03": "",
        "c04": "This data contains image notations and related area",
        "c05": "selection information that provides a means for an",
        "c06": "image gallery to display notations with elliptical,",
        "c07": "rectangular, polygonal or freehand area indications",
        "c08": "over an image displayed to a gallery visitor.",
        "c09": "",
        "c10": "X and Y positions are all in image space. The image",
        "c11": "resolution is given as imageXW and imageYW, which",
        "c12": "you use to scale the notation areas to their proper",
        "c13": "locations and sizes for your display of the image,",
        "c14": "regardless of scale.",
        "c15": "",
        "c16": "For Ellipses, anchor is the  center of the ellipse,",
        "c17": "and the extents are the X and Y radii respectively.",
        "c18": "",
        "c19": "For Rectangles, the anchor is the top left and the",
        "c20": "extents are the bottom right.",
        "c21": "",
        "c22": "For Freehand and Polygon area modes, the pointList",
        "c23": "contains a series of numbered XY points. If the area",
        "c24": "is closed, the last point will be the same as the",
        "c25": "first, so all you have to be concerned with is drawing",
        "c26": "lines between the points in the list. Anchor and extent",
        "c27": "are set to the top left and bottom right of the indicated",
        "c28": "region, and can be used as a simplistic rectangular",
        "c29": "detect for the mouse hover position over these types",
        "c30": "of areas.",
        "c31": "",
        "c32": "The textx and texty positions provide basic positioning",
        "c33": "information to help you locate the text information",
        "c34": "in a reasonable location associated with the area",
        "c35": "indication.",
        "c36": "",
        "c37": "Opacity is a value between 0 and 1, where .5 represents",
        "c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
        "c39": "backdrop. Recommendation is that regions be drawn",
        "c40": "only if the user hovers the pointer over the image,",
        "c41": "and that the text associated with the regions be drawn",
        "c42": "only if the user hovers the pointer over the indicated",
        "c43": "region."
    }
}

Comments

"तर्क" लिंक टूट गया है। इसके लिए एक वर्तमान लिंक खोजने का कोई मौका?

— डॉन हैच

डॉन, दुर्भाग्य से, Google ने उस सोशल मीडिया सिस्टम को मार दिया है जिसमें पोस्ट शामिल थी; मुझे पता नहीं है कि मूल पोस्टर वहां से कहां गया, अगर कहीं भी। मैं उपरोक्त जानकारी में लिंक को मारूंगा, हालांकि, अस्पष्टता को दूर करने के लिए। धन्यवाद।

— fyngyrz

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

— डोमिनिक सेरिसानो

यदि कल्पना ने कहा कि "# के साथ शुरू होने वाली एक पंक्ति एक टिप्पणी है", तो यह पूरी तरह से अंतर होगा। जैसा कि यह खड़ा है, टिप्पणियां पार्सर स्थान को लोड करती हैं, क्योंकि वे टिप्पणी के रूप में समझने के बजाय मान्य पार्स आइटम हैं , और वे अस्तित्व में हर .json फ़ाइल के लिए अलग हो सकते हैं। जबकि अगर (उदाहरण के लिए) कल्पना ने कहा "# के साथ शुरू होने वाली लाइनें टिप्पणी हैं", तो पार्सर उन लाइनों को पार्सिंग (तेज) के बिना छोड़ सकते हैं और पार्सर स्थान (बेहतर मेमोरी उपयोग) को लोड नहीं कर सकते हैं। कमी से कोई फायदा नहीं है। टिप्पणियों में .json, केवल downsides।

— fyngyrz

Answer 30

किसी JSON आइटम को भागों में काटने के लिए मैं "डमी टिप्पणी" लाइनें जोड़ता हूं:

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}

Comments

आपने JSON में एक INI फ़ाइल संरचना का अनुकरण किया है। कृपया, अपना गोल्डन हैमर लगाएं।

— आर्टूर कज्जाका

RFC का कहना है कि "किसी वस्तु के नाम अद्वितीय होने चाहिए"। ऊपर दिए गए JSON को पार्स करने में त्रुटि करने वाले इस व्यक्ति को भी देखें: stackoverflow.com/questions/4912386/…

— विलियम एंट्रिएन

यदि आप JSON को मान्य करने के लिए स्कीमा का उपयोग कर रहे हैं, तो यह अतिरिक्त फ़ील्ड्स के कारण विफल हो सकता है।

— gregsdennis

यदि आप वास्तव में अपने JSON में टिप्पणियां जोड़ने के लिए दृढ़ हैं, तो यह कुछ ऐसा करने के लिए बहुत अधिक समझ में आता है: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } यह नाम अद्वितीय रखता है और आपको जो भी स्ट्रिंग मान पसंद करता है उसे जोड़ने की सुविधा देता है। यह अभी भी एक कीचड़ है, क्योंकि टिप्पणियां आपके JSON का हिस्सा नहीं होनी चाहिए। एक अन्य विकल्प के रूप में, अपने JSON से पहले या बाद में टिप्पणियां क्यों नहीं जोड़नी चाहिए, लेकिन इसके भीतर नहीं?

— जाजिमोव