Sj.h: लगभग 150 लाइनों के C99 में लिखा गया एक बेहद छोटा JSON parsing लाइब्रेरी

• Sj.h लगभग 150 लाइनों का एक अत्यंत हल्का JSON parser है, जिसे C99 आधारित environments में इस्तेमाल किया जा सकता है
• इसमें zero memory allocation और minimal state जैसी विशेषताएं हैं, इसलिए यह हल्के embedded environments या कम dependencies वाली स्थितियों के लिए उपयुक्त है
• यह number और string parsing को सीधे संभालने के बजाय ऐसा तरीका अपनाता है, जिससे उपयोगकर्ता संबंधित processing अपनी जरूरत के अनुसार स्वतंत्र रूप से implement कर सके
• line:column आधारित error messages के समर्थन से debugging के दौरान readability और location पहचान बेहतर होती है
• यह public domain software है, इसलिए कोई भी इसे स्वतंत्र रूप से इस्तेमाल, संशोधित और वितरित कर सकता है

---

प्रोजेक्ट परिचय

• Sj.h एक C99 header file है, जो अतिरिक्त features या अनावश्यक memory allocation के बिना सिर्फ न्यूनतम कोड से JSON parsing की सुविधा देता है
• पूरा implementation लगभग 150 लाइनों का है, इसलिए यह embedded systems, tools, या ऐसे मामलों के लिए उपयुक्त है जहाँ external library dependencies को कम रखना हो

मुख्य विशेषताएं

• zero-allocations और minimal state के साथ काम करता है, इसलिए memory overhead बहुत कम है
• line:column जानकारी वाले error messages parsing के दौरान होने वाली समस्याओं की स्थिति समझना आसान बनाते हैं
• number parsing built-in रूप से उपलब्ध नहीं है; उपयोगकर्ता strtod, atoi आदि अपनी पसंद के तरीके इस्तेमाल कर सकते हैं
• string parsing भी उपयोगकर्ता स्वयं implement कर सकते हैं, और जरूरत के अनुसार Unicode surrogate pair handling जैसी चीजें जोड़ सकते हैं
• पूरा source code public domain (Unlicense) में उपलब्ध है, इसलिए license जैसी पाबंदियों के बिना इसका उपयोग और संशोधन किया जा सकता है

उपयोग उदाहरण

• JSON string को Rect struct में parse करने का एक सरल उदाहरण दिया गया है

  char *json_text = "{ \"x\": 10, \"y\": 20, \"w\": 30, \"h\": 40 }";  
  typedef struct { int x, y, w, h; } Rect;  
  ...  
  

• sj_Reader, sj_Value, sj_reader, sj_read, sj_iter_object जैसे सरल और स्पष्ट API इस्तेमाल किए जाते हैं
• numeric value parsing और key-value comparison उपयोगकर्ता को स्वयं implement करने होते हैं; built-in सुविधा नहीं दी गई है
• demo folder में कई अतिरिक्त उपयोग उदाहरण देखे जा सकते हैं

लाइसेंस

• Sj.h एक public domain software है, जिसे कोई भी बिना किसी प्रतिबंध के इस्तेमाल कर सकता है
• अधिक जानकारी के लिए LICENSE file देखें

अन्य

• code और folder structure सरल हैं, इसलिए बिना किसी अलग configuration या build प्रक्रिया के इसे तुरंत इस्तेमाल किया जा सकता है
• यह स्वतंत्र है, external dependencies नहीं हैं, और मुख्य रूप से उन environments के लिए उपयुक्त है जहाँ हल्कापन और ease of use महत्वपूर्ण हों

[GN⁺]

Hacker News राय

• मुझे इस लेखक का काम पसंद आने की वजह यह है कि ज़्यादातर single-file libraries ANSI C या Lua में लिखी गई हैं, दायरा साफ़ रखती हैं, इस्तेमाल में आसान interface और बढ़िया documentation देती हैं, और free software license भी अच्छा लगता है। इस प्रोजेक्ट के अलावा इनके कुछ और काम भी मुझे पसंद हैं: log.c (सरल C99 logging library), microui (बहुत छोटी immediate-mode UI library), fe (embed की जा सकने वाली छोटी language), microtar (हल्की tar library), cembed (files को C header में embed करने का tool), ini (.ini config files के लिए lightweight library), json.lua (Lua के लिए lightweight JSON library), lite (Lua में बना lightweight text editor), cmixer (games के लिए portable audio mixer), uuid4 (C में लिखी छोटी uuid4 library)
  • मैं अपने C projects में लगभग हर बार log.c शामिल कर लेता हूँ। मुझे पता ही नहीं था कि लेखक ने इतनी सारी libraries बनाई हैं। log.c सच में इस्तेमाल करने में बहुत आसान है, इसलिए मैं इसकी सिफारिश कर सकता हूँ
  • जब मैं LOVE2D से game बनाता था तब Lume library इस्तेमाल करता था। मैंने लेखक को IRC chat room में कुछ बार देखा भी है, और एक बार उनकी किसी idea को बुरा कह दिया था, लेकिन बाद में देखा तो वह अच्छा idea निकला। https://github.com/rxi/lume देखने लायक है
  • यह open source तो है, लेकिन असली free software नहीं है
