Show HN: Valores Separados por Vírgula (CSV) para Valores Separados por Unicode (USV)

Visão geral da proposta USV

• USV (Unicode Separated Values) é um formato de texto semelhante a CSV que usa símbolos Unicode de “controle pictórico” como separadores:
  • Separadores de unidade, registro, grupo e arquivo (␟ ␞ ␝ ␜).
  • Escape e outros modificadores (␛, ␗, ␖).
• Benefícios pretendidos: menos escapes do que CSV, hierarquia explícita de múltiplos níveis (unidade/registro/grupo/arquivo) e sintaxe bem definida com um rascunho do IETF e tipo MIME proposto.

*Comparação com CSV e formatos SV existentes

• Muitos consideram CSV “bom o suficiente”, com enorme suporte no ecossistema (bancos de dados, Excel, ferramentas Unix, bibliotecas).
• Reclamações sobre CSV:
  • “Padrão” inconsistente e regras de escape inconsistentes.
  • Problemas de localidade (separadores vírgula vs ponto e vírgula, vírgulas decimais).
  • Quebras de linha permitidas dentro de campos complicam o parsing.
• Contra-argumento: esses são principalmente problemas de ferramentas/uso indevido; a capacidade de edição humana e a onipresença do CSV superam as falhas.
• Vários observam que os separadores ASV (ASCII 0x1C–0x1F) já existem e resolvem muitos problemas de escape, mas carecem de suporte em editores.

Pictogramas de controle Unicode vs caracteres de controle ASCII

• USV usa os glifos visíveis (U+241C–241F), e não os códigos de controle reais (U+001C–001F).
• Defensores: editores e copiar/colar funcionam de forma mais confiável com símbolos visíveis e de largura de letra.
• Críticos:
  • Esses símbolos foram feitos para representar caracteres de controle, não para ser os próprios; isso embaralha a semântica.
  • Delimitadores multibyte exigem decodificação antes da separação.
  • Os símbolos são pequenos e difíceis de distinguir visualmente; muitos usuários precisariam de fontes customizadas ou ajustes no editor de qualquer forma.
  • Alguns acham que a equivalência visual ao ASV renderizado é um defeito de design “fatal”.

Legibilidade, edição e acessibilidade

• Há discordância sobre se o USV é realmente amigável para humanos:
  • Alguns relatam que editores comuns (Emacs, etc.) exibem os exemplos bem; outros precisam dar zoom consideravelmente.
  • Quebras de linha opcionais na especificação inicialmente geravam arquivos longos em uma única linha, quebrando ferramentas baseadas em linhas; o autor depois atualizou o conversor para inserir quebras de linha.
• Acessibilidade:
  • Alega-se que leitores de tela lidam bem com USV; outros testam leitores que não anunciam os símbolos.

Escape, SYN e complexidade do formato

• Existe um mecanismo de escape; críticos argumentam que isso enfraquece a alegação de que “não é necessário escape” e reproduz a complexidade do CSV.
• Preocupações com:
  • Regras de escape dependentes de classe.
  • Modificadores extras como o heartbeat SYN e “ignorar próximo caractere”, que criam múltiplas codificações em nível de byte para o mesmo documento lógico e complicam checksums e parsers.
  • Após feedback, o autor indica que SYN será removido e a documentação será atualizada.

Adoção, padronização e praticidade

• Muitos duvidam que o USV ganhe tração sem suporte do Excel/LibreOffice e de grandes bibliotecas.
• Alguns veem isso como “mais um padrão”, como no famoso quadrinho XKCD; a sugestão é usar em vez disso:
  • CSV bem especificado (RFC 4180), TSV, JSON/JSONLines, ou formatos tabulares/binários tipados (Parquet, Avro, SQLite).
• Defensores argumentam que editores e bibliotecas poderiam evoluir, mas os críticos não veem vantagem convincente sobre formatos já existentes de texto ou binários.

Alternativas e ideias relacionadas

• Alternativas mencionadas: ASV, RSV (usando bytes inválidos de UTF-8 como delimitadores), SML, JSONLines, COPY TSV no estilo Postgres, valores separados por emoji e vários esquemas personalizados.
• Vários defendem que melhorar o suporte a separadores ASCII e modos de tabela melhores em editores seria um caminho mais limpo do que introduzir o USV.