डेटा · 4 मिनट में पढ़ें ·

JSON से CSV, बिना एक भी फ़ील्ड खोए

नेस्टेड key, वैकल्पिक फ़ील्ड और टेक्स्ट के अंदर कॉमा: 4Dev उलझे हुए JSON को स्प्रेडशीट के लिए तैयार CSV में कैसे बदलता है।

स्प्रेडशीट सपाट होती है, JSON नहीं। JSON को CSV में बदलते समय हर बार तय करना पड़ता है कि नेस्टेड ऑब्जेक्ट, array और सिर्फ़ कुछ रिकॉर्ड में मौजूद key के साथ क्या किया जाए। 4Dev का कन्वर्टर ठीक यही करता है।

हर key को अपना कॉलम मिलता है

हेडर पंक्ति सिर्फ़ पहले रिकॉर्ड से नहीं, बल्कि सभी ऑब्जेक्ट की key से बनती है, उसी क्रम में जिसमें वे पहली बार आती हैं। जिस रिकॉर्ड में कोई key नहीं है, उसे खाली सेल मिलता है, इसलिए कॉलम कभी खिसकते नहीं और वैकल्पिक फ़ील्ड कभी गायब नहीं होते।

[{"id":1,"name":"Ada"},
 {"id":2,"name":"Alan","note":"optional"}]

id,name,note
1,Ada,
2,Alan,optional

नेस्टेड ऑब्जेक्ट अंडरस्कोर वाले कॉलम बन जाते हैं

ऑब्जेक्ट को उनकी key अंडरस्कोर से जोड़कर सपाट किया जाता है, इसलिए {"address":{"city":"Lisbon"}} address_city नाम का कॉलम बन जाता है। साधारण वैल्यू वाला array एक ही सेल में जाता है ("admin, dev"), और ऑब्जेक्ट वाला array अपने सेल में JSON टेक्स्ट के रूप में रहता है, यानी कुछ भी नहीं छूटता।

कॉमा और कोटेशन मार्क अपने-आप escape होते हैं

जिस भी वैल्यू में कॉमा, डबल कोट या नई लाइन हो, उसे डबल कोट में रखा जाता है और अंदर के कोट दोहरे कर दिए जाते हैं। यही CSV का मानक नियम है जिसकी Excel और Google Sheets उम्मीद करते हैं।

2,"Alan, T.","says ""hi"""

CSV को Excel में खोलना

CSV की अपनी कोई सेटिंग नहीं होती, इसलिए Excel अंदाज़ा लगाता है। दो चीज़ें अक्सर बिगड़ती हैं। जिन देशों में दशमलव के लिए कॉमा इस्तेमाल होता है, वहाँ Excel कॉलम के बीच सेमीकोलन की उम्मीद करता है और पूरी लाइन एक ही सेल में डाल सकता है। और अगर फ़ाइल UTF-8 की जगह लोकल एन्कोडिंग में खुले, तो हिंदी, हिब्रू, एक्सेंट वाले अक्षर या इमोजी अजीब सिंबल बन सकते हैं। दोनों हालात में Excel में Data → From Text/CSV इस्तेमाल करें, UTF-8 और कॉमा डिलिमिटर चुनें, और कॉलम सही आएँगे।

शुरुआती शून्य और लंबे नंबर

स्प्रेडशीट नंबर जैसी दिखने वाली हर चीज़ को नंबर मानती हैं। 01234 जैसा पिन कोड अपना शुरुआती शून्य खो देता है, और 1234567890123456 जैसा 16 अंकों का ID राउंड होकर 1.23457E+15 दिखता है। CSV ख़ुद सही है; नुक़सान तब होता है जब Excel उसे खोलता है। ऐसे कॉलम को टेक्स्ट के रूप में इम्पोर्ट करें, और लंबे ID को JSON में स्ट्रिंग के रूप में भेजें ("id": "1234567890123456"), ताकि हर टूल उन्हें बिलकुल वैसा ही रखे।

रिकॉर्ड के अंदर ऐरे

किसी भी कन्वर्ज़न का सबसे मुश्किल हिस्सा ऐरे होते हैं, क्योंकि एक रिकॉर्ड में कई वैल्यू हो सकती हैं जबकि CSV की लाइन में हर कॉलम के लिए एक ही सेल होता है। उन्हें कई लाइनों में फैलाने से बाकी सारे फ़ील्ड दोहराए जाएँगे, और नंबर वाले कॉलम (tags_1, tags_2…) में फैलाने से हर फ़ाइल का हेडर अलग बनेगा। सादी वैल्यू की सूची एक सेल में और ऑब्जेक्ट के ऐरे को JSON टेक्स्ट के रूप में रखने से हर रिकॉर्ड ठीक एक लाइन बना रहता है, और ज़रूरत पड़ने पर ओरिजिनल डेटा दोबारा बनाया जा सकता है।

शेयर करने से पहले नतीजा जाँचें

  • लाइनों की संख्या JSON ऐरे के रिकॉर्ड की संख्या के बराबर है।
  • हेडर में हर अपेक्षित फ़ील्ड है, वैकल्पिक फ़ील्ड भी।
  • नेस्टेड फ़ील्ड अंडरस्कोर वाले कॉलम के रूप में दिखते हैं, जैसे address_city।
  • कॉमा, कोट्स या लाइन ब्रेक वाली वैल्यू एक ही सेल में रहीं।

स्प्रेडशीट चाहिए या उलटी दिशा?

4Dev का JSON से CSV कन्वर्टर हर बार फ़्लैटनिंग के वही नियम लागू करता है, और JSON से Excel और CSV से JSON टूल बाक़ी आम मामलों को संभालते हैं। जल्दी जाँच के लिए पहले कुछ रिकॉर्ड पेस्ट करें, कॉलम देखें, फिर पूरी फ़ाइल कन्वर्ट करें।

JSON से CSV कन्वर्टर खोलें

LinkedInXFacebook