• यह library इन lines में signed integer overflow check नहीं करती: L89, L149, L150। कुछ input values पर undefined behavior हो सकता है
  • कुछ developers को simple single-header C library culture पसंद है; Tsoding जैसे streamers इसका उदाहरण हैं। लोग जानते हैं कि ऐसी libraries security या functionality पर फ़ोकस नहीं करतीं। हर project ऐसा business-grade software नहीं होता जो हज़ारों customers के सामने expose हो, इसलिए यह तरीका भी ठीक हो सकता है
  • edge case को पूरी तरह handle करने वाली libraries के bloat पर एक अच्छा लेख है, और इस पर चर्चा भी है। हर error को handle करने की कोशिश करने पर complexity बहुत तेज़ी से बढ़ती है। कभी-कभी यह library की ज़िम्मेदारी भी नहीं होती
  • अगर nesting level 2 अरब से ज़्यादा हो, या दूसरे case में line count 2 अरब से ऊपर चला जाए, तब UB हो सकता है। अगर JS input को 1GB तक सीमित कर दें, तो उसके ऊपर वैसे भी stack के दूसरे हिस्सों में बड़े problems आएँगे। अगर मुझे 2GB से बड़े JSON को process करना हो तो source code में सारे int को 64-bit कर दूँगा। फिर भी अगर input 2^64 से ऊपर गया तो अंततः सब टूटेगा। मैं code में हर जगह int overflow manually check नहीं करूँगा
  • int 32-bit होने की वजह से समस्या तभी होगी जब हर line पर 2 अरब depth की nesting हो, या file 2 अरब lines से ज़्यादा हो, या किसी एक line में 2 अरब से ज़्यादा characters हों
  • मुझे नहीं लगता कि यह library production में इस्तेमाल की जा सकती है
