JSON parsing और processing लाइब्रेरी तुलना
मुख्य बात: Native APIs सबसे तेज़ हैं, tolerant parsers offsets देते हैं। तीन बातों से चुनें: error location, मूल text सुरक्षित रहता है या नहीं, और सीमाएँ स्पष्ट हैं या नहीं।
सार: पहले ज़रूरत को वर्गीकृत करें, फिर implementations की तुलना करें — केवल पढ़ने वाले मानों के लिए native JSON.parse, offsets चाहिए या मूल formatting सुरक्षित रखना हो तो jsonc-parser, और query या patch लाइब्रेरी केवल वहीं जोड़ें जहाँ ज़रूरी हो; बड़ी लाइब्रेरी per page lazy-load करें और unmaintained हटा दें।
हर लाइब्रेरी "तेज़, छोटी और पूर्ण" होने का दावा करती है। असली अंतर यह है कि कुछ गलत होने पर वह आपको कितनी जानकारी दे सकती है।
1. उद्देश्य के आधार पर चार श्रेणियाँ
| श्रेणी | प्रतिनिधि लाइब्रेरी | क्या हल करती है |
|---|---|---|
| मानक parsing | JSON.parse / JSON.stringify |
Syntax ↔ object, गति पहले |
| Tolerant parsing + editing | jsonc-parser, json5 |
Comments वाला input, offset तक सटीक errors, formatting सुरक्षित रखने वाले बदलाव |
| Query | jsonpath-plus, jsonpath |
Expression से nodes चुनना |
| Mutation | fast-json-patch, immer |
Patch बनाना/लागू करना, immutable updates |
पहले पहचानें कि आप किस श्रेणी में हैं, फिर ठोस implementations की तुलना करें — वरना parser का काम query लाइब्रेरी से कराना आसान हो जाता है।
2. साथ-साथ तुलना
| लाइब्रेरी | Error location | सहनशीलता (comments/trailing commas) | मूल formatting सुरक्षित | उपयुक्त परिदृश्य |
|---|---|---|---|---|
JSON.parse |
केवल संदेश और स्थिति (engine पर निर्भर) | ✗ | ✗ | डिफ़ॉल्ट parsing, API डेटा |
jsonc-parser |
सटीक offset + error code |
✓ | ✓ (modify + applyEdits) |
एडिटर, कॉन्फ़िगरेशन फ़ाइलें |
json5 |
Line और column जानकारी | ✓ (अधिक उदार) | ✗ | JSON5 कॉन्फ़िगरेशन पढ़ना |
jsonlint |
Line और column जानकारी | ✗ | ✗ | केवल संदर्भ, सक्रिय रूप से maintained नहीं |
jsonpath-plus |
Expression syntax errors | — | — | Expression से querying |
fast-json-patch |
Operation-स्तर errors | — | — | Patch निर्माण और अनुप्रयोग |
lz-string |
— | — | — | JSON को URL में compress करना |
JSON.parse के error संदेश engines के बीच बहुत भिन्न होते हैं। V8 कुछ ऐसा देता है
Unexpected token } in JSON at position 42, लेकिन स्थिति सटीक है या नहीं यह engine संस्करण पर निर्भर करता है;
jsonc-parser इसके बजाय एक स्थिर संरचित { error, offset, length } लौटाता है, जो एडिटर markers के लिए उपयुक्त है।
3. चार मुख्य निर्णय बिंदु
3.1 क्या आपको offsets चाहिए
अगर आप एडिटर बना रहे हैं और चाहते हैं कि "error पर क्लिक करें और संबंधित पंक्ति पर जाएँ", तो offset अनिवार्य है। परख सरल है: अगर आपका error संदेश केवल "invalid JSON" छाप सकता है, तो उपयोगकर्ता को खुद खोजना पड़ेगा।
import { parse, printParseErrorCode } from 'jsonc-parser';
const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });
if (errors.length > 0) {
const firstError = errors[0];
console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}
3.2 क्या आपको मूल text सुरक्षित रखना है
केवल मान पढ़ना → कोई भी parser चलेगा। "एक field बदलें और बाकी सब वैसा ही रखें" → आपको editing-style API इस्तेमाल करना होगा, "parse → object बदलो → serialize" नहीं।
बाद वाला खो देता है: comments, key order (कुछ implementations में), indentation style, numeric literal notation (1e3 1000 बन जाता है), और escape forms (\u4e2d असली अक्षर बन जाता है)।
3.3 क्या सीमा व्यवहार स्पष्ट हैं
लाइब्रेरी चुनने से पहले documentation में तीन बातें देखें:
- Duplicate keys कैसे संभाले जाते हैं (आख़िरी वाला रखें / error दें);
- क्या बड़े integers सटीकता खो देते हैं (ज़्यादातर JS लाइब्रेरी खो देती हैं, क्योंकि सभी
Numberसे गुज़रती हैं); - BOM, comments और trailing commas का समर्थित दायरा।
अगर documentation नहीं है, तो एक छोटा sample लिखकर खुद परखें। यह README पढ़ने से अधिक भरोसेमंद है।
3.4 रखरखाव स्थिति
JSON लाइब्रेरी का जोखिम features की कमी नहीं, बल्कि दीर्घकालिक उपेक्षा है: अब कोई security patches (prototype pollution, ReDoS) नहीं देगा।
4. अन्य भाषाओं के साथ तुलना
| भाषा | मानक लाइब्रेरी / मुख्यधारा लाइब्रेरी | मुख्य अंतर |
|---|---|---|
| JavaScript | JSON.parse |
सभी संख्याएँ double-precision |
| TypeScript | ऊपर जैसा + jsonc-parser / zod |
Types केवल compile time पर |
| Go | encoding/json |
डिफ़ॉल्ट float64, सटीकता बनाए रखने के लिए UseNumber(); deferred parsing के लिए json.RawMessage |
| Java | Jackson / Gson / Moshi | Jackson के साथ, default typing सक्षम करने के जोखिम से सावधान रहें |
| Python | json / orjson |
parse_float=Decimal सटीकता बनाए रखता है; orjson तेज़ है पर सभी प्रकार समर्थित नहीं |
| Rust | serde_json |
Strongly typed deserialization; arbitrary_precision feature सटीकता बनाए रखता है |
| C++ | simdjson / RapidJSON | simdjson parsing throughput पर लक्षित है, RapidJSON अधिक सामान्य-प्रयोजन |
भाषाओं के बीच डेटा का आदान-प्रदान करते समय सबसे आसानी से ठोकर खाने वाली चीज़ें अब भी number precision और time formats हैं; लाइब्रेरी चयन उन्हें कम कर सकता है, खत्म नहीं।
5. सामान्य संयोजन
विकल्प 1: Tool site (browser side)
Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string
इस संयोजन की पहचान यह है कि सब कुछ locally चलता है और कोई डेटा upload नहीं होता, जो एक utility site की privacy अपेक्षाओं से मेल खाता है।
विकल्प 2: Server-side API gateway
Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed
Gateway परत में business logic लागू करने के लिए query/patch लाइब्रेरी न जोड़ें — वह business परत का काम है।
विकल्प 3: CLI और scripts
Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli
6. Bundle आकार और प्रदर्शन का असली प्रभाव
jsonc-parserबहुत छोटा है और main bundle के लिए उपयुक्त है;json5jsonc-parserसे थोड़ा बड़ा है क्योंकि वह अधिक syntax समर्थित करता है;jsonpath-plusमें expression evaluation शामिल है और स्पष्ट रूप से बड़ा है, इसलिए इसे per page lazy-load करना चाहिए;fast-json-patchमध्यम आकार का है और केवल तब चाहिए जब आपके पास comparison feature हो।
Optimization सीधा है: per page dynamically import करें, और उन्हें first-screen chunk में न रखें।
const { JSONPath } = await import('jsonpath-plus');
7. जाँच सूची
- [ ] उद्देश्य के अनुसार लाइब्रेरी चुनें; parsing के लिए query लाइब्रेरी न इस्तेमाल करें;
- [ ] सटीक error locations चाहिए तो
jsonc-parserइस्तेमाल करें; - [ ] Comments और formatting सुरक्षित रखने हों तो editing-style APIs इस्तेमाल करें;
- [ ] तीन सीमा व्यवहार व्यवहार में परखें: duplicate keys, बड़े integers और BOM;
- [ ] लाइब्रेरी की रखरखाव स्थिति और security advisories पर नज़र रखें;
- [ ] बड़ी लाइब्रेरी माँग पर dynamically import करें।
सामान्य प्रश्न
अपने प्रोजेक्ट आकार के अनुसार JSON लाइब्रेरी कैसे चुनें?
छोटे उपकरण जो केवल API डेटा पढ़ते हैं, native JSON.parse पर रह सकते हैं। जिन प्रोजेक्ट्स को एडिटर-स्तरीय error locations चाहिए या मूल formatting सुरक्षित रखनी हो, उन्हें jsonc-parser इस्तेमाल करना चाहिए। Server-side gateway को केवल validation और parsing चाहिए, query और patch लाइब्रेरी business परत के लिए छोड़ दें, जबकि CLI scripts सीधे jq, yq और ajv-cli इस्तेमाल कर सकती हैं।
रखरखाव स्थिति features की संख्या से अधिक महत्वपूर्ण क्यों है?
JSON लाइब्रेरी का असली जोखिम दीर्घकालिक उपेक्षा है, features की कमी नहीं: prototype pollution या ReDoS के लिए कोई security patches नहीं देगा। Feature सूची कितनी भी पूर्ण हो, रुकी हुई लाइब्रेरी आपको खुद पैच करने पर छोड़ देती है। रखरखाव और security advisories को feature tables की तुलना के बजाय कठोर मानदंड मानें।
क्या एक field बदलने और comments व indentation रखने के लिए JSON.parse इस्तेमाल करना चाहिए?
नहीं। Parse करना, object बदलना, फिर serialize करना comments, key order, indentation style, numeric literal notation (1e3 1000 बन जाता है) और escape forms (\u4e2d असली अक्षर बन जाता है) खो देता है। एक field बदलते हुए बाकी सब अक्षुण्ण रखने के लिए jsonc-parser में modify और applyEdits जैसे editing-style API चाहिए।