लेख
CSV, XML, JSON और YAML के बीच रूपांतरण: एक व्यावहारिक मार्गदर्शिका
CSV, JSON, XML और YAML वे चार फ़ॉर्मैट हैं जिनसे डेवलपर डेटा पाइपलाइन, कॉन्फ़िग फ़ाइलों और API में सबसे अधिक मिलते हैं। जब डेटा मॉडल मेल खाते हैं तो इनके बीच रूपांतरण सीधा होता है, और जब नहीं मिलते तो आश्चर्यजनक रूप से हानिकारक (lossy) होता है। यह मार्गदर्शिका बताती है कि हर फ़ॉर्मैट क्या दर्शा सकता है और क्या नहीं, रूपांतरण के दौरान जानकारी कहाँ गायब होती है, और कौन-से एन्कोडिंग जाल चुपचाप डेटा बिगाड़ देते हैं। इस साइट का data-converter टूल चार में से तीन फ़ॉर्मैट (CSV, JSON और YAML) को पूरी तरह ब्राउज़र में संभालता है; यहाँ के XML सेक्शन तब के लिए पृष्ठभूमि जानकारी हैं जब आप डेटा को हाथ से या किसी अलग टूल से माइग्रेट करते हैं।
चार फ़ॉर्मैट और उनके डेटा मॉडल
CSV डेटा को पंक्तियों और स्तंभों की एक सपाट ग्रिड के रूप में व्यवस्थित करता है। पहली पंक्ति आमतौर पर स्तंभों के नाम देती है; हर अगली पंक्ति एक रिकॉर्ड होती है। कोई नेस्टिंग नहीं, कोई टाइप जानकारी नहीं, और सेल में सादे टेक्स्ट के अलावा किसी चीज़ के लिए कोई मानक नहीं। हर मान एक स्ट्रिंग होता है जब तक उपयोग करने वाला ऐप्लिकेशन कोई टाइप न थोपे। JSON डेटा को ऑब्जेक्ट (की-वैल्यू मैप) और ऐरे के एक वृक्ष के रूप में मॉडल करता है। मान स्ट्रिंग, संख्या, boolean, null, नेस्टेड ऑब्जेक्ट, या किसी भी गहराई के ऐरे हो सकते हैं। इससे एक ही JSON दस्तावेज़ नेस्टेड पता ऑब्जेक्ट, लाइन-आइटम ऐरे और टाइप वाले संख्यात्मक योग के साथ एक ग्राहक रिकॉर्ड दर्शा सकता है। XML डेटा को तत्वों (elements) के एक वृक्ष के रूप में मॉडल करता है। हर तत्व नामित विशेषताएँ रख सकता है और संतान तत्व या टेक्स्ट सामग्री समाहित कर सकता है। कोई अंतर्निहित संख्या या boolean टाइप नहीं; सब कुछ टेक्स्ट है। XSD जैसे स्कीमा सत्यापन के समय टाइप लागू कर सकते हैं, पर तार पर भेजा गया रूप हमेशा वर्ण डेटा होता है। YAML इंडेंटेशन का उपयोग कर वही ऑब्जेक्ट-और-ऐरे मॉडल व्यक्त करता है जो JSON करता है, पर मनुष्य के पढ़ने के लिए साफ़ वाक्यविन्यास के साथ। YAML, JSON का सुपरसेट है: कोई भी वैध JSON दस्तावेज़ वैध YAML भी है। यह बहु-पंक्ति स्ट्रिंग, टिप्पणियाँ, और दोहराए गए ब्लॉक के लिए anchor-alias संदर्भ जोड़ता है। YAML कॉन्फ़िग फ़ाइलों में आम है; JSON API प्रतिक्रियाओं में आम है।
हानिकारक रूपांतरण: समतल करना और XML की अस्पष्टता
सबसे आम हानिकारक रूपांतरण नेस्टेड JSON या XML को CSV में समतल (flatten) करना है। नेस्टेड पता फ़ील्ड वाला एक JSON ऑब्जेक्ट किसी CSV पंक्ति में साफ़-साफ़ मैप नहीं हो सकता। सामान्य उपाय डॉट-नोटेशन स्तंभ नाम है: customer.address.city अपना अलग स्तंभ बन जाता है। यह एक स्तर की नेस्टिंग के लिए काम करता है, पर जब कोई ऐरे आता है तो पूरी तरह टूट जाता है। तीन फ़ोन नंबर वाले ग्राहक के लिए या तो तीन अलग स्तंभ चाहिए (अधिकतम संख्या को हार्ड-कोड करते हुए), दूसरी CSV फ़ाइल में बाँटना, या ऐरे को एक सेल के भीतर सीमांकित स्ट्रिंग के रूप में एन्कोड करना। इनमें से कोई भी विकल्प अतिरिक्त मेटाडेटा के बिना मूल JSON पर वापस नहीं लौटता। XML एक अलग अस्पष्टता लाता है: विशेषता बनाम संतान तत्व का चुनाव। मान Paris को विशेषता (<city name="Paris">) के रूप में या संतान तत्व (<city><name>Paris</name></city>) के रूप में रखा जा सकता है। जब कोई कन्वर्टर XML पढ़कर JSON बनाता है, उसे तय करना होता है कि विशेषताएँ कैसे मैप हों। आम परंपराओं में विशेषता की को @ उपसर्ग देना या उन्हें "_attributes" की के नीचे रखना शामिल है। यह चुनाव मानकीकृत नहीं है, जिसका अर्थ है कि एक ही XML पढ़ने वाले दो कन्वर्टर संरचनात्मक रूप से अलग JSON बना सकते हैं। यदि आप XML और JSON के बीच डेटा को आगे-पीछे ले जाने की योजना बना रहे हैं, शुरू करने से पहले एक परंपरा तय कर लें।
CSV के जाल: सीमांकक, उद्धरण और एन्कोडिंग
CSV का कोई एकल औपचारिक मानक नहीं है, केवल RFC 4180 एक व्यापक रूप से उद्धृत संदर्भ के रूप में है। सबसे आम सीमांकक अल्पविराम है, पर अर्धविराम (यूरोपीय locale में आम जहाँ अल्पविराम दशमलव विभाजक का काम करता है), टैब (TSV), और पाइप भी व्यवहार में दिखते हैं। .csv नाम की फ़ाइल इनमें से किसी का भी उपयोग कर सकती है बिना यह संकेत दिए कि कौन-सा। जब किसी फ़ील्ड मान में स्वयं सीमांकक होता है, RFC 4180 फ़ील्ड को दोहरे उद्धरण में लपेटने की माँग करता है: "San Francisco, CA"। उद्धृत फ़ील्ड के भीतर एक दोहरा उद्धरण उसे दोगुना करके escape करना होता है: "He said ""hello"""। शाब्दिक नई-पंक्ति वाले फ़ील्ड को भी उद्धृत करना होता है। यह कदम छोड़ने वाले पार्सर पंक्ति-गणना की त्रुटियाँ पैदा करते हैं जिन्हें खोजना कठिन है। एन्कोडिंग एक अलग जाल है। Windows टूल से आई CSV फ़ाइलें अक्सर एक UTF-8 BOM (byte order mark: फ़ाइल के आरंभ में तीन बाइट EF BB BF) रखती हैं। BOM Excel को एन्कोडिंग पहचानने में मदद करता है, पर कई प्रोग्रामिंग-भाषा पार्सर BOM को पहले स्तंभ नाम का हिस्सा मान लेते हैं, और "id" के बजाय "id" नाम का स्तंभ बना देते हैं। इससे नाम से स्तंभ खोजने वाला हर आगे का कोड टूट जाता है। CSV फ़ाइल को प्रोग्राम से पढ़ते समय, पार्स करने से पहले BOM हटा दें, या ऐसी लाइब्रेरी का उपयोग करें जो इसे स्पष्ट रूप से संभालती हो।
फ़ॉर्मैट चुनना: कॉन्फ़िग, आदान-प्रदान और स्प्रेडशीट
फ़ॉर्मैट का चुनाव आमतौर पर संदर्भ से तय होता है, पसंद से नहीं। JSON, REST API और ब्राउज़र-से-सर्वर आदान-प्रदान के लिए डिफ़ॉल्ट है। यह सघन है, हर प्रोग्रामिंग भाषा में स्वाभाविक रूप से पार्स होता है, और संख्याओं तथा boolean के लिए टाइप जानकारी रखता है। इसकी कमज़ोरी टिप्पणियों का अभाव है, जो इसे उन फ़ाइलों के लिए अनुपयुक्त बनाता है जिन्हें डेवलपर हाथ से पढ़ते और संपादित करते हैं। YAML कॉन्फ़िग फ़ाइलों (Kubernetes manifest, CI पाइपलाइन परिभाषाएँ, Ansible playbook) के लिए पसंद किया जाता है क्योंकि यह इनलाइन टिप्पणियों की अनुमति देता है और कई स्तरों के इंडेंटेशन वाले JSON से पढ़ने में आसान है। इसका मुख्य जोखिम यह है कि इंडेंटेशन की त्रुटियाँ चुपचाप होती हैं: ग़लत इंडेंट की हुई एक की बिना किसी पार्स त्रुटि के अलग दायरे में चली जाती है। XML पुराने एंटरप्राइज़ सिस्टम, SOAP वेब सेवाओं, दस्तावेज़ फ़ॉर्मैट (DOCX, SVG, RSS), और स्कीमा सत्यापन या नेमस्पेस स्पष्टीकरण की माँग वाले संदर्भों में मानक बना हुआ है। यह वाचाल है, पर XPath और XSLT औज़ार परिपक्व हैं। CSV सही चुनाव है जब डेटा सचमुच सपाट हो और उपभोक्ता एक स्प्रेडशीट ऐप्लिकेशन या डेटा विश्लेषक हो। यह कॉन्फ़िग या API आदान-प्रदान के लिए उपयुक्त नहीं क्योंकि इसमें न टाइप प्रणाली है न नेस्टिंग।
data-converter से स्थानीय रूप से करना
इस साइट का data-converter टूल CSV, JSON और YAML के बीच पूरी तरह ब्राउज़र के भीतर पार्स और रूपांतरण करता है; यह XML को न तो पढ़ता है न लिखता है। किसी भी क्षण कोई डेटा सर्वर को नहीं भेजा जाता। रूपांतरण आपके स्थानीय JavaScript रनटाइम में चलता है, और परिणाम बिना कुछ भी आपके डिवाइस से बाहर गए डाउनलोड या कॉपी के लिए उपलब्ध रहता है। यह उस डेटा के लिए मायने रखता है जो साझा करने के लिए आपका नहीं है: व्यक्तिगत जानकारी वाली API प्रतिक्रियाएँ, आंतरिक होस्टनाम वाली कॉन्फ़िग फ़ाइलें, या आंतरिक डेटाबेस से CSV निर्यात। ऐसा डेटा सर्वर पर चलने वाले वेब-आधारित कन्वर्टर में चिपकाने का अर्थ है कि सामग्री नेटवर्क पर भेजी जाती है और उस हार्डवेयर पर संसाधित होती है जिसे आप नियंत्रित नहीं करते। data-converter के साथ, ब्राउज़र टैब ही संसाधन वातावरण है। टूल CSV पढ़ते या लिखते समय RFC 4180 उद्धरण लागू करता है, और JSON या YAML से CSV जाते समय objects की एक flat array अपेक्षित करता है: किसी key के नीचे nested object या array वैल्यू को अपने आप dot-notation में समतल नहीं किया जाता, इसलिए अगर आपको उन्हें अलग कॉलम के रूप में चाहिए तो कन्वर्ट करने से पहले उन फ़ील्ड को खुद समतल करें। अगर आपको डेटा को XML से या XML में ले जाना है, तो पहले किसी समर्पित XML टूल से उसे JSON या YAML में बदलें, फिर नतीजे को यहाँ लाएँ।
इस लेख में उल्लेखित टूल्स
अक्सर पूछे जाने वाले सवाल
क्या मैं JSON को CSV के ज़रिए ले जाकर वापस मूल पा सकता हूँ?
केवल तब जब JSON बिना किसी नेस्टेड फ़ील्ड और बिना किसी ऐरे-मान वाले ऑब्जेक्ट का एक सपाट ऐरे हो। जैसे ही कोई नेस्टेड ऑब्जेक्ट या ऐरे-मान आता है, CSV प्रतिनिधित्व को एक संरचनात्मक निर्णय (डॉट-नोटेशन स्तंभ, अनेक पंक्तियाँ, या एन्कोड की हुई स्ट्रिंग) चाहिए जो स्वचालित रूप से उलटा नहीं किया जा सकता। यदि आपके डेटा में नेस्टिंग है, JSON, XML या YAML साफ़-साफ़ वापस लौटेंगे; CSV नहीं।
किसी यूरोपीय ऐप्लिकेशन से निर्यात के बाद मेरी CSV Excel में ग़लत क्यों दिखती है?
यूरोपीय locale अक्सर CSV सीमांकक के रूप में अर्धविराम का उपयोग करते हैं क्योंकि अल्पविराम दशमलव संकेतन के लिए सुरक्षित रखा जाता है। यूरोपीय locale पर Excel अर्धविराम की अपेक्षा करता है। यदि फ़ाइल अल्पविराम का उपयोग करती है, Excel पूरी पंक्ति को एक ही स्तंभ मान लेता है। समाधान या तो निर्यात सेटिंग में सीमांकक बदलना है, या Excel के Data Import विज़ार्ड का उपयोग करना है, जो आपको सीमांकक मैन्युअल रूप से बताने देता है। UTF-8 BOM का मुद्दा अलग है: BOM के बिना, Excel उच्चारण वाले वर्णों को भी विकृत टेक्स्ट के रूप में पढ़ सकता है।
व्यवहार में YAML और JSON में क्या अंतर है?
दोनों एक ही अंतर्निहित डेटा मॉडल दर्शाते हैं: ऑब्जेक्ट, ऐरे, स्ट्रिंग, संख्या, boolean और null। YAML टिप्पणियाँ (# से शुरू होने वाली पंक्तियाँ), बहु-पंक्ति स्ट्रिंग शाब्दिक, और दोहराए गए ब्लॉक के लिए anchor संदर्भ जोड़ता है। JSON सख़्ती से वैध YAML का एक उपसमुच्चय है, पर JSON पार्सर YAML नहीं पढ़ते। व्यावहारिक नियम: API payload और डेटा भंडारण के लिए JSON का उपयोग करें; उन कॉन्फ़िग फ़ाइलों के लिए YAML का उपयोग करें जिन्हें मनुष्य संपादित करते हैं और जिन्हें इनलाइन टिप्पणियों से लाभ होता है।