CSV फ़ॉर्मैट के नाम एक प्रेमपत्र

 (github.com/medialab)
4 पॉइंट द्वारा GN⁺ 2025-03-27 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • CSV को बदलने वाले "श्रेष्ठ" फ़ॉर्मैट अक्सर पेश किए जाते हैं, लेकिन ज़्यादातर तुलना पक्षपाती होती है और CSV की असली ताकतों को नज़रअंदाज़ करती है
  • इस लेख का मकसद यह कहना नहीं है कि CSV परफ़ेक्ट है, बल्कि इसके कम आंके गए फ़ायदों पर रोशनी डालना है
  • CSV से नफ़रत करना कूल समझे जाने वाले माहौल के उलट, यह लेख CSV की असली अहमियत को फिर से याद दिलाता है

1. CSV बेहद सरल है

  • CSV की परिभाषा उसके नाम में ही है: "comma-separated values"
  • पंक्तियाँ newline से और कॉलम comma से अलग होते हैं
  • अगर किसी value में comma या newline हो, तो उसे quotes में रखा जाता है, और quote को खुद double quote से दर्शाया जाता है
  • बिना किसी जटिल specification के, कोई भी इसे सहज रूप से समझ और इस्तेमाल कर सकता है
  • फिर भी, सही parsing के लिए dedicated CSV parser का उपयोग करना अब भी ज़रूरी है

2. CSV एक सामूहिक विचार है

  • इसका कोई मालिक नहीं है, यह निजी नियंत्रण में नहीं है
  • RFC 4180 मौजूद है, लेकिन ज़्यादातर लोग इसे सिर्फ़ संदर्भ के रूप में देखते हैं
  • यह दुनिया भर के developers द्वारा चुपचाप साझा किए गए आम नियमों पर आधारित एक मुक्त फ़ॉर्मैट है

3. CSV टेक्स्ट है

  • JSON, YAML, XML की तरह यह भी इंसानों द्वारा पढ़ा जा सकने वाला pure text फ़ॉर्मैट है
  • इसे किसी भी text editor में खोला जा सकता है, और बिना अलग tool के भी इसकी सामग्री देखी जा सकती है
  • encoding का तरीका भी अपनी ज़रूरत के अनुसार चुना जा सकता है

4. CSV streaming के लिए अनुकूलित है

  • क्योंकि इसे line-by-line पढ़ा जाता है, इसलिए memory की खपत बहुत कम होती है
  • साधारण code से भी कई gigabytes डेटा को सिर्फ़ कुछ KB memory में process किया जा सकता है
  • Parquet जैसे column-oriented फ़ॉर्मैट में streaming processing कठिन होती है और जटिल buffering चाहिए होती है
  • इसकी कमी यह है कि अगर आपको सिर्फ़ कोई एक कॉलम देखना हो, तब भी पूरी row पढ़नी पड़ती है

5. CSV में आसानी से data append किया जा सकता है

  • फ़ाइल को append mode(a+) में खोलकर आखिर में नई rows जोड़ना बहुत आसान है
  • इसके उलट Parquet जैसे column-oriented फ़ॉर्मैट में row जोड़ना अक्षम और जटिल होता है

6. CSV dynamic types को सपोर्ट करता है

  • इसमें fixed types नहीं होते, इसलिए डेटा की व्याख्या लचीले ढंग से की जा सकती है
  • उदाहरण: JavaScript 64-bit integers को ठीक से represent नहीं कर पाता, लेकिन CSV में ऐसी पाबंदी नहीं है
  • इससे भाषाओं के बीच compatibility और flexibility का फ़ायदा मिलता है
  • लेकिन अगर गलत interpret किया जाए तो error हो सकती है → इसलिए इस्तेमाल में सावधानी चाहिए
  • अगर high performance चाहिए, तो text decode किए बिना binary स्तर पर सीधे processing भी संभव है

7. CSV संक्षिप्त है

  • header सिर्फ़ फ़ाइल की शुरुआत में होता है, इसलिए फ़ॉर्मैट की पुनरावृत्ति लगभग नहीं होती
  • JSON और XML में keys की पुनरावृत्ति के कारण overhead ज़्यादा होता है
  • string representation भी पहले से संक्षिप्त है, और फ़ॉर्मैट का खुद का overhead (comma, quotes आदि) बहुत कम है

8. उलटा किया गया CSV भी फिर भी वैध रहता है

  • CSV को byte स्तर पर उलट देने पर भी वह अब भी वैध CSV रहता है
  • यह double quote escaping के तरीके की वजह से संभव है, क्योंकि यह palindrome जैसी escaping शैली है
  • इस गुण की वजह से CSV फ़ाइल के आख़िरी हिस्से को बहुत कुशलता से पढ़ा जा सकता है
  • उदाहरण: किसी रुकी हुई process को फिर से शुरू करते समय, फ़ाइल की आख़िरी कुछ lines पढ़कर restart किया जा सकता है

9. Excel को CSV पसंद नहीं है

  • अगर Excel को कोई फ़ॉर्मैट असुविधाजनक लगता है, तो शायद यह इस बात का संकेत है कि आप सही रास्ते पर हैं

संबंधित पढ़ाई

3 टिप्पणियां

 
ng0301 2025-03-29

सरल ही सबसे बेहतर है!
 
ethanhur 2025-03-27

Worse is better!
 
