क्या CSV XML और JSON के लिए एक अच्छा विकल्प है? [बन्द है]

Question

क्या CSV को प्रोग्रामिंग भाषाओं के लिए XML और JSON के खिलाफ एक अच्छा विकल्प माना जाता है ?

मैं आमतौर पर फ्लैट फाइल स्टोरेज के रूप में XML और JSON (या कभी-कभी एक सादे पाठ फ़ाइल) का उपयोग करता हूं। हालाँकि, हाल ही में मैं PHP में एक CSV कार्यान्वयन में आया था । मैंने आमतौर पर CSV को एक्सेल फाइलों में इनपुट के लिए इस्तेमाल करते देखा है , लेकिन मैंने इसे प्रोग्रामिंग के साथ कभी इस्तेमाल नहीं किया है। क्या यह किसी भी तरह से XML या JSON से बेहतर होगा?

Comments

यह विचित्रता अस्पष्ट है। क्या आप पूछ रहे हैं कि क्या CSV स्टोरेज सिस्टम के रूप में बेहतर प्रारूप बनाता है, या आप पूछ रहे हैं कि क्या XML / CSON पर CSV का उपयोग करने के कोई कारण हैं ?

— ग्रैंडमास्टरबी

किसी भी CSV संदेश संरचना को XML या JSON संदेश प्रारूप में मैप किया जा सकता है। सभी XML / JSON संदेश प्रारूप को CSV में मैप नहीं किया जा सकता है। इसलिए, CSV केवल एक विशिष्ट डेटा उपयोग के मामले, सारणीबद्ध प्रारूप को शामिल करता है, जहां JSON और XML अधिक जटिल संदेश संरचनाओं को कवर कर सकते हैं।

— जॉन रेनोर

@JonRaynor: मुझे लगता है कि किसी भी XML या JSON फॉर्मेट को CSV में मैप किया जा सकता है - लेकिन सफाई से नहीं। आपको पेड़ की संरचना का प्रतिनिधित्व करने के कुछ तरीके का आविष्कार करना होगा। परिणाम बदसूरत होगा और लगभग निश्चित रूप से लागू करने के लायक नहीं होगा। लगभग सभी व्यावहारिक उद्देश्यों के लिए, आप सही हैं।

— कीथ थॉम्पसन

@ कीथ थोमसन ने इसका आविष्कार किया था :)

— एलिरन मलका

Answer 1

उत्तर है, यह निर्भर करता है।

CSV कुछ उपयोग मामलों के लिए बहुत अच्छा है। बड़े डेटासेट के लिए "स्ट्रीमिंग" प्रारूप के रूप में उदाहरण के लिए, XML / JSON से स्ट्रीम करना आसान है, और CSV फ़ाइलें बहुत कम संग्रहण स्थान लेती हैं। मैं इसे गीगाबाइट रेंज में डेटासेट स्ट्रीम करने के लिए उपयोग करता हूं जहां अन्य प्रारूप अव्यावहारिक हैं।

विरासत प्रणालियों और वर्कफ़्लोज़ से निपटने के दौरान कुछ उद्योगों में यह वास्तव में आम है। एमएस एक्सेल में JSON आयात करने का प्रयास करें।

ODI ने हाल ही में CSV के बारे में टिप्पणी की, 2014 को "CSV का वर्ष" कहा

"उचित" CSV फ़ॉर्मेटिंग के लिए, अपने HTTP प्रतिक्रियाओं में CSV माइम प्रकार का उपयोग करने पर विचार करें ।

Comments

विरासत प्रणालियों के लिए +1; जबकि पुराने सिस्टम एक इरादा ढंग से CSV का उपयोग नहीं किया जा सकता (मैं हाल ही में एक सीएसवी था कि एक रिपोर्ट, नहीं एक मेज का आयात, ईमानदारी से, के साथ सौदा करने के लिए किया है), हम करते हैं दुनिया भर में विरासत जानकारी से निपटने के लिए ।

— ब्रायन एस

CSV में स्ट्रीमिंग का लाभ है जो एक बड़ी बात है: CSV पार्सर में JSON या XML पार्सर की तुलना में बहुत कम स्थिति है।

— मैट

Answer 2

सबसे निश्चित रूप से नहीं।

