JSON ↔ CSV परिवर्तक
JSON को CSV में और CSV को वापस JSON में सीधे अपने ब्राउज़र में बदलें। स्प्रेडशीट के लिए तैयार टेबल पाने हेतु ऑब्जेक्ट का ऐरे पेस्ट करें, या संरचित JSON पाने के लिए CSV पेस्ट करें — डिलिमिटर और हेडर पंक्ति पर पूरे नियंत्रण के साथ।
डिलिमिटर
बदला हुआ नतीजा यहाँ देखने के लिए ऊपर डेटा दर्ज करें।
JSON से CSV परिवर्तक का उपयोग कैसे करें
- 1
एक दिशा चुनें
JSON से CSV या CSV से JSON चुनने के लिए टॉगल का उपयोग करें। स्वैप बटन आपके नतीजे को इनपुट में ले जाता है, ताकि आप दूसरी दिशा में वापस बदल सकें।
- 2
अपना डेटा पेस्ट करें
ऑब्जेक्ट का एक JSON ऐरे, या CSV टेक्स्ट, इनपुट बॉक्स में पेस्ट करें। जैसे ही आप टाइप करते हैं, रूपांतरण अपने आप चलता है।
- 3
विकल्प सेट करें
अपने डेटा से मेल खाने वाला डिलिमिटर चुनें, और CSV पढ़ते समय तय करें कि पहली पंक्ति हेडर है या नहीं और संख्याओं व बूलियन को पार्स करना है या नहीं।
- 4
नतीजा कॉपी करें
बदले हुए आउटपुट को देखें और उसे अपने क्लिपबोर्ड पर कॉपी करें, जो स्प्रेडशीट, डेटाबेस, या आपके कोड में डालने के लिए तैयार रहता है।
JSON ऐरे को स्प्रेडशीट-तैयार CSV में बदलना
मुख्य मैपिंग: ऑब्जेक्ट बनते हैं पंक्तियाँ, कुंजियाँ बनती हैं कॉलम
CSV एक सपाट, द्वि-आयामी ग्रिड है — पंक्तियाँ और कॉलम — जबकि JSON एक वृक्ष है। इसलिए जो रूपांतरण अर्थपूर्ण है वह एक विशिष्ट रूपांतरण है: ऑब्जेक्ट का एक शीर्ष-स्तरीय ऐरे, जहाँ हर ऑब्जेक्ट एक रिकॉर्ड है। हर ऑब्जेक्ट एक अकेली डेटा पंक्ति बन जाता है, और हर ऑब्जेक्ट की सभी कुंजियों का संघ हेडर पंक्ति बन जाता है। name और role फ़ील्ड वाले तीन व्यक्ति-रिकॉर्ड का एक ऐरे पेस्ट कीजिए, और आपको name तथा role की एक हेडर पंक्ति के बाद तीन पंक्तियाँ मिलती हैं।
सिर्फ़ पहले के बजाय सभी ऑब्जेक्ट से कुंजियाँ इकट्ठा करना ही असमान डेटा को संरेखित रखता है। अगर आपके पहले रिकॉर्ड में एक name और एक email है पर दूसरे में एक phone फ़ील्ड भी जुड़ता है, तो भी कन्वर्टर एक phone कॉलम उत्सर्जित करता है और बस पहली पंक्ति का phone सेल खाली छोड़ देता है। क्रम पहली बार दिखने से लिया जाता है, इसलिए कॉलम एक पूर्वानुमेय, स्थिर अनुक्रम में पढ़े जाते हैं।
ऑब्जेक्ट का ऐरे ही सही इनपुट आकार क्यों है
एक अकेली संख्या या खाली स्ट्रिंग का एक ऐरे का कोई स्वाभाविक सारणीबद्ध रूप नहीं होता, इसलिए उस अस्पष्टता को दूर करने के लिए ऑब्जेक्ट-का-ऐरे वाली परंपरा मौजूद है। हर तत्व एक पंक्ति बन जाता है; हर फ़ील्ड नाम एक कॉलम बन जाता है। एक अकेला ऑब्जेक्ट बस एक-पंक्ति वाला मामला है — यह टूल एक अकेले ऑब्जेक्ट को एक-पंक्ति वाली तालिका में लपेट देता है जिसका हेडर उसकी कुंजियाँ होती हैं — लेकिन यह परंपरा सूचियों के लिए असल में चमकती है, जो ठीक वही आकार है जो अधिकांश REST एंडपॉइंट सूची संसाधनों के लिए लौटाते हैं: एक users एंडपॉइंट, एक orders एंडपॉइंट, एक search-results एंडपॉइंट। यही वजह है कि किसी API प्रतिक्रिया को स्प्रेडशीट में एक्सपोर्ट करना सबसे आम कारण है जिसके लिए लोग इस रूपांतरण की ओर रुख़ करते हैं।
अगर आपका असली डेटा एक स्तर गहरे लिपटा हुआ है, उदाहरण के लिए एक ऐसा ऑब्जेक्ट जिसका results फ़ील्ड आपके मतलब का ऐरे रखता है, तो उस भीतरी ऐरे को पहले बाहर निकालिए और उसे अकेले पेस्ट कीजिए। कन्वर्टर को सीधे ऐरे देना ही एक भ्रमित करने वाली अकेली पंक्ति के बजाय एक साफ़ तालिका बनाता है।
नेस्टेड ऑब्जेक्ट और ऐरे कैसे संभाले जाते हैं
CSV में गहराई की कोई अवधारणा नहीं होती, इसलिए एक ऐसा मान जो खुद एक ऑब्जेक्ट या एक ऐरे हो, वह किसी समतलीकरण योजना का आविष्कार किए बिना अधिक कॉलम में नहीं फैल सकता। यह टूल पूर्वानुमेय, उत्क्रमणीय राह लेता है: एक नेस्टेड मान एक अकेले सेल के भीतर संक्षिप्त JSON टेक्स्ट के रूप में सीरियलाइज़ किया जाता है। एक street और एक city रखने वाला एक address फ़ील्ड एक सेल बन जाता है जिसमें वह छोटा ऑब्जेक्ट एक JSON स्ट्रिंग के रूप में होता है, उद्धरण में रखा गया ताकि उसके भीतरी अल्पविराम पंक्ति को न तोड़ें।
यह डेटा को अक्षुण्ण और राउंड-ट्रिप करने योग्य रखता है, लेकिन किसी स्प्रेडशीट में इसे पढ़ना सुखद नहीं होता। जब आपके रिकॉर्ड सचमुच पदानुक्रमित हों — गहराई से नेस्टेड कॉन्फ़िग, वृक्ष संरचनाएँ, ऐरे के ऐरे वाली कोई भी चीज़ — तो CSV ग़लत लक्ष्य है और एक JSON या YAML प्रतिनिधित्व आपकी कहीं बेहतर सेवा करेगा। CSV सपाट, रिकॉर्ड-जैसे डेटा के लिए चमकता है।
उद्धरण और एस्केपिंग, वह हिस्सा जो चुपचाप फ़ाइलें भ्रष्ट करता है
भोले-भाले स्ट्रिंग-जोड़ने से टूटा हुआ CSV बनने का कारण यह है कि सीमांकक डेटा के भीतर दिख सकता है। "Portland, Oregon" का एक city मान एक अल्पविराम रखता है; कच्चा लिखे जाने पर यह दो सेल में बँट जाएगा और उसके बाद के हर कॉलम को खिसका देगा। कन्वर्टर सामान्य RFC 4180 परंपरा का पालन करता है: कोई भी फ़ील्ड जिसमें सीमांकक, एक दोहरा उद्धरण, या एक लाइन ब्रेक हो, उसे दोहरे उद्धरणों में लपेट दिया जाता है, और मान के भीतर पहले से मौजूद कोई भी दोहरा उद्धरण दोगुना कर दिया जाता है।
तो she said "hi" शब्द वाला एक मान चारों ओर उद्धरणों और भीतरी उद्धरणों के दोगुने के साथ उत्सर्जित होता है, और एक अंतर्निहित न्यूलाइन वाला मान इस तरह लपेटा जाता है कि लाइन ब्रेक एक नई पंक्ति शुरू करने के बजाय एक ही सेल के भीतर रहे। यह ठीक वही एन्कोडिंग है जिसकी स्प्रेडशीट आयात पर अपेक्षा करती हैं, यही वजह है कि एक सही ढंग से उद्धरण की हुई फ़ाइल साफ़-सुथरे ढंग से खुलती है जबकि एक हाथ से बनाई फ़ाइल डेटा को ग्रिड में बिखेर देती है।
सीमांकक चुनना
अल्पविराम डिफ़ॉल्ट है और CSV का C है, लेकिन यह तब ख़राब फ़िट है जब आपका डेटा अल्पविरामों से भरा हो या जब आपकी स्प्रेडशीट लोकेल अल्पविराम को दशमलव विभाजक के रूप में इस्तेमाल करती हो। इसी कारण से अधिकांश यूरोप अर्धविराम पर डिफ़ॉल्ट करता है, और विश्लेषक अक्सर टैब वर्ण पसंद करते हैं क्योंकि टैब असली फ़ील्ड मानों के भीतर लगभग कभी नहीं दिखते, जिससे अधिकांश उद्धरण-कार्य टल जाता है।
सीमांकक को इससे मिलाइए कि फ़ाइल कहाँ जा रही है। अगर किसी सहकर्मी की स्प्रेडशीट हर पंक्ति को कॉलम A में ठूँसती रहती है, तो सामान्य कारण एक सीमांकक बेमेल होता है — अल्पविराम, अर्धविराम और टैब के बीच तब तक बदलिए जब तक उनकी मशीन पर कॉलम सही ढंग से न बँट जाएँ।
वापस JSON की ओर राउंड-ट्रिप करना
यह रूपांतरण दोनों दिशाओं में चलता है। CSV-से-JSON पर स्वैप कीजिए और हेडर पंक्ति कुंजियों के नाम रखती है जबकि उसके बाद की हर पंक्ति एक ऑब्जेक्ट बन जाती है, जो तब काम का है जब कोई ग़ैर-डेवलपर आपको एक स्प्रेडशीट थमाता है और आपको किसी API या किसी आयात स्क्रिप्ट के लिए संरचित डेटा चाहिए। एक चेतावनी इस राउंड ट्रिप को परिभाषित करती है: CSV सेल बिना-प्रकार वाला टेक्स्ट होते हैं, इसलिए CSV से वापस पढ़ा गया 42 स्ट्रिंग 42 है, संख्या नहीं, जब तक आप टाइप किया हुआ पार्सिंग सक्षम न करें।
वापसी के रास्ते में सादे संख्यात्मक और true/false पाठ को असली JSON मानों में बदलने के लिए parse-numbers-and-booleans विकल्प सक्षम कीजिए। तब भी, राउंड ट्रिप को भावना में हानिकारक मानिए — उद्धरण सामान्यीकरण करता है, टाइप जानकारी अनुमान से पुनर्निर्मित होती है, और किसी सेल के भीतर के किसी भी नेस्टेड-JSON को फिर से हाथ से पार्स करना पड़ता है। संरचित डेटा की एक विश्वासयोग्य प्रति के लिए, उसे पूरे रास्ते JSON में रखिए।
यह किसी असली कार्यप्रवाह में कहाँ फिट बैठता है
रोज़मर्रा का उपयोग इंजीनियरिंग और बाक़ी व्यवसाय के बीच पुल बनाना है: एक API सूची को CSV में एक्सपोर्ट कीजिए ताकि वह किसी स्प्रेडशीट में खुले, किसी BI डैशबोर्ड में गिरे, या किसी थोक-आयात टेम्पलेट को खिलाए। विश्लेषकों को एक ग्रिड मिलता है जिसे वे पिवट और चार्ट कर सकते हैं; आप एक बार के एक्सपोर्ट स्क्रिप्ट लिखने से बच जाते हैं। चूँकि पूरा रूपांतरण आपके ब्राउज़र में होता है, आप इसे उत्पादन डेटा — ऑर्डर इतिहास, उपयोगकर्ता सूचियाँ, आंतरिक मीट्रिक — के साथ बिना उसमें से कुछ भी किसी तृतीय-पक्ष सर्वर पर भेजे कर सकते हैं।
साफ़ एक्सपोर्ट के लिए एक व्यावहारिक सुझाव: रूपांतरण से पहले अपने रिकॉर्ड को सामान्य कीजिए। सुनिश्चित कीजिए कि हर ऑब्जेक्ट एक ही फ़ील्ड नामों का उपयोग करे, ऐरे को किसी भी लपेटने वाले ऑब्जेक्ट से बाहर निकालिए, और पहले से तय कीजिए कि नेस्टेड फ़ील्ड को आपके कोड में समतल किया जाना चाहिए या एक सेल के भीतर JSON के रूप में छोड़ा जाना चाहिए। JSON को आकार देने के कुछ मिनट एक ऐसा CSV देते हैं जिसे आयात के बाद किसी सफ़ाई की ज़रूरत नहीं पड़ती।
अक्सर पूछे जाने वाले प्रश्न
मैं JSON को CSV में कैसे बदलूँ?
यह परिवर्तक कौन-सा CSV फ़ॉर्मैट उपयोग करता है?
क्या यह CSV को वापस JSON में बदल सकता है?
नेस्टेड ऑब्जेक्ट्स को कैसे संभाला जाता है?
क्या मेरा डेटा किसी सर्वर पर अपलोड किया जाता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें