Ferramentas de desenvolvedor · Conversores de sintaxe
Padrão ausente de CSV: o que RFC 4180 cobre e o que deixa em aberto
· Fundo
csv JSON formatos de dados
CSV é anterior a qualquer especificação, e aquela RFC que a descreve é informativa e deliberadamente restrita. Esta postagem explica o que RFC 4180 define, sobre o que não diz nada e por que a conversão de CSV é, portanto, sempre uma negociação.
De quem CSV está correto? — duas exportações da mesma tabela, uma com ponto e vírgula e outra com vírgulas, ambas chamadas CSV
ToolAcre pode emitir saída delimitada por vírgula, ponto e vírgula ou tabulação de JSON. Ele não lê duas exportações CSV concorrentes nem declara nenhuma delas correta. CSV é somente gravação aqui, então a escolha do delimitador é uma opção de saída explícita em vez de um algoritmo de detecção.
Essa distinção evita um deslize factual comum. Uma interface que pode escrever ponto-e-vírgula não provou que pode identificar ponto-e-vírgula em um arquivo desconhecido, manipular decimais de localidade ou interpretar cabeçalhos. Essas são responsabilidades de entrada separadas deliberadamente excluídas.
Duas opções de delimitador são opções de saída, não são evidências de que este painel lê qualquer arquivo
O repositório não contém nenhuma fonte para planilhas antigas ou histórico de banco de dados, portanto o artigo não inventa uma cronologia. Começa com o gravador atual e seus testes: registros, campos, delimitadores, terminação CRLF e escape de cotação.
O contexto histórico pode ser adicionado posteriormente com fontes revisadas. A implementação de um conversor é uma evidência do que o produto escreve hoje, não de quando uma convenção apareceu pela primeira vez ou por que os fornecedores divergiram.
O histórico de CSV antes de RFC 4180 está fora da evidência do repositório
Um campo que contém o delimitador, aspas duplas, retorno de carro ou alimentação de linha é colocado entre aspas duplas e cada aspa incorporada é duplicada. Os espaços em branco à esquerda ou à direita também são citados para evitar cortes comuns em planilhas. Os registros terminam com CRLF e o arquivo é finalizado.
Esses comportamentos seguem regras de estilo RFC 4180 testadas no repositório. O artigo evita reivindicar conformidade universal porque o autor também suporta delimitadores alternativos e adiciona tratamento de segurança fora da gramática restrita.
O escritor usa citações no estilo RFC 4180 e CRLF sem reivindicar conformidade total com o padrão
As células CSV não preservam os tipos JSON. String nula e vazia tornam-se células vazias, enquanto booleanos e números tornam-se representações de texto. O conteúdo UTF-8 é transmitido e um BOM opcional pode ser prefixado para consumidores que precisam dele.
A interpretação de localidade não está incorporada. Um delimitador de ponto e vírgula pode coexistir com vírgulas decimais, mas o gravador não reformata números por localidade nem codifica um tipo de data. O aplicativo receptor ainda decide como interpretar cada campo.
Os limites de codificação, tipo e localidade permanecem explícitos neste escritor
As variações implementadas são vírgula, ponto e vírgula e tabulação, além de um BOM opcional. Texto semelhante a uma fórmula começando com `=`, `+`, `-`, `@`, tabulação ou retorno de carro é prefixado com um apóstrofo por padrão, portanto, as planilhas o tratam como texto. Os usuários podem desativar essa proteção e receber um aviso.
Não há dica `sep=` ou modo de escape de barra invertida neste gravador. Mencioná-los como opções enviadas seria falso. Aspas incorporadas usam duplicação, exatamente como afirmam os testes.
As variações observadas na planilha são limitadas às opções e proteções implementadas aqui
Cada suposição nesta rota começa a partir de JSON analisado: qual valor fornece linhas, como o aninhamento se nivela em colunas pontilhadas e quais chaves se tornam cabeçalhos. Nenhuma suposição é feita sobre um dialeto CSV de entrada porque CSV de entrada é rejeitado.
Esta correção inverte a direção solicitada da pasta de trabalho. Um fluxo de trabalho CSV-to-JSON deve escolher delimitador, aspas, cabeçalho e tipos de células em outra ferramenta. O erro de ToolAcre explica essa recusa em vez de adivinhar silenciosamente.
As suposições de conversão se aplicam a JSON-to-CSV somente porque a entrada CSV foi recusada
Reparar CSV malformado está fora do escopo. Aspas quebradas, codificações mistas e delimitadores acidentais precisam do limpador CSV ou de outro analisador com diagnóstico explícito. O conversor de sintaxe recebe texto JSON estrito, não danificado CSV.
A saída ainda pode ser inadequada para um destino quando uma árvore aninhada cria colunas pontilhadas ambíguas ou excede colunas 2,000. Avisos e limites expõem essas falhas no formato da tabela antes do download.
Conclusão: CSV é uma convenção, não um formato - e como o painel de conversores de sintaxe transforma um arquivo bem formado em JSON você pode inspecionar
Trate CSV como uma convenção cujas escolhas devem estar visíveis. ToolAcre documenta suas escolhas de saída e recusa o reverso subespecificado. Isso é mais confiável do que usar um botão para duas tarefas fundamentalmente diferentes.
Inspecione o delimitador, aspas, CRLF, BOM e a fórmula que escapa no sistema receptor. Se a análise de entrada for necessária, use uma ferramenta que pergunte em vez de transferir as convenções do escritor para um arquivo desconhecido.
Uma verificação prática de aceitação abre o arquivo gerado no consumidor pretendido e também examina os bytes ou texto bruto. A visão do consumidor detecta problemas de exibição e importação; a visualização bruta confirma delimitador, aspas duplas, CRLF e um BOM opcional sem reinterpretação da planilha. Teste strings semelhantes a fórmulas como texto inerte e um número negativo como um número. Essas verificações emparelhadas verificam o contrato real do redator sem afirmar que cada programa implementa convenções CSV de forma idêntica.