CSV एक तालिका प्रारूप है जो डेटा सेट या अन्य सारणीबद्ध डेटा के लिए बहुत अच्छी तरह से मैप करता है। लेकिन सभी डेटा सारणीबद्ध नहीं है! आम तौर पर, हम ऑब्जेक्ट ग्राफ़ को क्रमबद्ध करना चाहते हैं । यह निम्नलिखित मामलों में मुश्किल हो सकता है:

• परिपत्र संदर्भ
• साझा उपसमूह (उदाहरण के लिए दो वस्तुएं जो दोनों एक ही वस्तु को एक सदस्य के रूप में समाहित करती हैं)
• विभिन्न प्रकार की वस्तुओं को एक ही दस्तावेज में क्रमबद्ध किया जाना है

हम आगे अपने भंडारण प्रारूप से वस्तुओं को मज़बूती से क्रमबद्ध करने में सक्षम होना चाहते हैं।

एक्सएमएल

मुख्य रूप से एक एक्स्टेंसिबल मार्कअप भाषा है। यह सामान्य डेटा संरचनाओं को भी स्टोर करने के लिए जूता-सींग लगाया जा सकता है। आईडी के लिए भाषा समर्थन का मतलब है कि जटिल रेखांकन बनाया जा सकता है, हालांकि यह पेड़ों के लिए सबसे अच्छा उपयोग किया जाता है। एक दस्तावेज को विनिर्देश के खिलाफ शुद्धता के लिए परीक्षण किया जा सकता है। इस प्रारूप के साथ कई समस्याएं हैं जो इसे अव्यवहारिक बना सकती हैं, जैसे कि चरम क्रिया।

JSON

मुख्य रूप से सरल वस्तु पेड़ों को संग्रहीत करने का एक तरीका है । सामान्य रेखांकन के लिए कोई समर्थन नहीं है। JSON में आदिम स्ट्रिंग , पूर्णांक , फ्लोट , बूलियन , नल और संग्रह प्रकार सरणी और ऑब्जेक्ट से परे प्रकार की कोई अवधारणा नहीं है ।

YAML

सबसे आसानी से JSON के विस्तार के रूप में समझा जाता है। एलियंस की एक धारणा है जो मनमाने ढंग से जटिलता के ऑब्जेक्ट ग्राफ़ बनाने की अनुमति देती है। मेटाडेटा की अवधारणा है जैसे टैग जो उचित टाइपिंग के लिए उपयोग किए जा सकते हैं।

सीएसवी

एक टेबल के अलावा कुछ भी नहीं है। अगर हम ऑब्जेक्ट ग्राफ को स्टोर करना चाहते हैं, तो हमें एक स्कीमा का उपयोग करना होगा

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

CSV की कई बोलियां हैं जो सीमांकक, लाइन टर्मिनेटर्स, उद्धरण, भागने वाले पात्रों और कई अन्य मुद्दों पर असहमत हैं जो इसे सामान्य (बाइनरी) डेटा के लिए अनुपयुक्त बनाते हैं। यह सब CSV डेटा को संसाधित करने के बजाय कठिन बनाता है।

इसलिए मूल रूप से, आसान चीजें सीएसवी के साथ कठिन या असंभव हैं, जब इसे सामान्य क्रमांकन प्रारूप के रूप में उपयोग किया जाता है।

समय सारणी या माप की एक श्रृंखला की तरह सही मायने में सारणीबद्ध डेटा को संग्रहीत करने के लिए इसका उपयोग करते समय यह आलोचना लागू नहीं होती है। यहां, CSV (अक्सर टैब अलग मूल्यों के प्रकार में) आमतौर पर अन्य डेटा प्रारूपों की तुलना में अधिक कॉम्पैक्ट और उपयोग करने में आसान होता है।

Comments

मुझे लगता है कि यह एक उचित तर्क है। वे अलग-अलग हैं, इसलिए उन्हें अलग-अलग चीजों के लिए उपयोग करें, प्रत्येक का उपयोग करें जहां यह सबसे अच्छा है।

— बेन

पहली पंक्ति के बिना यह एक अच्छा जवाब होगा। CSV सारणीबद्ध जानकारी के लिए XML का एक अच्छा विकल्प है (एक वितरण योग्य SQLite फ़ाइल शायद दोनों से बेहतर है)। लेकिन जैसा कि आप सारणीबद्ध डेटा के लिए समझाते हैं, यह बेहतर फ़ाइल विकल्प है।

