Tamanho do arquivo binário vs. ASCII

Se sua única preocupação for o tamanho do arquivo, você deseja arquivos binários. Para um exemplo ilustrativo, vamos supor que você esteja gravando 1 número de ponto flutuante de precisão dupla em um arquivo. Vamos supor que o sistema de arquivos pode lidar com isso perfeitamente e mantendo o arquivo, cabeçalhos e preenchimento são todos 0.

Para um arquivo binário, esse número tomaria o tamanho exato do número na RAM, ou 8 bytes.

No formato ASCII, ele conteria:

• 16 dígitos da base
• 1 ponto decimal
• 1 caractere para delimitar o expoente
• 1 caractere para o sinal do expoente
• 2-3 caracteres para o expoente

Supondo ele usa apenas 1 byte para um caractere, ou seja, 22 bytes para conter o mesmo número. Isso não conta os caracteres necessários para dilimitar entre os números (geralmente pelo menos 1). Portanto, o tamanho do arquivo para o formato ASCII será cerca de 3 vezes maior.

Você pode trocar o tamanho do arquivo pela precisão nos arquivos armazenados (mantenha apenas 5-6 dígitos na base), mas isso depende do que você os está usando para. A principal vantagem do ASCII é para depurar ou produzir dados legíveis por humanos.

Comentários

• Também importante na área científica é o arquivamento de longo prazo e confiável compartilhamento, por isso, apesar de ‘ s ineficiências, o ASCII CSV é tão prevalente e recomendado (PDF) .
• Outro ponto útil é que, embora a codificação ASCII CSV não seja ‘ t muito eficiente, usando um utilitário de compactação de arquivo (como zip, gzip, etc.) em seu ascii arquivo normalmente reduzirá o tamanho do arquivo para algo semelhante ao tamanho de um arquivo binário.
• Tenha cuidado porque algumas bibliotecas de entrada / saída não são ‘ suficientemente cuidadosas para obter bit para reprodutibilidade de bit conforme você produz números IEEE Double Precision em ASCII e depois os lê de volta. Em minha experiência, usar 17 ou 18 dígitos decimais às vezes é necessário para segurança.
• Em relação ao horchler ‘ s comentário: I ‘ tenho certeza de que formatos binários abertos padronizados e bem usados, como HDF5, permanecerão por muito tempo. Isso ‘ é o que eu ‘ d recomendo pessoalmente.
• + Eu fico com o binário sempre que possível, para precisão, compacidade, paz de espírito e (especialmente) velocidade. Então, se eu precisar de mais compactação, posso fechar o zíper. Se eu precisar ler visualmente o conteúdo, posso escrever um pequeno programa para isso. Por outro lado, se ‘ é mais importante ser visual e facilmente transmitido para programas aleatórios como Excel, R etc., CSV é o caminho a seguir.

Na prática, você raramente precisa de dados em arquivos de visualização que são mais precisos do que, digamos, 3 válidos dígitos. Nesse caso, ASCII é – talvez surpreendentemente – muitas vezes mais compacto do que a forma binária. Se você está pensando em arquivar, então compactar esses arquivos ASCII provavelmente produzirá os menores arquivos que você puder obter.

Dito isso, o Paraview lê o formato VTU que tem um formato binário compactado (baseado em XML, mas os dados são primeiro compactados por libz e depois uuencodificados novamente para produzir texto ASCII). Em arquivos típicos, isso economiza um fator de 4-10. Para arquivos grandes, este é definitivamente o caminho a seguir.

Comentários

• Votei aqui em contraste com a outra resposta. Eu não ‘ não tenho uma opinião forte de qualquer maneira, mas há ‘ um bom ponto a ser tido aqui.
• Como alternativa, zere explicitamente os bits baixos e compacte o binário.
• Uau, isso exigiria alguns ajustes nos bits. Ou existem funções que fazem isso? (Além de lançar para flutuar e voltar para dobrar.)

tl; dr – armazenar arquivos em utf8 . Se for tabular, use valores separados por TAB.

Parece-me que as opções corretas são:

1. utf8 texto ( não ASCII . Não somos todos falantes de inglês americano)
2. binário

ASAICT a única vantagem real dos arquivos binários é o desempenho. É muito mais rápido carregar um despejo de memória na memória do que gerar texto na saída ou analisá-lo na entrada.

por exemplo. https://www.cfd-online.com/Forums/openfoam/136983-binary-gives-significant-performance-advantage-mesh-solve.html

Ou aqui: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Isso não é científico e está discutindo o desempenho geral, com as grandes diferenças sendo a quantidade de dados transmitidos e o tempo de análise em um caso tendencioso para dados textuais. )

As chances de um formato de arquivo binário oferecer suporte adequado a texto unicode são pequenas, então se você se preocupa com a integridade dos dados, não use . Você também ouviu falar sobre questões de endian? Diferentes representações binárias de números inteiros e flutuantes com sinal?

As representações de texto de -100000 e -1e + 6 não mudam de valor dependendo em sua CPU (em utf-8 e ASCII, pelo menos).

As chances de que um programa que entende um arquivo binário ainda o compreenda ou ainda rode 50 anos a partir de agora é desconhecida, provavelmente não é boa . Se você se preocupa com a longevidade, não use o binário .

Muitas vezes é difícil ler dados binários de outro programa, então se você se preocupa com a interoperabilidade, não use binários .

À parte: CSV é um formato de arquivo terrível . É simples, mas mal definido e requer um analisador com estado. Não use CSV. Se for necessário, use TSV. É mais simples, mas melhor definido e trivial de analisar.

https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/

https://www.cloudbakers.com/blog/everything-you-didnt-want-to-have-to-know-about-csv

Se você está preocupado com o tamanho, comprima .

(Vim aqui procurando estudos sobre a eficiência relativa do tamanho da representação binária compactada vs. texto. Ainda não encontrei boas informações além deste estudo sobre VRML, mas não tenho certeza se é uma comparação entre binário codificado em base64 e binário. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)