Show HN: Valores Separados por Comas (CSV) a Valores Separados por Unicode (USV)

Artículo original ↗ Discusión en Hacker News ↗

Resumen de la propuesta de USV

  • USV (Unicode Separated Values) es un formato de texto similar a CSV que usa símbolos Unicode de “control picture” como separadores:
    • Separadores de unidad, registro, grupo y archivo (␟ ␞ ␝ ␜).
    • Escape y otros modificadores (␛, ␗, ␖).
  • Beneficios previstos: menos escapes que CSV, jerarquía multinivel explícita (unidad/registro/grupo/archivo) y sintaxis bien definida con un borrador de la IETF y un tipo MIME propuesto.

*Comparación con CSV y formatos SV existentes

  • Muchos consideran que CSV es “suficientemente bueno”, con un enorme ecosistema de soporte (bases de datos, Excel, herramientas Unix, bibliotecas).
  • Quejas sobre CSV:
    • “Estándar” inconsistente y reglas de escape inconsistentes.
    • Problemas de locale (separadores coma vs. punto y coma, comas decimales).
    • Los saltos de línea permitidos dentro de los campos complican el análisis.
  • Contraargumento: estos son sobre todo problemas de herramientas/abuso; la facilidad de edición manual de CSV y su ubicuidad compensan sus defectos.
  • Varios señalan que ya existen ASV (ASCII separators 0x1C–0x1F) y resuelven muchos problemas de escape, pero carecen de soporte en editores.

Control pictures de Unicode vs. caracteres de control ASCII

  • USV usa los glifos visibles (U+241C–241F), no los códigos de control reales (U+001C–001F).
  • Los defensores dicen que los editores y el copiar/pegar funcionan de forma más fiable con símbolos visibles y de ancho de letra.
  • Los críticos:
    • Estos símbolos están pensados para representar caracteres de control, no para ser esos caracteres; eso difumina la semántica.
    • Los delimitadores de varios bytes requieren decodificación antes de separar.
    • Los símbolos son pequeños y difíciles de distinguir visualmente; muchos usuarios necesitarían fuentes personalizadas o ajustes del editor igualmente.
    • Algunos consideran que la equivalencia visual con ASV renderizado es un fallo de diseño “demoledor”.

Legibilidad, edición y accesibilidad

  • Hay desacuerdo sobre si USV es realmente amigable para humanos:
    • Algunos informan que editores convencionales (Emacs, etc.) muestran los ejemplos bien; otros necesitan hacer zoom mucho.
    • Los saltos de línea opcionales en la especificación al principio generaban archivos largos de una sola línea, rompiendo herramientas basadas en líneas; más tarde el autor actualizó el conversor para insertar saltos de línea.
  • Accesibilidad:
    • Se afirma que los lectores de pantalla manejan bien USV; otros prueban lectores que no anuncian los símbolos.

Escape, SYN y complejidad del formato

  • Existe un mecanismo de escape; los críticos sostienen que eso socava la idea de que “no se necesita escape” y reproduce la complejidad de CSV.
  • Preocupaciones sobre:
    • Reglas de escape dependientes de la clase.
    • Modificadores adicionales como SYN heartbeat e “ignore next char”, que crean múltiples codificaciones a nivel de byte para el mismo documento lógico y complican checksums y parsers.
    • Tras recibir comentarios, el autor indica que SYN se eliminará y la documentación se actualizará.

Adopción, estandarización y practicidad

  • Muchos dudan de que USV gane tracción sin soporte de Excel/LibreOffice y de bibliotecas principales.
  • Algunos lo ven como “otro estándar” según el famoso cómic de XKCD; la sugerencia es usar en su lugar:
    • CSV bien especificado (RFC 4180), TSV, JSON/JSONLines, o formatos binarios/tabulares tipados (Parquet, Avro, SQLite).
  • Los defensores argumentan que editores y bibliotecas podrían evolucionar, pero los críticos no ven una ventaja convincente frente a formatos de texto o binarios ya existentes.

Alternativas e ideas relacionadas

  • Se mencionan alternativas: ASV, RSV (usando bytes UTF‑8 inválidos como delimitadores), SML, JSONLines, COPY TSV al estilo Postgres, valores separados por emoji y varios esquemas personalizados.
  • Varios sostienen que mejorar el soporte de separadores ASCII y modos de tabla mejores en editores sería un camino más limpio que introducir USV.