CSV, Excel या JSON: 10,000 पंक्तियों की एक टेबल पर नापकर देखा

छोटा जवाब

सपाट टेबल के लिए सबसे छोटी टेक्स्ट फाइल CSV ने बनाई: हमारी 10,000 पंक्तियों के लिए 1.2 MB। वही पंक्तियां इंडेंट वाली JSON में 2.7 MB और NDJSON में 2 MB की हुईं। ZIP करने पर CSV और JSON करीब आ गए: 357 KB बनाम 398 से 424 KB।

बड़े फर्क वापसी में दिखे। डिफॉल्ट सेटिंग पर Excel से होकर या JSON से होकर लौटने पर 1,00,000 में से 10,960 सेल बदले, और दोनों रास्तों पर अलग-अलग सेल। एक सेटिंग ने Excel से होकर लौटना बिल्कुल सटीक बना दिया। नेस्टेड फील्ड सिर्फ JSON ने बचाए: CSV या स्प्रेडशीट से गुजरने के बाद वे कभी वापस नहीं आए। इसलिए फॉर्मेट इस हिसाब से चुनें कि फाइल आगे कौन पढ़ेगा।

हमने कैसे नापा

21 अक्टूबर 2026 को हमने एक स्क्रिप्ट से टेस्ट टेबल बनाई: बनावटी डेटा की 10,000 पंक्तियां और 10 कॉलम। इसमें 000001 जैसे शुरुआती शून्य वाले ID, 13 अंकों के बारकोड और 19 अंकों के अकाउंट नंबर हैं। इसमें ISO तारीखें और दो दशमलव वाली रकम भी हैं, जिनमें से लगभग आधी ऋणात्मक हैं। नामों में लैटिन, एक्सेंट वाले और सिरिलिक अक्षर मिले-जुले हैं, और हर सौवीं पंक्ति में एक इमोजी है। सौ में से एक नोट में कॉमा, कोट और लाइन ब्रेक है। कूपन वाला कॉलम 3,096 पंक्तियों में खाली है, और हर फोन नंबर प्लस के चिह्न से शुरू होता है।

हमने उसे pulsarkit.com के छह कन्वर्टर से गुजारा: CSV से Excel, “Excel से CSV”, “CSV से JSON”, “JSON से CSV”, “Excel से JSON” और “JSON से Excel”। हमने 2023 के MacBook पर Chrome 155 इस्तेमाल किया। छहों ब्राउजर टैब के अंदर काम करते हैं, और जिस सेटिंग का हम नाम न लें, वह डिफॉल्ट पर रही। समय बटन दबाने से लेकर “डाउनलोड करें” बटन आने तक नापा गया। फिर हमारी अपनी स्क्रिप्ट ने लौटे हर सेल की तुलना मूल से की, और हमने हर वर्कबुक के अंदर सेल के टाइप पढ़े। ZIP वाले साइज एक सामान्य ZIP से हैं, लेवल 6 पर Deflate।

साइज, ZIP में साइज और स्पीड

CSV कॉलम के नाम एक बार, सबसे ऊपर लिखता है। JSON उन्हें हर रिकॉर्ड में दोहराता है। दो स्पेस के अपने डिफॉल्ट इंडेंट के साथ “CSV से JSON” ने टेबल को 2.7 MB का बना दिया, यानी CSV का 2.3 गुना। NDJSON, जिसमें हर लाइन में एक सटा हुआ रिकॉर्ड होता है, 2 MB का निकला। “मिनिफाई करें” पर सेट “JSON फॉर्मेटर” ने इंडेंट वाली फाइल को भी 2 MB का कर दिया, यानी 23.6% कम।

ZIP इस अंतर का ज्यादातर हिस्सा मिटा देता है, क्योंकि दोहराई गई कुंजियां ठीक वही चीज हैं, जिसे कंप्रेशन सबसे अच्छी तरह दबाता है। ZIP करने पर CSV 357 KB, NDJSON 398 KB और इंडेंट वाली JSON 424 KB की हुई।

XLSX फाइल पहले से ही एक ZIP है, इसलिए उसका साइज इस पर निर्भर है कि उसे कौन-सा प्रोग्राम लिखता है। “CSV से Excel” की बनाई शीट LibreOffice Calc से दोबारा सेव करने पर 753 KB की रही। जब सिर्फ साइज मायने रखता हो, तो ZIP की हुई CSV भेजें।

स्पीड से फॉर्मेट में कोई फर्क नहीं पड़ा। हमने 60 बार समय नापा, और 10,000 पंक्तियों के कन्वर्जन का मीडियन लगभग एक-तिहाई सेकंड रहा। इनमें से 49 बार आधे सेकंड से कम लगा। सबसे धीमे, हमारे सेशन के पहले “Excel से CSV” में 2 सेकंड लगे।

बदलकर वापस लाने पर क्या बदला

