CSV para JSON

CSV parece trivial de analisar — dividir cada linha por vírgulas, tratar a primeira linha como cabeçalhos — até que um valor nos dados reais contenha uma vírgula própria, o que acontece constantemente com exportações reais de planilhas: um endereço como "123 Main St, Apt 4", um nome de empresa como "Smith, Jones & Co", ou uma descrição de produto contendo uma lista. A especificação CSV, formalizada como RFC 4180, lida com isso permitindo que um campo seja envolvido em aspas duplas, dentro das quais vírgulas, quebras de linha e até caracteres de aspas literais (escapados duplicando-os) são simplesmente dados em vez de estrutura. Um analisador que ingenuamente divide por cada vírgula, ignorando aspas completamente, corrompe exatamente essas linhas — dividindo "Smith, Jones & Co" em duas colunas separadas — e geralmente faz isso silenciosamente, sem nenhum erro sinalizando que algo deu errado, o que é o que torna esse erro perigoso em vez de apenas incômodo.

A análise corretamente ciente de aspas rastreia se o leitor está atualmente dentro de um campo entre aspas e ignora caracteres delimitadores e de quebra de linha até chegar à aspa de fechamento, que é a única forma de reconstruir corretamente campos que legitimamente contêm os caracteres que de outra forma seriam confundidos com estrutura.

Todo valor em um arquivo CSV bruto é texto, já que CSV não tem nenhum conceito nativo de número, booleano ou nulo — uma célula contendo `42` e uma célula contendo `hello` são armazenadas de forma idêntica como caracteres. A inferência de tipos é o processo de adivinhar quais strings estavam "realmente" destinadas a ser números, valores verdadeiro/falso ou nulos, e convertê-las de acordo para que o JSON resultante tenha valores realmente tipados em vez de tudo entre aspas como uma string.

No entanto, o palpite precisa ser conservador, porque bastantes valores que parecem numéricos não são destinados a ser tratados como números de jeito nenhum. Um zero à esquerda — `007`, `042` — normalmente sinaliza um identificador ou um código preenchido onde o zero inicial é significativo e seria silenciosamente destruído ao converter para um número, já que `7` e `007` são o mesmo número mas identificadores muito diferentes. Um número de telefone como `+44 20 7946 0958` parece parcialmente numérico mas não são dados aritméticos. Valores além do intervalo inteiro seguro do JavaScript perdem precisão se convertidos para um número de jeito nenhum. Esta ferramenta deixa todos esses como strings especificamente porque adivinhar errado aqui significa corromper dados silenciosamente de uma forma fácil de passar despercebida até muito depois.

Um objeto JSON não pode ter duas chaves com o mesmo nome — a segunda encontrada simplesmente sobrescreve a primeira, descartando silenciosamente o valor de uma coluna inteira sem nenhum erro levantado em lugar algum. Exportações de planilhas produzem cabeçalhos duplicados com mais frequência do que parece provável: um relatório com duas colunas "Total" com escopos distintos, ou uma exportação fundida de duas fontes que por acaso ambas usam "Nome". Detectar duplicatas e renomear a segunda ocorrência para `name_2` preserva os dados de cada coluna em vez de silenciosamente perder qualquer uma que por acaso aparecesse primeiro no objeto de linha. Cabeçalhos em branco recebem o mesmo tratamento pela mesma razão, já que JSON não tem como representar uma chave que seja simplesmente uma string vazia como um campo significativo e endereçável.