Por que exportações CSV de planilhas quebram quando você as converte
Uma exportação CSV parece dados simples, claramente estruturados. No momento em que aparece um endereço real, um zero à esquerda ou uma quebra de linha embutida, essa simplicidade se revela uma ilusão.
· 4 min de leitura
Por que o CSV parece trivial e não é
Um arquivo CSV parece tão simples quanto um formato de dados pode ser — dividir cada linha por vírgulas, tratar a primeira linha como cabeçalhos de coluna, pronto — e essa aparente simplicidade é exatamente o que torna tão fácil usar o formato de forma errada assim que dados do mundo real aparecem nele. A abordagem ingênua de dividir por vírgulas funciona perfeitamente em um exemplo de brinquedo e quebra logo na primeira linha em que um valor de dado real contém uma vírgula própria, o que é uma ocorrência rotineira, não um caso extremo: um endereço como "Rua Principal, 123, Apto 4", um nome de empresa como "Silva, Souza & Cia." ou uma descrição de produto que inclui uma lista são todos valores completamente normais que legitimamente contêm exatamente o caractere que um analisador ingênuo está usando como separador de campos.
Como o CSV realmente lida com vírgulas dentro de um valor real — e como ferramentas ingênuas erram
A especificação do CSV resolve o problema da vírgula embutida permitindo que um campo seja envolvido em aspas duplas, dentro das quais vírgulas, e até quebras de linha, são simplesmente dados literais, não estrutura — um campo corretamente entre aspas como `"Silva, Souza & Cia."` é entendido como um único valor que contém uma vírgula, não dois valores separados por essa vírgula. Um analisador que divide ingenuamente por cada vírgula sem rastrear se está atualmente dentro de um campo entre aspas não tem como fazer essa distinção, e divide silenciosamente esse único nome de empresa em duas colunas espúrias — geralmente sem lançar erro nenhum, o que é precisamente o que torna essa classe de bug perigosa: a conversão parece bem-sucedida, e a corrupção só é descoberta depois, muitas vezes bem depois de os dados malformados já terem sido usados para alguma coisa.
Quebras de linha embutidas dentro de uma única célula
Uma célula de planilha contendo uma nota ou um endereço de várias linhas é completamente normal, e quando essa célula é exportada para CSV, a especificação lida com ela do mesmo jeito que lida com uma vírgula embutida: o campo inteiro é envolvido em aspas, e a quebra de linha dentro dele é genuinamente parte dos dados do campo, não um sinal de que uma nova linha da tabela começou. Um analisador que assume que toda quebra de linha no arquivo marca o início de um novo registro, sem rastrear se está atualmente dentro de um campo entre aspas ainda aberto, divide essa única célula de várias linhas no que parecem ser várias linhas separadas — corrompendo silenciosamente a estrutura de linhas de tudo o que vem depois no arquivo, já que cada linha subsequente fica deslocada pela quantidade de linhas espúrias extras que a célula quebrada introduziu.
Ambiguidade de tipo: zeros à esquerda, números de telefone, e números que não são realmente números
Todo valor individual em um arquivo CSV bruto é armazenado como texto simples, sem nenhuma forma embutida de indicar se um determinado valor é "de fato" um número, um booleano, ou apenas uma string que parece numérica — o que se torna um problema real assim que um conversor tenta ser útil inferindo tipos automaticamente. Um CEP como "007" ou um identificador como "042" tem um zero à esquerda que é semanticamente significativo — é um identificador de largura fixa, e "7" e "007" são identificadores diferentes mesmo representando o mesmo número — mas um conversor que analisa avidamente strings de aparência numérica como números de verdade descarta silenciosamente esse zero à esquerda, já que o número 7 não tem nenhum conceito de quantos zeros o precediam antes. Um número de telefone como "+55 11 99999-0000" parece parcialmente numérico, mas não é dado aritmético algum, e convertê-lo em número produz algo genuinamente sem sentido. A opção segura e correta por padrão é deixar valores ambíguos como texto, a menos que um valor seja inequívoca e seguramente numérico, já que errar o palpite aqui corrompe os dados silenciosamente em vez de lançar um erro visível e detectável.
Por que o Excel especificamente adiciona uma segunda camada de problemas, sem relação com o CSV em si
Além dos casos extremos genuínos do próprio formato CSV, o Microsoft Excel introduz atrito adicional que não tem nada a ver com a especificação do CSV em si: muitas configurações regionais europeias e de outras regiões do Excel usam por padrão o ponto e vírgula em vez da vírgula como delimitador de campo, já que a vírgula já é usada como separador decimal nessas localidades — o que significa que um arquivo CSV exportado de uma dessas configurações do Excel não vai ser analisado corretamente por um analisador delimitado por vírgulas. O Excel também tem o hábito conhecido de reformatar automaticamente valores que acha que reconhece quando um arquivo CSV é aberto para visualização — transformando um identificador numérico longo em notação científica, por exemplo — o que é uma interpretação errada por parte do Excel no momento da exibição, não uma falha do arquivo CSV em si, mas que rotineiramente é confundida com corrupção real de dados na própria exportação.