Excel से होकर: पहले “CSV से Excel”, फिर “Excel से CSV”। शुरुआती शून्य, 19 अंकों के अकाउंट, बारकोड, नोट के अंदर के लाइन ब्रेक, इमोजी और खाली सेल, सब वैसे ही लौटे, जैसे थे। दो कॉलम बदले। हर true और false, TRUE और FALSE बनकर लौटा, क्योंकि वर्कबुक उन्हें लॉजिकल वैल्यू के रूप में रखती है। और 960 रकमों का आखिरी शून्य चला गया, इसलिए 612.40 बना 612.4: वर्कबुक नंबर रखती है, यह नहीं कि वह कैसे लिखा गया था।

JSON से होकर: पहले CSV से JSON, फिर JSON से CSV। उन्हीं 960 रकमों का आखिरी शून्य, उसी वजह से, चला गया। हर फोन नंबर आगे एक एपॉस्ट्रॉफी के साथ लौटा, जैसे '+1 202 555 0117। “JSON से CSV” हर उस वैल्यू के आगे एपॉस्ट्रॉफी लगाता है, जो +, =, - या @ से शुरू होती है और सादा नंबर नहीं है। इस तरह स्प्रेडशीट उसे फॉर्मूला मानकर चला नहीं सकती। JSON में खाली सेल खाली स्ट्रिंग बने, जबकि Excel से JSON ने उन्हीं 3,096 सेल के लिए null लिखा। आपको कौन-सी JSON मिलेगी, यह रास्ते पर निर्भर है, जब तक आप “CSV से JSON” में “खाली सेल की जगह” को null पर न करें।

जिस ब्राउजर में UTC या UTC+4 सेट था, उसमें हर तारीख “CSV से Excel” से बिना बदले निकली। “CSV से Excel” हर तारीख को UTC की आधी रात के रूप में लिखता है, इसलिए New York के समय वाला ब्राउजर भी उसे नहीं खिसकाता।

Excel वाले रास्ते का हर बदलाव एक सेटिंग ने हटा दिया: “CSV से Excel” में “सेल के टाइप” को “सब कुछ टेक्स्ट के रूप में” पर करना। New York के समय में भी और UTC+4 में भी, तब वापसी में सभी 1,00,000 सेल ठीक वैसे लौटे, जैसे लिखे गए थे। कीमत यह है कि शीट में सारे सेल टेक्स्ट होते हैं, रकम भी। बारकोड के लिए भी टेक्स्ट ठीक है। डिफॉल्ट सेटिंग पर हमारे 13 अंकों के कोड General फॉर्मेट में नंबर बन गए। Microsoft का डॉक्यूमेंटेशन कहता है कि General फॉर्मेट 12 या उससे ज्यादा अंकों वाले नंबर साइंटिफिक नोटेशन में दिखाता है।

नेस्टेड डेटा वापस नहीं आता

असली JSON शायद ही कभी सपाट होती है, इसलिए हमने हर रिकॉर्ड को एक address ऑब्जेक्ट और टैग की एक लिस्ट दी: इंडेंट के साथ 3.8 MB। “JSON से CSV” ने address को address.city और address.zip नाम के कॉलम में फैला दिया, और टैग को एक सेल में जोड़ दिया, जैसे new, wholesale। “JSON से Excel” ने भी यही किया।

वापस JSON में बदलने पर किसी भी फाइल को अपना पुराना ढांचा नहीं मिला। दोनों ने address.city जैसी सपाट कुंजियां दीं, और लिस्ट की जगह tags की एक स्ट्रिंग। CSV वाले रास्ते ने टाइप भी बदले: 10,000 में से 6,017 ZIP कोड, यानी 78701 जैसे बिना शुरुआती शून्य वाले, नंबर बनकर लौटे, जबकि 02134 टेक्स्ट रहा। उसी रास्ते पर खाली कूपन, जो हमारी फाइल में null थे, खाली स्ट्रिंग बनकर लौटे। Excel वाले रास्ते ने हर ZIP कोड को टेक्स्ट और हर null को null ही रखा।

कौन-सा फॉर्मेट चुनें

अगर कोई व्यक्ति डेटा को सॉर्ट और फिल्टर करेगा और उसका जोड़ लगाएगा, तो XLSX लें। यह रकम को नंबर, तारीख को तारीख और true या false को लॉजिकल वैल्यू के रूप में रखता है। अगर फाइल कोई प्रोग्राम पढ़ेगा, तो JSON लें। यह नंबर, true, false और null रखता है, और तीनों में यही अकेला फॉर्मेट है, जो नेस्टेड फील्ड रखता है। NDJSON का साइज मिनिफाई की हुई JSON जितना है, और यह हर लाइन में एक रिकॉर्ड रखता है।

अगर फाइल सिर्फ एक सिस्टम से दूसरे सिस्टम तक जाती है, तो ZIP की हुई CSV तीनों में सबसे छोटी है। Excel तक पहुंचते हुए सेपरेटर, एनकोडिंग और बाइट ऑर्डर मार्क अब भी CSV को बिगाड़ सकते हैं। हमारी गाइड CSV से Excel और वापस: डेटा बिगाड़े बिना कैसे कन्वर्ट करें इन सब पर बात करती है।