Show HN：逗号分隔值（CSV）到 Unicode 分隔值（USV）

USV 提案概述

• USV（Unicode Separated Values，Unicode 分隔值）是一种类似 CSV 的文本格式，使用 Unicode “控制图形”符号作为分隔符：
  • 单元、记录、组和文件分隔符（␟ ␞ ␝ ␜）。
  • 转义和其他修饰符（␛、␗、␖）。
• 预期好处：比 CSV 需要更少的转义、明确的多级层次结构（单元/记录/组/文件），以及带有 IETF 草案和建议 MIME 类型的明确定义语法。

*与 CSV 和现有 SV 格式的比较

• 许多人认为 CSV 已经“足够好”，并拥有庞大的生态支持（数据库、Excel、Unix 工具、库）。
• 对 CSV 的抱怨：
  • “标准”和转义规则不一致。
  • 本地化问题（逗号 vs 分号分隔符、小数逗号）。
  • 字段内允许换行，使解析复杂化。
• 反方观点：这些大多是工具或误用问题；CSV 的可人工编辑性和无处不在的普及度超过了它的缺点。
• 还有人指出，ASV（ASCII 分隔符 0x1C–0x1F）早已存在，也解决了许多转义问题，但缺少编辑器支持。

Unicode 控制图形 vs ASCII 控制字符

• USV 使用可见的字形（U+241C–U+241F），而不是实际的控制码（U+001C–U+001F）。
• 支持者认为：编辑器和复制/粘贴对这些可见、字母宽度的符号支持更稳定。
• 批评者认为：
  • 这些符号是用来 表示 控制字符，而不是 成为 控制字符；这模糊了语义。
  • 多字节分隔符在切分前需要先解码。
  • 这些符号很小、难以在视觉上区分；许多用户最终还是需要自定义字体或编辑器调整。
  • 有人认为它们与渲染后的 ASV 在视觉上等价，这属于“致命”的设计缺陷。

可读性、编辑与可访问性

• 对 USV 是否真正适合人类阅读存在分歧：
  • 有人反馈主流编辑器（Emacs 等）能很好地渲染示例；也有人需要大幅放大才能看清。
  • 规范中可选换行最初会产生很长的单行文件，破坏基于行的工具；作者后来更新了解析器/转换器以插入换行。
• 可访问性：
  • 有人声称屏幕阅读器对 USV 支持良好；但也有人测试的阅读器并不会朗读这些符号。

转义、SYN 与格式复杂度

• 该格式存在转义机制；批评者认为这削弱了“无需转义”的说法，并重现了 CSV 类似的复杂性。
• 对以下问题存在担忧：
  • 按类别区分的转义规则。
  • 额外修饰符，如 SYN 心跳和“忽略下一个字符”，它们会为同一逻辑文档带来多种字节级编码，并使校验和与解析器复杂化。
  • 在反馈之后，作者表示 SYN 将被移除，文档也会更新。

采用、标准化与实用性

• 许多人怀疑，如果没有 Excel/LibreOffice 和主流库的支持，USV 很难流行起来。
• 有人把它看作那张著名 XKCD 漫画里的“又一个标准”；建议改为：
  • 使用定义良好的 CSV（RFC 4180）、TSV、JSON/JSONLines，或有类型的二进制/表格格式（Parquet、Avro、SQLite）。
• 支持者认为编辑器和库 可以 随着时间演进，但批评者认为它相较现有文本或二进制格式没有令人信服的优势。

替代方案与相关想法

• 提到的替代方案包括：ASV、RSV（使用无效 UTF‑8 字节作为分隔符）、SML、JSONLines、Postgres 风格的 COPY TSV、emoji 分隔值，以及各种自定义方案。
• 还有人认为，改进对 ASCII 分隔符的支持，以及在编辑器中提供更好的表格模式，会比引入 USV 是更清晰的路径。