CSV से JSON

CSV पार्स करना मामूली लगता है — हर लाइन को कॉमा से बाँटना, पहली लाइन को हेडर मानना — जब तक असली डेटा में किसी वैल्यू में अपना कॉमा न हो, जो असली स्प्रेडशीट एक्सपोर्ट में लगातार होता है: "123 Main St, Apt 4" जैसा पता, "Smith, Jones & Co" जैसा कंपनी नाम, या किसी लिस्ट रखने वाला प्रोडक्ट विवरण। CSV स्पेसिफ़िकेशन, जिसे RFC 4180 के रूप में औपचारिक बनाया गया है, इसे किसी फ़ील्ड को डबल कोट में लपेटने की अनुमति देकर संभालती है, जिसके अंदर कॉमा, लाइन ब्रेक और यहाँ तक कि लिटरल कोटेशन कैरेक्टर (उन्हें दोहराकर एस्केप किया गया) संरचना की बजाय सिर्फ़ डेटा होते हैं। कोई पार्सर जो हर कॉमा पर भोलेपन से बाँटता है, कोटेशन को पूरी तरह नज़रअंदाज़ करते हुए, ठीक उन्हीं पंक्तियों को बिगाड़ देता है — "Smith, Jones & Co" को दो अलग कॉलम में बाँटते हुए — और आमतौर पर यह चुपचाप करता है, बिना कोई एरर दिए कि कुछ ग़लत हुआ, जो इस ग़लती को सिर्फ़ परेशान करने वाली की बजाय ख़तरनाक बनाती है।

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

कच्ची CSV फ़ाइल में हर वैल्यू टेक्स्ट है, क्योंकि CSV में नंबर, बूलियन, या नल की कोई नेटिव अवधारणा नहीं है — `42` रखने वाला सेल और `hello` रखने वाला सेल एक जैसे कैरेक्टर के रूप में स्टोर होते हैं। टाइप इंफ़रेंस यह अंदाज़ा लगाने की प्रक्रिया है कि कौन सी स्ट्रिंग "असल में" नंबर, ट्रू/फ़ॉल्स वैल्यू, या नल बनने के लिए थीं, और नतीजे में मिले JSON को उसके हिसाब से कन्वर्ट करना ताकि सब कुछ स्ट्रिंग की तरह कोट में लिपटे होने की बजाय असल में टाइप की गई वैल्यू हों।

हालाँकि, अंदाज़ा रूढ़िवादी होना ज़रूरी है, क्योंकि कई ऐसी वैल्यू जो नंबर जैसी दिखती हैं वे बिल्कुल भी नंबर के रूप में इस्तेमाल होने के लिए नहीं थीं। कोई शुरुआती शून्य — `007`, `042` — आमतौर पर कोई आइडेंटिफ़ायर या पैडेड कोड दर्शाता है जहाँ शुरुआती शून्य मायने रखता है और नंबर में बदलने पर चुपचाप नष्ट हो जाएगा, क्योंकि `7` और `007` एक जैसा नंबर हैं लेकिन बहुत अलग आइडेंटिफ़ायर। `+44 20 7946 0958` जैसा फ़ोन नंबर आंशिक रूप से संख्यात्मक दिखता है लेकिन गणितीय डेटा नहीं है। JavaScript की सुरक्षित इंटीजर रेंज से बाहर की वैल्यू नंबर में बदलने पर सटीकता खो देती हैं। यह टूल इन सबको ख़ास तौर पर स्ट्रिंग के रूप में छोड़ता है क्योंकि यहाँ ग़लत अंदाज़ा लगाने का मतलब है डेटा को इस तरह चुपचाप बिगाड़ना जिसे बहुत बाद तक नज़रअंदाज़ करना आसान हो।

किसी JSON ऑब्जेक्ट में एक जैसे नाम की दो कुंजियाँ नहीं हो सकतीं — दूसरी मिली कुंजी बस पहली को ओवरराइट कर देती है, कहीं भी कोई एरर उठाए बिना पूरे कॉलम की वैल्यू चुपचाप छोड़ते हुए। स्प्रेडशीट एक्सपोर्ट संभावना से कहीं ज़्यादा बार डुप्लीकेट हेडर बनाते हैं: अलग-अलग स्कोप वाले दो "Total" कॉलम वाली कोई रिपोर्ट, या दो स्रोतों से मिली कोई फ़्यूज़ की गई एक्सपोर्ट जहाँ इत्तेफ़ाक़न दोनों "Name" इस्तेमाल करते हैं। डुप्लीकेट पहचानना और दूसरी मौजूदगी का नाम बदलकर `name_2` करना हर कॉलम का डेटा बरक़रार रखता है बजाय पंक्ति ऑब्जेक्ट में पहले आने वाले किसी को चुपचाप खोने के। ख़ाली हेडर को उसी वजह से वही व्यवहार मिलता है, क्योंकि JSON के पास सिर्फ़ एक ख़ाली स्ट्रिंग वाली कुंजी को कोई मायने वाली और पहुँचने लायक़ फ़ील्ड के रूप में दर्शाने का कोई तरीक़ा नहीं है।