Answer 3

मुझे यह भी कहना होगा कि यह इस बात पर निर्भर करता है कि आप क्या हासिल करना चाहते हैं। कई समस्याओं के लिए यह बहुत मायने नहीं रखता कि आप क्या चुनते हैं यदि समस्या काफी छोटी है और आपकी पसंद मौजूदा प्रणाली के साथ अच्छी तरह से फिट बैठती है।

एक विरासत प्रणाली को लेना और एक नए प्रारूप में ढालने की कोशिश करना कभी-कभी एक समस्या हो सकती है क्योंकि आपने अधिक जटिलता पेश की है और एक नई इनपुट प्रणाली को डीबग करना है। मैंने इसे बहुत देखा है जब नए लोग मौजूद चीज़ों की तुलना में कुछ अलग पसंद करते हैं, या जब एक नया प्रारूप दिखाई देता है और वे इसके साथ प्रयोग करना चाहते हैं। यह एक अच्छा विचार हो सकता है या नहीं भी हो सकता है, यह परिस्थितियों पर निर्भर करता है।

कई साल पहले मैंने एक शोध ग्राफ डेटाबेस प्रणाली पर काम किया था जो विभिन्न प्रारूपों के सीएसवी फाइलों पर निर्भर था। CSV फ़ाइल आयातक हमारे लिए रेखांकन बनाएंगे और कोड को डिबग और ऑप्टिमाइज़ करने के लिए कई वर्षों तक काम किया था। यह तेज और लचीला दोनों था और हम बड़ी शोध परियोजनाओं को बूटस्ट्रैप करने के लिए खुशी से इसका उपयोग करेंगे। जब XML उस दृश्य पर दिखाई दिया, जिसमें हमने XML आयातक जोड़ा था, लेकिन गति या व्यक्त जटिलता के संदर्भ में यह आवश्यक रूप से सुधार नहीं था, और निश्चित रूप से XML CSV की तुलना में ग्राफ संरचनाओं को व्यक्त करने में कोई बेहतर नहीं था। JSON XML की तुलना में बहुत अच्छा (और terser) है, लेकिन कई मामलों में समान है, इसलिए मैं उस सिस्टम पर एक नया आयातक बनाते समय एक समान परिणाम की उम्मीद करूंगा।

एक समय में हमारे पास एक ग्राहक भारी मात्रा में डेटा लाता था (जैसा कि हमने इसे "कोबोल" कहा था), चर लंबाई की पंक्तियों वाली फाइलें जिनमें मार्कर होते हैं, जो उस रेखा पर आने वाले बाइट्स की व्याख्या करने का संकेत देते हैं। यह ऐसे समय से आया है जब भंडारण महंगा था इसलिए कॉम्पैक्टनेस की आवश्यकता थी। हमने उस डेटा को मक्खी पर CSV प्रारूप में परिवर्तित करके और CSV आयातक में फ़ीड करके आयात किया। यह करना आसान था और डिबगिंग और रखरखाव की मात्रा कम से कम थी, जो अच्छी चीजें हैं। अगर हमें उस तरह के डेटा को आयात करना पड़ा, तो हो सकता है कि हमने प्रदर्शन और दक्षता हासिल करने के लिए इसे सीधे सिस्टम में बनाया हो।

तो, यह निर्भर करता है कि आप क्या कर रहे हैं और अंतर्निहित सिस्टम क्या करता है। मेरे उदाहरण में CSV आयातक ठोस रूप से इंजीनियर और भरोसेमंद थे। मैं आपको यह बताने में संकोच करूंगा कि एक प्रारूप बेहतर या बदतर था यह समझे बिना कि अन्य परतों में क्या चल रहा है। मैं JSON से प्यार करता हूं और इसे पसंद करता हूं, लेकिन मुझे पता है कि कुछ जटिल डेटा संरचनाओं और बड़े पर्याप्त डेटा सेटों को देखते हुए, CSV फ़ाइलों को बहुत अच्छी तरह से काम करने के लिए बनाया जा सकता है।

Answer 4

नहीं।

CSV वास्तव में एकल प्रारूप नहीं है। भागने के लिए शैलियों की एक विस्तृत विविधता है, विभाजक, और अन्य स्वरूपण मुद्दे जो जंगली में कई सीएसवी फाइलें हैं।

