Os arquivos UTF-8 CSV devem conter uma BOM (marca de ordem de bytes)?

Nosso software de linha de negócios permite ao usuário salvar determinados dados como CSV . Como existem muitos formatos diferentes (todos chamados de "CSV") em uso, procuramos decidir como deve ser o "formato padrão".

Em relação aos separadores de linha / campo e escape, existe um padrão que podemos usar: RFC 4180 .
No que diz respeito à codificação de texto, o UTF-8 parece ter surgido na última década como o "formato padrão de arquivo de texto"; portanto, usaremos isso.

A única pergunta deixada em aberto é: devemos adicionar uma lista técnica no início ou não? Li várias opiniões e prós / contras sobre o uso de BOMs em geral, mas há uma recomendação "oficial" ou pelo menos algum tipo de consenso da comunidade sobre o uso de BOMs em arquivos CSV?

— Heinzi
fonte

Se tiver uma lista técnica, não será UTF-8. Mas qual formato os programas desejam. Se eles precisam de uma lista técnica (principalmente micro-preguiça), é necessário adicionar uma, mas UTF-8 + BOM ≠ UTF-8.

— CTRL-ALT-DELOR

Embora o CSV seja aparentemente mais fácil de gerar, há tantos problemas de compatibilidade, especialmente se você se desviar do ASCII de 7 bits puro, que eu recomendaria muito, muito, fortemente que você gere XLSX real se o objetivo for que os usuários o abram. no Excel (em vez de reimportá-lo em outro software, nesse caso, você terá que fornecer opções para separadores, codificação etc.). Existem bibliotecas para a maioria dos idiomas por aí, e você economizará muito tempo para você e seus usuários.

— jcaron

Se você seguir a rota CSV, verifique o que acontece quando você abre o arquivo no Mac e no PC, idealmente com várias versões do Excel. Lembre-se também de que algumas versões do Excel não se comportam da mesma maneira quando você clica duas vezes no arquivo para abri-lo ou abrir o arquivo através do menu.

— jcaron

Por que importa se ele abre corretamente no Excel? Nada na pergunta indica que o Excel precisa ser capaz de analisar o arquivo gerado ...

— rubenvb

Respostas:

Não é para UTF-8 , mas veja as várias advertências nos comentários.

É desnecessário (o UTF-8 não possui ordem de bytes), diferentemente do UTF-16/32 e não é recomendado no padrão Unicode . Também é bastante raro ver UTF-8 com BOM "em estado selvagem", portanto, a menos que você tenha um motivo válido (por exemplo, como comentado, você estará trabalhando com software que espera a BOM), recomendo a abordagem sem BOM .

A Wikipedia menciona alguns softwares principalmente da Microsoft que força e espera uma BOM, mas, a menos que você esteja trabalhando com eles, não o use.

— Kayaman
fonte

Também há software generalizado que exige uma BOM: o Excel precisa de uma BOM para identificar corretamente um arquivo CSV como UTF-8 em vez de "ANSI", ou seja, o local de compatibilidade local. (Mas Excel também faz coisas estranhas ao salvar um arquivo, por isso aconselha os usuários a usar a nossa exportação "real" Excel em vez da exportação CSV se deseja abrir o arquivo com o Excel.)

— Heinzi

@ Heinzi Aprendi há muito tempo que você realmente não pode vencer ao trabalhar com CSV e Excel. É simplesmente um péssimo leitor de CSV. Pena que é o que os usuários normais esperam.

— pipe

@Voo: a exigência de uma lista técnica para UTF-8 certamente viola o padrão, considerando que ele " não é necessário nem recomendado ".

— Deduplicator

@ Reduplicador: Os sistemas MS-DOS e Windows têm uma grande base de arquivos de texto herdados em codificações diferentes de UTF-8. Aplicativos de qualidade permitem ao usuário especificar como um arquivo de texto é codificado ao abri-lo, mas geralmente inclui uma opção "automática". Se um usuário selecionar "UTF-8", um arquivo UTF-8 será aberto corretamente com ou sem uma BOM. Se um usuário selecionar "automático", alguns arquivos UTF-8 que não possuem uma lista técnica poderão ser identificados incorretamente como usando outra codificação. Eu não sei o que seria de esperar que um aplicativo para fazer diferente, já que os arquivos que estão "identificados incorretamente" poderia ser bit por bit idêntico ...

— supercat

@Voo: Isso entra em conflito com muitos outros requisitos específicos de formato em que uma lista técnica é ilegal. Por exemplo, um script de shell com uma lista técnica anterior #!é inválido. Na melhor das hipóteses, uma lista técnica no UTF-8 é "permitida, quando nenhum requisito específico de formato / aplicativo a impede", não é "permitida" e, como tal, não deve ser usada. Os padrões são realmente claros sobre o que NÃO DEVE.

— R ..

Ainda não existe uma convenção generalizada AFAIK, embora certamente UTF-8 agora seja geralmente aceito.

A BOM é um artefato terrível:

É invisível (espaço com largura zero).

Alguns softwares podem aparecer no nome da primeira coluna, não contendo apenas letras, mas essa lista técnica estranha na frente.

A linha do cabeçalho pode, porventura, ser copiada para linhas de valor que corrompem o primeiro valor.

Alguns softwares Windows precisam apenas distinguir entre uma das codificações ANSI usadas por essa máquina Windows local e o UTF-8. Bloco de notas, Excel.

O triste é que devemos apoiar a lista técnica. Talvez opcional.

Use um esquema de nomenclatura para os arquivos (...- utf8.txt, ...- utf8bom.txt).

Em muitos casos, poderíamos usar o HTML como alternativa de exportação. Isso permite definir a codificação no arquivo. Um recurso extra é a coloração de segundo plano / primeiro plano de linhas e células. O que aumenta a qualidade da exportação.

— Joop Eggen
fonte

Se a formatação "aumenta a qualidade da exportação" depende muito do uso pretendido do arquivo. O CSV é frequentemente usado como um formato legível por máquina simples , e fazer com que o destinatário analise HTML seria uma grande desvantagem nesse caso.

— IMSoP

Se você estiver escolhendo um esquema de nomeação, lembre-se do público. -utf8-windows.csvé melhor. Quase todo mundo sabe o que é o Windows, no contexto de computadores, mas muito menos usuários sabem o que é uma Marca de Pedido de Byte.

— MSalters

@ Davidislor sim se for um padrão conhecido amplamente divulgado. Caso contrário, surgirão relatórios de erro sobre tschÃ¼ÃŸlixo, que tschüßdeveriam ter sido gravados. No StackOverflow, muitos erros de TI são sobre codificações. Os usuários finais também terão problemas.

— Joop Eggen

@JoopEggen "Padrão conhecido amplamente comunicado" em que comunidade exatamente? Estou desenvolvendo software há quase 10 anos e nunca vi isso - nem mesmo no Windows, e certamente não no Linux ou OSX, onde você quase sempre lida com o utf-8.

— Cubic

@ JustinTime sim, já há alguns anos, mas não antes. Os desenvolvedores da MS não são tão ruins (conformidade com Posix, agora suporte a UTF-8).

— Joop Eggen