GN⁺ 2025-03-27
Hacker News टिप्पणियाँ

  • लोगों को CSV और INI फ़ाइलें इसलिए पसंद हैं क्योंकि वे सरल हैं, text-based हैं, फ़ॉर्मैट में types encode नहीं होते, और वे सिर्फ strings से बनी होती हैं

    • आधिकारिक standard न होना एक कमी है, लेकिन ये अपना काम अच्छी तरह करती हैं
    • TOML पर INI की आलोचना को बुकमार्क करके रखा है
    • लगता है कि TOML की आलोचना की पहली पंक्ति CSV पर भी लागू होती है: यह कई dialects का एक संघ है

  • CSV सुंदर है, लेकिन इसमें एक घातक कमी है — quotes का असर "non-local" होता है

    • उदाहरण के लिए, byte 1 पर एक quote byte 1000000 पर comma का मतलब बदल सकता है
    • इससे दो असुविधाजनक परिणाम सामने आते हैं
      • CSV processing को parallelize करना मुश्किल होता है
      • data corruption का फ़ाइल की readability पर बहुत बड़ा असर पड़ता है (एक quote का छूट जाना या अतिरिक्त जुड़ जाना सब कुछ बिगाड़ सकता है)
    • इसलिए आजकल सरल tabular data serialization के लिए CSV की बजाय simple escaping को प्राथमिकता दी जाती है

  • CSV की सबसे अच्छी बात यह है कि कोई भी 30 मिनट में parser लिख सकता है

    • 90 के दशक की शुरुआत के data को आधुनिक web services में आसानी से लाया जा सकता है
    • सबसे बुरी बात भी यही है कि कोई भी 30 मिनट में parser लिख सकता है
    • गलत implementations, गलत data, और अजीब undefined behavior पैदा होना आसान है
    • JSON और YAML में भी मिलती-जुलती समस्याएँ हैं
    • XML थोड़ा बदसूरत लगता है, लेकिन सबसे मज़बूत वही प्रतीत होता है

  • जिसे CSV पसंद है, उससे शायद कभी enterprise environment में CSV injection prevention संभालने के लिए नहीं कहा गया होगा

    • web पर अच्छे resources कम हैं
    • सबसे अच्छा resource <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">यहाँ</a> है

  • CSV को पसंद करने के कई कारण हैं

    • C में program लिखकर सीधे कई चीज़ों को CSV के रूप में output किया जा सकता है
    • लगभग हर database या सामान्य "चीज़" से CSV में आसानी से बदलने वाला simple middleware लिखा जा सकता है
    • CSV को Excel में डालकर मनचाही हर चीज़ की जा सकती है
    • ini फ़ाइलें भी पसंद हैं। उन्हें Notepad में सीधे edit किया जा सकता है
    • लेकिन अच्छा होता अगर कोई सामान्य outline/structure भी होता

  • हाल में Raspberry Pi आधारित solution विकसित किया जा रहा है

    • पहली implementation में SQLite database इस्तेमाल किया गया था, लेकिन power cycling के कुछ दिनों बाद वह corrupt हो गया
    • Parquet files को देखा, लेकिन वे append-only workloads के लिए अनुकूल नहीं हैं
    • IPC फ़ाइल में events log करके समय-समय पर उन्हें Parquet file में "flush" करने का तरीका लागू किया गया
    • यह काम करता है और efficient भी है, लेकिन इसे सही तरह से implement करना आसान नहीं है
    • आम developers के लिए CSV (या JSONL) अब भी सबसे अच्छा है

  • CSV की एक कम मज़ेदार बात यह है कि जल्दी में लिखे गए parser और serializer अक्सर quotes को गलत handle करने वाली आम गलतियों को दोहराते हैं

    • लंबे समय तक CSV से सावधान रहा, लेकिन Python सीखने और उसके शानदार csv standard library module का उपयोग करने के बाद राय बदल गई

  • अगर यह सचमुच एक love letter होता, तो इसे CSV format में लिखा गया होता

  • JSON के खिलाफ़ तर्क बहुत ज़्यादा प्रभावशाली नहीं हैं

    • हर field में नाम जोड़ना ज़रूरी नहीं है
    • CSV और JSON की तुलना करें तो JSON थोड़ा बड़ा है, लेकिन braces यह दिखाते हैं कि कुछ simple भी हो सकता है और complex भी
    • CSV इतना simple है कि अक्सर parsing/encoding libraries का उपयोग ही नहीं किया जाता
    • JSON parser हमेशा अपेक्षित values output करता है, और भाषा शायद बहुत efficient SIMD-based parser का इस्तेमाल करती है
    • standardization की समस्या भी है। CSV file comma, space, semicolon, pipe आदि में क्या इस्तेमाल करती है, CR, LF, CRLF में क्या इस्तेमाल करती है, quotes को escape किया जा सकता है या नहीं — ऐसे सवाल रहते हैं
    • JSON में ऐसी समस्याएँ नहीं हैं
    • JSON में types हैं। 6 types होना, types न होने से बेहतर है
    • JSON perfect नहीं है, लेकिन आम तौर पर CSV से बेहतर है

  • आधुनिक formats पसंद करने वाले व्यक्ति के रूप में, संदेह होने पर CSV या JSONL का उपयोग किया जाता है

    • क्योंकि यह ज़्यादातर plain text होता है, इसे grep से आसानी से खोजा जा सकता है और यह streaming के लिए उपयुक्त है
    • दस्तावेज़ में सूचीबद्ध अधिकांश features JSONL में भी मिलते हैं
    • यह gzip या zstd से अच्छी तरह compress हो जाता है
    • compression plain text के कुछ फ़ायदे कम कर देता है, लेकिन ripgrep compressed files में भी खोज सकता है
    • JSONL का एक और फ़ायदा यह है कि इसे छोटी files में आसानी से बाँटा जा सकता है