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

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

Se propone un nuevo formato “Unicode Separated Values” (USV) como reemplazo de CSV, usando símbolos Unicode visibles para los separadores ASCII tradicionales (unidad, registro, grupo, archivo) con el fin de reducir escapes y añadir jerarquía. Los comentaristas consideran la idea técnicamente interesante, pero cuestionan su practicidad: los símbolos son difíciles de leer a tamaño normal, editores y herramientas como Excel no lo soportan, y usar las versiones pictográficas de los caracteres de control se ve como conceptualmente incorrecto e innecesariamente complejo. La mayoría concluye que, sin una fuerte adopción y herramientas adecuadas, USV no desplazará a CSV ni a alternativas más simples como TSV, JSON o esquemas de separación basados en ASCII.

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.