CSV से JSON कन्वर्टर
अपने ब्राउज़र में ही CSV या TSV को साफ़-सुथरे JSON में बदलें। पहली पंक्ति keys बन जाती है, डिलिमिटर अपने आप पहचाना जाता है, और आप हर वैल्यू को text के रूप में रख सकते हैं या numbers और booleans को टाइप करवा सकते हैं — कुछ भी अपलोड नहीं होता।
डिलिमिटर
आउटपुट
वैल्यू
पहली पंक्ति हर object के लिए keys बन जाती है।
आपका JSON यहाँ दिखाई देगा।
CSV से JSON कन्वर्टर का उपयोग कैसे करें
- 1
अपना CSV पेस्ट करें
CSV या TSV डेटा की पंक्तियाँ पेस्ट करें, हर रिकॉर्ड एक अलग लाइन में। कॉलम के नाम पहली पंक्ति में रखें ताकि वे keys बन सकें।
- 2
डिलिमिटर चुनें
Comma, Semicolon या Tab को अपने आप पहचानने के लिए इसे ऑटो पर रहने दें, या अपने डेटा में इस्तेमाल हुआ डिलिमिटर चुनें।
- 3
आउटपुट का स्वरूप चुनें
हर पंक्ति को header के आधार पर keys वाले object में बदलने के लिए Objects चुनें, या हर लाइन को एक साधारण array की तरह रखने के लिए Rows चुनें। numbers और booleans को असली JSON टाइप के रूप में पढ़ने के लिए वैल्यू को Typed पर सेट करें।
- 4
JSON कॉपी करें
फ़ॉर्मैट किया गया JSON कॉपी करें और इसे सीधे अपने कोड, किसी API request या config फ़ाइल में पेस्ट करें।
CSV को JSON में पार्स करना: हेडर, प्रकार, और अनियमितताएँ
CSV सरल दिखता है, पर है नहीं
एक अल्पविराम-पृथक फ़ाइल तुच्छ दिखती है — मान, अल्पविराम, न्यूलाइन — लेकिन वह सरलता एक जाल है। CSV का कोई आधिकारिक, सर्वत्र लागू किया गया मानक नहीं है; RFC 4180 सामान्य परंपराओं को दर्ज करता है, फिर भी एक्सपोर्टर उद्धरण, लाइन एंडिंग, और सीमांककों पर असहमत हैं। कठिन मामले ठीक वही हैं जिन्हें अल्पविरामों पर एक भोला-भाला विभाजन ग़लत कर देता है: ऐसे मान जो खुद अल्पविराम रखते हैं, ऐसे मान जो उद्धरण वर्ण रखते हैं, और ऐसे मान जो कई पंक्तियों में फैले होते हैं।
एक असली पार्सर इन्हें केवल पाठ बाँटने के बजाय उद्धरण नियमों को पढ़कर संभालता है। दोहरे उद्धरणों में लिपटा एक फ़ील्ड वैध रूप से अल्पविराम और एस्केप किए उद्धरण (एक के बाद एक दो दोहरे उद्धरणों के रूप में लिखे गए) रख सकता है, और यह टूल ठीक उसी का सम्मान करता है: "Portland, Oregon" रखने वाला एक सेल दो कॉलम बनने के बजाय एक अकेला मान बना रहता है, और किसी फ़ील्ड के भीतर एक दोगुना उद्धरण एक अकेले शाब्दिक उद्धरण में सिमट जाता है। एक मामला जिसे यह पुनर्निर्मित नहीं करता वह है उद्धरणों के भीतर लाइन ब्रेक वाला मान, क्योंकि यह फ़ाइल को पहले पंक्ति-दर-पंक्ति रिकॉर्ड में बाँटता है — इसलिए रूपांतरण से पहले हर रिकॉर्ड को उसकी अपनी पंक्ति पर रखिए, या सेल के भीतर की न्यूलाइन हटा दीजिए।
आउटपुट आकार: ऑब्जेक्ट का एक ऐरे
एक तालिका का स्वाभाविक JSON रूप ऑब्जेक्ट का एक ऐरे होता है, प्रति डेटा पंक्ति एक ऑब्जेक्ट। CSV की पहली पंक्ति को हेडर माना जाता है, और हर हेडर सेल एक कुंजी बन जाती है जो हर ऑब्जेक्ट में साझा होती है। name, role, और city नाम के तीन कॉलम और उसके बाद दो डेटा पंक्तियाँ पेस्ट कीजिए, और आपको दो ऑब्जेक्ट का एक ऐरे मिलता है, हर एक में वे तीनों कुंजियाँ उस पंक्ति के मानों से मैप की हुई। यही वह आकार है जिसकी अधिकांश API और आयात स्क्रिप्ट अपेक्षा करते हैं।
अगर आपके डेटा में कोई हेडर पंक्ति नहीं है, तो उस मैपिंग के पास कुंजियाँ निकालने के लिए कुछ नहीं होता। rows आउटपुट मोड पर स्विच कीजिए और इसके बजाय हर पंक्ति मानों का एक सादा ऐरे बन जाती है, जो नाम गढ़े बिना कच्चे ग्रिड को संरक्षित रखती है। पहले से सही आउटपुट मोड चुनना आपको आकस्मिक पहली डेटा पंक्ति से कुंजी पाए ऑब्जेक्ट से बचाता है।
जब तक आप न कहें, हर चीज़ एक स्ट्रिंग है
CSV पढ़ते समय यह सबसे महत्वपूर्ण अकेली चेतावनी है। यह फ़ॉर्मेट कोई भी टाइप जानकारी बिल्कुल नहीं ले जाता — हर सेल टेक्स्ट है। हस्तक्षेप के बिना संख्या 42 बन जाती है स्ट्रिंग 42, शब्द true बन जाता है स्ट्रिंग true, और एक खाली सेल बन जाता है एक खाली स्ट्रिंग। ऐसा कोड जो उन फ़ील्डों से एक असली संख्या या बूलियन की अपेक्षा करता है, वह चुपचाप गड़बड़ करेगा।
टाइप किए मान सक्षम कीजिए और पार्सर सादे संख्यात्मक पाठ को JSON संख्याओं में, शब्द true और false को बूलियन में, और शब्द null को एक असली null में पदोन्नत कर देता है। टाइप अनुमान सुविधाजनक है पर स्वभाव से अनुमान-आधारित है, इसलिए किनारों पर नज़र रखिए: आगे शून्य वाले पहचानकर्ता, फ़ोन नंबर, ZIP कोड, और संस्करण-जैसी स्ट्रिंग तकनीकी रूप से संख्या-जैसी दिखती हैं पर आमतौर पर टेक्स्ट ही रहनी चाहिए। जब उन फ़ील्डों के लिए सटीकता मायने रखती हो, तो मानों को टेक्स्ट रखिए और अपने ही कोड में जान-बूझकर बदलिए।
सीमांकक पहचान और TSV
हर पृथक-मान वाली फ़ाइल अल्पविराम का उपयोग नहीं करती। कई यूरोपीय लोकेल में स्प्रेडशीट अर्धविराम के साथ एक्सपोर्ट होती हैं क्योंकि अल्पविराम दशमलव चिह्न है, और किसी स्प्रेडशीट से सीधे एक रेंज कॉपी करने पर आमतौर पर टैब-पृथक मान मिलते हैं। Auto मोड आपके इनपुट की पहली पंक्ति का निरीक्षण करता है और अल्पविराम, अर्धविराम, या टैब में से जो भी वहाँ सबसे अधिक बार आता है उसे चुनता है, इसलिए एक अल्पविराम फ़ाइल, एक अर्धविराम फ़ाइल, और एक TSV सब बिना आपके कोई सेटिंग बदले रूपांतरित होते हैं।
साफ़ डेटा के लिए स्वतः-पहचान भरोसेमंद है पर ऐसी फ़ाइल से धोखा खा सकती है जिसकी पहली पंक्ति में संयोगवश असली सीमांकक से अधिक किसी एक विभाजक का हो। अगर कॉलम ग़लत निकलें, तो अनुमान को ओवरराइड कीजिए और सीमांकक को स्पष्ट रूप से तय कीजिए — यह एक ही चरण में अस्पष्टता हटा देता है।
एन्कोडिंग, BOM, और अन्य अदृश्य शैतान
स्प्रेडशीट सॉफ़्टवेयर से एक्सपोर्ट की गई फ़ाइलें अक्सर एक बाइट-ऑर्डर मार्क से शुरू होती हैं, जो फ़ाइल के बिल्कुल आरंभ में एक अदृश्य वर्ण होता है। यथास्थान छोड़ देने पर यह पहले हेडर नाम से चिपक जाता है, इसलिए एक कुंजी जो id होनी चाहिए वह चुपचाप थोड़ी अलग स्ट्रिंग बन जाती है और id के आधार पर आपकी खोजें चूक जाती हैं। ऑपरेटिंग सिस्टमों के बीच असंगत लाइन एंडिंग और पीछे लगी खाली पंक्तियाँ बाक़ी आम संदिग्ध हैं जो काल्पनिक पंक्तियाँ या एक-से-कम कॉलम बनाते हैं।
यह टूल हर हेडर और सेल को छाँट देता है, इसलिए सामान्य शैतान ज़्यादातर अपने-आप संभल जाते हैं: यह Unix और Windows दोनों लाइन एंडिंग को सहन करता है, और चूँकि एक आगे लगा बाइट-ऑर्डर मार्क छाँटने योग्य व्हाइटस्पेस गिना जाता है, इसे कुंजी से चिपकाए जाने के बजाय पहले हेडर से स्वचालित रूप से हटा दिया जाता है। यही वजह है कि एक कच्चा स्प्रेडशीट एक्सपोर्ट यहाँ पेस्ट करना आमतौर पर बस काम कर जाता है। अगर एक रूपांतरित कुंजी फिर भी कोड में मेल खाने से इनकार करे, तो किसी ऐसे भटके हुए वर्ण पर शक कीजिए जिसे छाँटना नहीं हटाता — मान लीजिए, एक शून्य-चौड़ाई वाला स्पेस — और फ़ाइल को सादे UTF-8 के रूप में फिर से एक्सपोर्ट कीजिए।
असमान पंक्तियाँ और खाली सेल
असली स्प्रेडशीट गंदी होती हैं: कुछ पंक्तियों में पीछे लगे खाली सेल होते हैं, कुछ में फ़ील्ड पूरी तरह ग़ायब होते हैं, और अंत में एक भटकी हुई खाली पंक्ति घुस आती है। जब किसी पंक्ति में हेडर की संख्या से कम मान होते हैं, तो ग़ायब फ़ील्ड रूपांतरण को क्रैश करने के बजाय खाली स्ट्रिंग के रूप में दिखते हैं, इसलिए आउटपुट ऐरे आयताकार बना रहता है और हर ऑब्जेक्ट कुंजियों का पूरा सेट रखता है।
परिणाम पर भरोसा करने से पहले, उसमें एक ऐसी संकेत-देने वाली पंक्ति के लिए नज़र दौड़ाइए जहाँ मान एक कॉलम खिसके हुए लगें — यही ऊपर की ओर किसी बिना-उद्धरण वाले फ़ील्ड के भीतर एक बिना-एस्केप किए सीमांकक का हस्ताक्षर है। स्रोत फ़ाइल को ठीक करना (आपत्तिजनक मान को उद्धरण में रखना) बाद में JSON को पैच करने की कोशिश से कहीं अधिक भरोसेमंद है।
CSV-से-JSON अपनी कीमत कहाँ वसूल करता है
सबसे आम उपयोग किसी के द्वारा थमाई गई एक स्प्रेडशीट को ऐसे डेटा में बदलना है जिसे आपका प्रोग्राम उपभोग कर सके: एक डेटाबेस को बीज देना, किसी API अनुरोध का मुख्य भाग बनाना, एक कॉन्फ़िग फ़ाइल उत्पन्न करना, या एक टेस्ट फ़िक्सचर खिलाना। ग़ैर-डेवलपर स्प्रेडशीट में रहते हैं, डेवलपर JSON में रहते हैं, और यह रूपांतरण हर बार एक फेंकने योग्य पार्सर लिखे बिना दोनों के बीच पुल है।
चूँकि पूरी पार्सिंग आपके ब्राउज़र में चलती है, आप संवेदनशील एक्सपोर्ट — ग्राहक सूचियाँ, आंतरिक मीट्रिक, वित्तीय पंक्तियाँ — को बिना किसी तृतीय-पक्ष सेवा पर कुछ भी अपलोड किए रूपांतरित कर सकते हैं। आगे की सुरक्षा के लिए एक नियम ध्यान में रखिए: सोच-समझकर तय कीजिए कि हर कॉलम को टाइप किया जाना चाहिए या टेक्स्ट के रूप में छोड़ा जाना चाहिए, क्योंकि चुपके से होने वाला टाइप परिवर्तन सबसे आम कारण है कि आयातित डेटा स्प्रेडशीट में दिखाए गए से अलग व्यवहार करता है।
अक्सर पूछे जाने वाले प्रश्न
मैं CSV को JSON में कैसे बदलूँ?
क्या पहली पंक्ति का header होना ज़रूरी है?
क्या यह सिर्फ़ comma नहीं, बल्कि tab या semicolon भी पढ़ सकता है?
numbers और booleans को कैसे संभाला जाता है?
क्या मेरा डेटा कहीं अपलोड होता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें