सजा हुआ JSON जरूरी नहीं कि सही डेटा भी हो

इंडेंट से सेटिंग या सेवा का उत्तर जांचना आसान होता है। उससे यह नहीं पता चलता कि कीमत सही है, कोई फ़ील्ड जरूरी है या माप की इकाई उपयुक्त है।

सिंटैक्स पहली जांच है, अंतिम नहीं

JSON में स्ट्रिंग और प्रॉपर्टी के नाम दोहरे उद्धरण में होते हैं। टिप्पणियां और अंतिम तत्व के बाद कॉमा मानक सिंटैक्स में नहीं आते।

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

संदर्भ: RFC 8259 — JSON syntax and interoperability

स्ट्रिंग के भीतर स्पेस भी डेटा है

संरचना के चिह्नों के आसपास स्पेस बदलने से संरचना नहीं बदलती। उद्धरण के भीतर स्पेस मान का हिस्सा है; संक्षिप्त करना हर स्पेस हटाना नहीं है।

ToolRoof मूल संख्या और स्ट्रिंग की लिखावट रखता है। स्वरूप बदलते समय "0042" पहचान संख्या 42 नहीं बनती और 1e3 केवल दिखावट के लिए दूसरे रूप में नहीं लिखा जाता।

संदर्भ: RFC 8259 — JSON syntax and interoperability

दोहराई कुंजियों पर अलग निर्णय चाहिए

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

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

संदर्भ: RFC 8259 — JSON syntax and interoperability

उदाहरण: डिब्बे का कोड, गणना की संख्या नहीं

{"item":"box blue","quantity":2,"amount":1e3,"code":"0042"} में नाम के 2 स्पेस, संख्या वाला quantity, घातांक वाला amount और शुरुआत में 2 शून्य वाला पाठ code है। इंडेंट इन फर्कों को न मिटाए।

संक्षिप्त रूप में box blue के 2 स्पेस, 1e3 की लिखावट और "0042" स्ट्रिंग बचते हैं। {"count":2,"count":3} में मूल डेटा पर निर्णय चाहिए; सुंदर रूप इच्छित गिनती तय नहीं करता।

संदर्भ