Show HN: Comma Separated Values (CSV) to Unicode Separated Values (USV)

मूल लेख ↗ Hacker News चर्चा ↗

USV प्रस्ताव का अवलोकन

  • USV (Unicode Separated Values) एक CSV-जैसा टेक्स्ट फ़ॉर्मैट है जो सेपरेटर के रूप में Unicode “control picture” प्रतीकों का उपयोग करता है:
    • Unit, record, group, और file separators (␟ ␞ ␝ ␜).
    • Escape और अन्य modifiers (␛, ␗, ␖).
  • अपेक्षित लाभ: CSV की तुलना में कम escapes, स्पष्ट बहु-स्तरीय hierarchy (unit/record/group/file), और IETF draft तथा प्रस्तावित MIME type के साथ सुव्यवस्थित syntax।

*CSV और मौजूदा SV फ़ॉर्मैट्स से तुलना

  • कई लोगों के लिए CSV “काफ़ी अच्छा” है, और इसके लिए बहुत बड़ा ecosystem support मौजूद है (databases, Excel, Unix tools, libraries).
  • CSV पर शिकायतें:
    • असंगत “standard” और escaping नियम।
    • locale समस्याएँ (comma बनाम semicolon separators, decimal commas)।
    • fields के भीतर newlines की अनुमति parsing को जटिल बनाती है।
  • प्रत्युत्तर: ये ज़्यादातर tooling/abuse समस्याएँ हैं; CSV की human-editability और व्यापकता इसकी कमियों पर भारी पड़ती है।
  • कई लोगों ने नोट किया कि ASV (ASCII separators 0x1C–0x1F) पहले से मौजूद है और escaping की कई समस्याएँ हल करता है, लेकिन editor support की कमी है।

Unicode Control Pictures बनाम ASCII Control Characters

  • USV दृश्य glyphs (U+241C–241F) का उपयोग करता है, वास्तविक control codes (U+001C–001F) का नहीं।
  • समर्थकों का कहना है: editors और copy/paste दिखाई देने वाले, letter-width symbols के साथ अधिक भरोसेमंद काम करते हैं।
  • आलोचक:
    • ये symbols control chars को represent करने के लिए हैं, होने के लिए नहीं; इससे semantics धुंधली हो जाती है।
    • Multi-byte delimiters को split करने से पहले decode करना पड़ता है।
    • Symbols बहुत छोटे हैं और visually अलग पहचानना कठिन है; कई उपयोगकर्ताओं को custom fonts या editor tweaks की ज़रूरत होगी ही।
    • कुछ लोग rendered ASV से visual equivalence को एक “show-stopping” design flaw मानते हैं।

पठनीयता, संपादन, और पहुँच-योग्यता

  • यह विवाद है कि USV वास्तव में human-friendly है या नहीं:
    • कुछ रिपोर्ट करते हैं कि mainstream editors (Emacs, etc.) उदाहरण ठीक से render करते हैं; अन्य लोगों को बहुत ज़्यादा zoom करना पड़ता है।
    • spec में वैकल्पिक newlines ने शुरू में लंबे single-line files बनाए, जिससे line-based tools टूट गए; बाद में लेखक ने converter को newlines जोड़ने के लिए अपडेट किया।
  • पहुँच-योग्यता:
    • दावा है कि screen readers USV को अच्छी तरह संभालते हैं; अन्य लोगों ने ऐसे readers परीक्षण किए जो symbols को announce नहीं करते।

Escaping, SYN, और फ़ॉर्मैट की जटिलता

  • एक escape mechanism मौजूद है; आलोचकों का कहना है कि यह “no escaping needed” वाले दावे को कमजोर करता है और CSV जैसी जटिलता दोहराता है।
  • चिंताएँ:
    • class-dependent escaping rules।
    • SYN heartbeat और “ignore next char” जैसे अतिरिक्त modifiers, जो एक ही logical document के लिए कई byte-level encodings बनाते हैं और checksums तथा parsers को जटिल करते हैं।
    • feedback के बाद लेखक संकेत देता है कि SYN हटाया जाएगा और docs अपडेट होंगे।

Adoption, Standardization, और व्यावहारिकता

  • कई लोगों को संदेह है कि Excel/LibreOffice और प्रमुख libraries के समर्थन के बिना USV को traction मिलेगा।
  • कुछ इसे प्रसिद्ध XKCD comic के अनुसार “another standard” मानते हैं; सुझाव है कि इसके बजाय:
    • अच्छी तरह निर्दिष्ट CSV (RFC 4180), TSV, JSON/JSONLines, या typed binary/tabular formats (Parquet, Avro, SQLite) का उपयोग किया जाए।
  • समर्थकों का तर्क है कि editors और libraries विकसित हो सकते हैं, लेकिन आलोचक मौजूदा text या binary formats पर कोई compelling upside नहीं देखते।

विकल्प और संबंधित विचार

  • उल्लिखित विकल्प: ASV, RSV (delimiters के रूप में invalid UTF‑8 bytes का उपयोग), SML, JSONLines, Postgres-style COPY TSV, emoji-separated values, और विभिन्न custom schemes.
  • कई लोग तर्क देते हैं कि ASCII separators के लिए support सुधारना और editors में बेहतर table modes लाना USV लाने से साफ़-सुथरा रास्ता होगा।