• यह library काफ़ी permissive है। मैं यह नहीं कहूँगा कि यह तरीका बुरा है, लेकिन जो लोग code देखे बिना इसे इस्तेमाल करेंगे उन्हें सावधान रहना चाहिए। शायद यही इसकी इतनी छोटी होने की मुख्य वजह भी है। README के demo example में यह इस तरह काम करती है:<br><code>{"x",10eee"y"22:5,{[:::,,}]"w"7"h"33<br>rect: { 10, 22, 7, 33 }</code>
  • parser आम तौर पर मानकर चलता है कि input valid है। validation एक अलग समस्या है जिसे यह library cover नहीं करती। आख़िरकार यह library data extract करने का काम करती है
  • तो क्या इसलिए यह गलत है?
• मुझे लगता है JSON parser libraries कुल मिलाकर दर्द का black hole हैं। हर एक का use case अलग होता है, और वे अक्सर जटिल abstractions से भरी होती हैं; कई बार दोनों बातें साथ में सच होती हैं। सच कहें तो अगर किसी खास उद्देश्य के लिए ज़रूरी हिस्सा ही implement करना हो, तो यह इतना मुश्किल मसला भी नहीं है
  • यह देखकर हैरानी होती है कि modern JSON libraries कितनी complex हो जाती हैं। पहले बहुत simple रही nlohmann की C++ single-header JSON library अब<br>* 13 साल पुरानी है<br>* आज भी pull requests सक्रिय रूप से merge हो रहे हैं<br>* 12.2 करोड़ unit tests हैं<br>फिर भी वे खुद मानते हैं कि यह सबसे तेज़ नहीं है। अगर सच में speed चाहिए तो simdjson सुझाते हैं। खुद JSON parser library बनाने का विचार न ही करें तो अच्छा है। 90% हिस्सा 45 मिनट में लिखा जा सकता है, लेकिन बाकी 10% के लिए दस हज़ार लोगों के हज़ारों घंटे लग जाते हैं
  • Parsing JSON is a Minefield (2016) नाम का एक मशहूर resource है https://seriot.ch/projects/parsing_json.html
  • इस library जितना neutral design भी कम ही देखने को मिलता है। यह बस keys और array items को iterate करके लौटाती है, और string-slice के ज़रिए type अलग करके देती है
  • यह project zero-allocation और minimal state storage का दावा करता है, लेकिन strings जैसे सबसे आम types के लिए आख़िरकार allocation चाहिए ही। यह मेरे problem space से काफ़ी अलग तरह का विकल्प है
  • उम्मीद है S-Expressions अभी भी लोगों का प्यार पाते रहेंगे
• दिलचस्प है, लेकिन मैं जानना चाहूँगा कि यह library conformance tests में कितना pass करती है https://github.com/nst/JSONTestSuite
  • validation के लिहाज़ से यह library बहुत strict नहीं लगती। उदाहरण के लिए यह object या array को बंद करने के लिए ']' या '}' दोनों स्वीकार कर लेती है, और '\v' को भी whitespace मानती है, यानी standard से ज़्यादा permissive है। इसे शायद “सही JSON के लिए data extractor” कहना ज़्यादा ठीक होगा। लेकिन अपने हाथ से string या number parser लिखना झंझट भरा हो सकता है, ख़ासकर जब producer के साथ JSON grammar के subset पर सहमति बनानी हो
  • मुझे लगता है कि real implementations के आधार पर conformance tests बनाना बहुत उपयोगी होगा। यानी ऐसा test-set जो किसी खास parsing library के subset/superset behavior से बिल्कुल मेल खाए। इससे वह जोखिम टाला जा सकेगा जहाँ दो parsers एक ही JSON को अलग तरह से समझें और vulnerability पैदा हो, जैसे auth bypass
  • यह एक वास्तविक सवाल है: क्या यह nested objects को support करती है?
• यह कुछ आधा-अधूरा parser लगता है, क्योंकि यह numbers को float या int में convert नहीं करता, तो लगता है वह हिस्सा खुद जोड़ना पड़ेगा। फिर भी यह काफ़ी प्रभावशाली है और मैं इसे इस्तेमाल करने पर विचार करूँगा। बस यह बात नोट कर रहा हूँ
• क्या C99 यह निर्दिष्ट करता है कि इस struct को default रूप से 0 से initialize किया जाएगा, या फिर = { 0 } बस छूट गया है? संबंधित code को देखकर लगता है कि r->depth initialize हुए बिना sj__discard_until loop में depth के बराबर संयोग से हो सकता है
  • r->depth यहाँ पहले ही 0 से initialize हो चुका है, संबंधित code देखें
• मैं जानना चाहता हूँ कि ऐसी library का use case क्या है। पहले से इतनी अच्छी JSON libraries मौजूद दिखती हैं; क्या यह educational tool है?
  • इसे existing codebase में जोड़ना आसान है, size overhead कम है, heap allocation नहीं करती, stdlib का भी इस्तेमाल नहीं करती (सिर्फ type definitions के लिए stdbool.h और stddef.h शामिल हैं), C++ template वाला तमाशा नहीं है, और API सीधी-सादी है। इन सब शर्तों को पूरा करने वाली C library सच में बहुत दुर्लभ है, और C++ में तो और भी ज़्यादा
  • बिना overhead और allocation के parsing करना आकर्षक है। बड़े json dump (जैसे Wikidata dumps) से सिर्फ कुछ properties निकालनी हों तो यह उपयोगी हो सकती है
  • embedded CPU पर इसे सीधे इस्तेमाल किया जा सकता है, और अब तो शायद vape जैसी चीज़ों पर भी API server चलाया जा सकता है
  • code छोटा है, इसलिए security-sensitive projects में review करना आसान है, और license compliance भी बहुत सरल है (notice text की ज़रूरत नहीं)
  • beginners के reference के रूप में या simple parsing करने वालों के लिए यह अच्छी codebase हो सकती है। छोटे hobby projects में, जहाँ processor limited हो और code footprint छोटा चाहिए, वहाँ यह काम आ सकती है। हालाँकि ऐसे मामलों में मैं शायद TOML जैसे file format को पसंद करूँगा
• बढ़िया! अगली बार C में JSON parser चाहिए होगा तो मैं इसे देखूँगा। मैं कई सालों से cJSON (https://github.com/DaveGamble/cJSON) अच्छे से इस्तेमाल करता आया हूँ। उससे पहले wjelement (https://github.com/netmail-open/wjelement) इस्तेमाल करता था, लेकिन कुछ समस्याओं की वजह से बाद में बदल दिया (ठीक वजह अब याद नहीं)
• इसे parser कहना थोड़ा खींचतान जैसा लगता है; आम तौर पर यह lexer के ज़्यादा क़रीब दिखता है