यदि आप इसे एक फ्लैट फ़ाइल स्टोरेज के रूप में उपयोग करने जा रहे हैं, तो JSON का उपयोग करने से आपको बहुत बेहतर सेवा मिलेगी। JSON ऐसे ऑब्जेक्ट्स से और कम से कम झंझट से दूर है जिनसे आपको CSV को ऐसा करने के लिए परेशान करना पड़ेगा।

Answer 5

मैं इसके खिलाफ पुरजोर सलाह दूंगा। मैं कुछ बिंदु पर CSV आउटपुट करने के लिए ठीक हो सकता हूं (यदि उपयोगकर्ता इसे अनुरोध करता है)। लेकिन यह भंडारण / आयात के उद्देश्यों के लिए खराब है। यह ज्यादातर इस तथ्य के कारण है कि "सीएसवी" बहुत बीमार है। क्या "C" "अल्पविराम" या "वर्ण" को अलग करता है? आप ऐसे टेक्स्ट स्ट्रिंग्स का इलाज कैसे करते हैं, जिसमें एस्केप कैरेक्टर्स होते हैं जैसे "? हर शापित CSV इंप्लीमेंट कैरेक्टर्स आदि से बचकर अलग-अलग तरीके से व्यवहार करता है, जिससे फाइलें निकलती हैं, जो पूर्व हो सकती हैं- लेकिन इम्पोर्टेड आदि।

एक्सेल एक अच्छा प्रदर्शन है: अंग्रेजी संस्करण में यह विभाजक के रूप में "," का उपयोग करता है। जर्मनी में, यह ";" का उपयोग करता है। इसलिए एक जर्मन संस्करण अंग्रेजी CSV फ़ाइलों पर चुटकुले, और इसके विपरीत ...

यह मुख्य ताकत है मानव पठनीयता, जिसे छूट नहीं दी जानी चाहिए। लेकिन मैं भंडारण के प्रारूप के रूप में इस पर भरोसा नहीं करता, यह उस उद्देश्य के लिए बहुत भंगुर है। यदि आपको मनुष्यों के लिए फ़ाइलें निर्यात करना है, तो आप CSV का उपयोग कर सकते हैं, लेकिन फिर भी मैं एक पुस्तकालय का उपयोग करने की कोशिश करूंगा जो xlsx फ़ाइलों को लिखता है (वे स्वतंत्र रूप से उपलब्ध हैं)।

Comments

यह "अल्पविराम" है, RFC 4180 देखें । सिर्फ इसलिए कि Microsoft ने जर्मनी में कुछ तोड़ दिया, इसका मतलब यह नहीं है कि एक मानकीकृत प्रारूप बेकार है ...

— बेन

नहीं, यह "कॉमा" नहीं है - इसका मतलब "चरित्र अलग" भी हो सकता है और समस्या जर्मनी तक ही सीमित नहीं है। हां, RFC अन्यथा निर्दिष्ट करता है, लेकिन "csv" नामक फ़ाइल में विभिन्न सेपरेटर, भागने की शैली आदि का एक बोझ हो सकता है जब आप ऐसी फ़ाइल आयात करने का प्रयास करते हैं तो आपका प्रोग्राम आयात करेगा ... कुछ, लेकिन वह नहीं जो आप चाहते हैं।

— क्रिश्चियन साउर

यह उत्तर CSV के खिलाफ महत्वपूर्ण नुकसान की पहचान करता है।

— gdbj

Answer 6

जनरल नं। क्यूं कर? JSON और XML मूल रूप से खूंखार CSV से छुटकारा पाने के लिए हैं। वे लंबे समय से सीएसवी के साथ असंरचित किए गए संरचित दृष्टिकोण हैं। हां, कुछ ऐसे उपयोग-मामले हैं जहां CSV को अभी भी पसंद किया जाता है लेकिन 10 में से 9 मामलों में सामान्य रूप से आप CSV का उपयोग नहीं कर रहे हैं।

Comments

जब तक आपके द्वारा स्थानांतरित किया जा रहा डेटा "फ्लैट" नहीं होता। फिर आप बेकार XML टैग्स को ट्रांसफर न करके एक बड़ी रकम बचाते हैं

— बेन