JSON को CSV में बदलें

कुछ भी बदलने से पहले यही समझ लेना ज़रूरी है। JSON एक पेड़ बयान करता है: कोई ऑब्जेक्ट किसी और ऑब्जेक्ट को रख सकता है, जो ऑब्जेक्ट की सूची रख सकता है, किसी भी गहराई तक। CSV एक जाली बयान करता है: पंक्तियाँ और कॉलम, और किसी सेल के भीतर कुछ नहीं।

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

नेस्टेड ऑब्जेक्ट कुंजी-नामों को जोड़कर चपटा किया जाता है, तो city वाले customer ऑब्जेक्ट से एक कॉलम बनता है जिसका नाम दोनों को जोड़ता है। एक स्तर की नेस्टिंग से हर कोई पढ़ सके ऐसी तालिका बनती है। दो स्तर भी आमतौर पर ठीक रहते हैं।

उससे आगे यह तेज़ी से बिगड़ती है: कॉलम-नाम लंबे हो जाते हैं, तालिका बहुत चौड़ी हो जाती है, और ज़्यादातर पंक्तियों के ज़्यादातर सेल ख़ाली रहते हैं क्योंकि अलग-अलग रिकॉर्ड अलग तरह से नेस्ट होते हैं। अगर किसी साधारण दिखने वाले निर्यात से साठ कॉलम निकलें, तो यह डेटा की असली शक्ल है, कन्वर्ज़न की ख़ामी नहीं।

तीन टैग, चार लाइन-आइटम या पिछले पतों की सूची वाले किसी रिकॉर्ड का तालिका में कोई सही रूप है ही नहीं। तीन आम जवाब हैं और हर एक किसी न किसी काम के लिए ग़लत है: हर स्थान के लिए एक कॉलम, जो पाँच वाले रिकॉर्ड पर टूट जाता है; एक कॉलम जिसमें मान जोड़कर रखे गए हों, जो उन मानों में वही अलगाव-चिह्न होने पर पढ़ा नहीं जा सकता; या सरणी के हर सदस्य के लिए एक पंक्ति, जो मूल रिकॉर्ड को दोहराती है।

जब सरणी ही अर्थ रखती है — लाइन-आइटम वाला कोई ऑर्डर, टिप्पणियों वाली कोई पोस्ट — तो ईमानदार जवाब है कि उसे न बदला जाए। JSON ही रखिए, या किसी डेटाबेस की तरह दो तालिकाएँ बनाइए — एक ऑर्डर के लिए, एक लाइन-आइटम के लिए, किसी पहचानकर्ता से जुड़ी हुई।

JSON निर्यात के रिकॉर्ड एक जैसी कुंजियाँ रखने को बाध्य नहीं। कोई API जो फ़ील्ड मौजूद हैं उन्हें लौटाता है और जो नहीं उन्हें छोड़ देता है, तो सौ रिकॉर्ड अस्सी अलग-अलग शक्लें दिखा सकते हैं।

कन्वर्ज़न इसे रिकॉर्ड में देखकर पूरा कॉलम-सेट बनाकर सुलझाता है, और जहाँ किसी रिकॉर्ड में मान नहीं होता वहाँ सेल ख़ाली छोड़ देता है। यही आम आश्चर्य बताता है — दस रिकॉर्ड के नमूने को बदलने से पूरी फ़ाइल बदलने से कम कॉलम बनते हैं, क्योंकि नमूने में दुर्लभ फ़ील्ड नहीं थे।

सही CSV बनाना उसे आगे होने वाली चीज़ों से नहीं बचाता। Excel हर कॉलम का प्रकार अंदाज़े से तय कर खोलता है, जो पहचान-संख्याओं के आगे के शून्य हटा देता है, तारीख़ जैसी दिखने वाली किसी भी चीज़ को तारीख़ बना देता है, और पंद्रह अंकों से आगे के पहचानकर्ता काट देता है।

इलाज हमेशा एक जैसा है — खोलने के बजाय आयात कीजिए: Data फिर From Text/CSV, और लोड होने से पहले पहचानकर्ता कॉलम को Text सेट कीजिए। अगर प्राप्तकर्ता कोई प्रोग्राम नहीं इंसान है, तो XLSX में बदलना अंदाज़ा लगाने की झंझट पूरी तरह हटा देता है।

जब डेटा सपाट रिकॉर्ड हो और मंज़िल कोई स्प्रेडशीट, डेटाबेस-आयात, सांख्यिकी औज़ार या सहकर्मी हो, तब बदलिए। यह ज़्यादातर एनालिटिक्स प्लैटफ़ॉर्म, CRM, फ़ॉर्म-बिल्डर और रिपोर्टिंग API के निर्यातों को कवर करता है, और उन सबके लिए CSV, JSON से आसान होती है।

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

AI सेवाओं के डेटा निर्यात अब सबसे आम वजह हैं कि कोई JSON फ़ाइल खोले, और ChatGPT का संग्रह सबसे सामान्य है। इसकी conversations.json पंक्तियों की सूची नहीं — यह संदेश-वृक्षों का समूह है, हर नोड अपने पैरेंट की ओर इशारा करता हुआ, यही तरीक़ा है शाखाओं वाली और संपादित बातचीत को दर्शाने का। इसके भीतर कोई ईमानदार जाली है ही नहीं।

इसे CSV में बदलना तकनीकी रूप से सही और व्यावहारिक रूप से बेकार कुछ बनाता है — हर नोड के लिए एक पंक्ति, थ्रेड का ढाँचा गायब। अगर मक़सद बातचीत पढ़ना है, संग्रह में साथ आई HTML फ़ाइल ही खोलिए। CSV उन चपटे निर्यातों के लिए सही मंज़िल है, जैसे उपयोग और बिलिंग रिकॉर्ड, जहाँ हर प्रविष्टि सचमुच एक पंक्ति है।

कोई JSON सरणी पूरी होने पर ही पार्स हो सकती है, क्योंकि आख़िरी कोष्ठक ही उसे मान्य बनाता है। तो बहुत बड़ी फ़ाइल को पूरा पढ़ना ही पड़ता है, और यह किसी औज़ार की नहीं, फ़ॉर्मेट की सीमा है।

अगर डेटा कैसे बनता है यह आपके हाथ में है, एक बड़ी सरणी के बजाय NDJSON — हर पंक्ति में एक पूरा JSON ऑब्जेक्ट — माँगिए। इसे भी यहाँ पूरा पढ़ना पड़ता है, सरणी जैसे ही, पर हर पंक्ति अलग से पार्स होती है: कोई टूटी या अधूरी पंक्ति अपने ही पंक्ति-नंबर के साथ नाकाम होती है, पूरे दस्तावेज़ को बेकार किए बिना।

कन्वर्ज़न आपके ब्राउज़र में, आपके अपने प्रोसेसर पर चलता है। फ़ाइल कहीं भेजी नहीं जाती, कोई खाता और कोई दैनिक सीमा नहीं, और 100 MB तक की फ़ाइल टैब में ही सँभल जाती है।

यह ज़्यादातर कन्वर्ज़न से यहाँ ज़्यादा मायने रखता है। JSON निर्यात लगभग हमेशा किसी API का कच्चा नतीजा होता है — ग्राहक रिकॉर्ड, ऑर्डर इतिहास, फ़ॉर्म प्रविष्टियाँ, खाते — और इसमें अक्सर ऐसे फ़ील्ड होते हैं जिनके बारे में किसी ने सोचा ही नहीं। इसे कहीं न भेजना ही सबसे सीधा जवाब है।