JSON से CSV

JSON मनमाने ढंग से नेस्टेड, ट्री-फ़ॉर्म डेटा दर्शाने के लिए बना है — ऑब्जेक्ट के अंदर ऑब्जेक्ट, ऑब्जेक्ट के अंदर एरे, साथ-साथ रखी वाक़ई अलग टाइप की वैल्यू — जबकि CSV सिर्फ़ एक सपाट, एक जैसी टेबल दर्शा सकता है: पंक्तियाँ और कॉलम, हर पंक्ति में कॉलम का एक जैसा सेट, हर सेल एक सादी वैल्यू। पहले फ़ॉर्म से दूसरे में बदलने का मतलब ज़रूरी तौर पर यह तय करना है कि किसी ऐसी चीज़ को कैसे चपटा किया जाए जो पंक्तियों और कॉलम में स्वाभाविक रूप से फ़िट नहीं होती, जो इस तरह के कन्वर्ज़न की ज़्यादातर असली जटिलता का घर है — ख़ुद JSON सिंटैक्स पढ़ने में नहीं, जो सीधा है, बल्कि यह तय करने में कि किसी स्प्रेडशीट पंक्ति का ऐसे डेटा के लिए मतलब ही क्या होना चाहिए जो शुरुआत में कभी टेबुलर था ही नहीं।

`{"user": {"name": "Ada", "id": 42}}` जैसे किसी नेस्टेड ऑब्जेक्ट का कोई एक साफ़ कॉलम नहीं है जिसमें यह सपाट टेबल बन सके, तो यह दो अलग कॉलम में चपटा होता है — `user.name` और `user.id` — डॉट नोटेशन बिल्कुल दर्शाते हुए कि हर वैल्यू मूल संरचना में कहाँ से आई। यह एक व्यापक रूप से पहचानी परंपरा है ख़ास तौर पर इसलिए क्योंकि यह पलटने लायक़ है: `user.name` नाम का कोई कॉलम बिना किसी अस्पष्टता के किसी नेस्टेड संरचना का रास्ता बताता है, जो मायने रखता है अगर CSV को कभी वापस JSON में बदलना हो या डॉट वाले पाथ को नेस्टेड फ़ील्ड के रूप में समझने वाले किसी सिस्टम में इम्पोर्ट करना हो।

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

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