Por que devo usar um formato de arquivo legível?

https://stackoverflow.com/questions/568671

05-09-2019
|

Pergunta

Por que eu deveria usar um formato de arquivo legível, de preferência a um binário? Há sempre uma situação em que não é esse o caso?

EDIT: Eu tinha isso como uma explicação quando inicialmente a postar a pergunta, mas não é tão relevante agora:

Ao responder esta questão eu queria remeter o consulente para uma resposta SO padrão em por que usar um arquivo legível formato é uma boa idéia. Então eu procurei por um e não poderia encontrar um. Então aqui vai a pergunta

Foi útil?

Solução

Depende

A resposta certa é que depende. Se você estiver escrevendo dados de áudio / vídeo, por exemplo, se você pé de cabra-lo em um formato legível, não vai ser muito legível! E documentos de texto são o exemplo clássico onde as pessoas têm desejou que eles eram humanos legível, de modo mais flexível, e movendo-se para MS XML estão indo dessa forma.

Muito mais importante do binário ou de texto é um padrão ou não um padrão. Se você usar um formato padrão, então as chances são você e o cara ao lado não terá que escrever um analisador, e isso é uma vitória para todos.

Na sequência deste são algumas das razões opinativo por isso que você pode querer escolher um sobre o outro, se você tem que escrever o seu próprio formato (e analisador).

Por legível uso humano?

O próximo cara . Considere o desenvolvedor manter a olhar para o seu código de 30 anos ou daqui a seis meses. Sim, ele deve ter o código fonte. Sim, ele deve ter os documentos e os comentários. Mas ele muito provavelmente não vai. E, tendo sido esse cara, e teve que resgate ou converta velho, extremamente, dados valiosos, eu vou agradecer por para torná-lo algo que pode apenas olhar e entender.

Deixe-me ler e escrever com minhas próprias ferramentas . Se eu sou um usuário do emacs eu posso usar isso. Ou Vim, ou bloco de notas ou ... Mesmo que você tenha criado grandes ferramentas ou bibliotecas, não pode ser executado em minha plataforma, ou até mesmo correr em tudo mais. Além disso, eu posso, então, criar novos dados com as minhas ferramentas.

O imposto não é tão grande - armazenamento livre . Quase sempre espaço em disco é gratuito. E se não é você saberá. Não se preocupe com alguns colchetes ou vírgulas, geralmente ele não vai fazer muita diferença. otimização prematura é a raiz de todo o mal. E se você está realmente preocupado apenas usar uma ferramenta de compressão padrão, e então você tem um formato legível pequeno - qualquer um pode correr unzip
.
O imposto não é tão grande - os computadores são rápidos . Pode ser uma mais rápida para binário de análise. Até que você precisa adicionar uma coluna extra, ou tipo de dados, ou apoiar tanto legado e novos arquivos. (Embora este é mitigado com Protocol Buffers )

Há um monte de bons formatos lá fora, . Mesmo se você não gosta XML. Tente CSV. Ou JSON. Ou .properties. Ou mesmo XML. Existem muitas ferramentas para analisar estes já em lotes de línguas. E leva apenas 5 minutos para escrevê-los novamente se misteriosamente todo o código fonte se perde.

Diffs-se fácil . Quando você check-in para controle de versão é muito mais fácil de ver o que mudou. E vê-lo na web. Ou o seu iPhone. Binário, você sabe que algo mudou, mas você confiar nos comentários de dizer o que.

Mescla-se fácil . Você ainda receber perguntas sobre o web perguntando como anexar um PDF para outro. Isso não acontece com o texto.

mais fácil de reparar se corrompido . Tentar reparar um documento de texto corrupto vs. um arquivo zip corrupto. Disse o suficiente.

Toda língua (e plataforma) pode ler ou escrevê-lo . Claro, binário é a língua nativa para computadores, de modo que todas as línguas apoiará binário também. Mas um monte de clássicos pequenas linguagens de script ferramenta funciona muito melhor com dados de texto. Eu não posso pensar de uma linguagem que funciona bem com o binário e não com texto (assembler talvez), mas não o contrário. E isso significa que os programas podem interagir com outros programas que você não tenha sequer pensado, ou que foram escritas 30 anos antes de seu. Há razões Unix foi bem sucedido.

Por que não, e uso binário em vez?

Você pode ter um monte de dados - terabytes talvez. E então um fator de 2 poderia realmente importa. Mas otimização prematura ainda é a raiz de todo mal. Que tal usar um humano agora, e converter mais tarde? Não vai demorar muito tempo.

Armazenamento pode ser livre, mas a largura de banda não é (Jon Skeet nos comentários). Se você está jogando arquivos pela rede, em seguida, o tamanho pode realmente fazer a diferença. largura de banda, mesmo para e do disco pode ser um fator limitante.

Realmente o desempenho do código intensivo . Binário pode ser seriamente otimizado. Há uma razão bases de dados normalmente não têm o seu próprio formato de texto simples.

Um formato binário pode ser o padrão . Portanto, use PNG, MP3 ou MPEG. Isso torna o trabalho seguinte caras mais fácil (pelo menos nos próximos 10 anos).

Há muitas boas formatos binários lá fora, . Alguns são padrões globais para esse tipo de dados. Ou pode ser um padrão para dispositivos de hardware. Alguns são estruturas de serialização padrão. Um grande exemplo é Google Protocol Buffers . Outro exemplo: Bencode

Mais fácil de incorporar binário . Alguns dados já é binário e você precisa incorporá-lo. Isso funciona naturalmente em formatos de arquivos binários, mas olha feio e é muito ineficiente em uns legíveis, e geralmente os impede de ser legível.

obscuridade deliberada . Às vezes você não quer que ele óbvio que seus dados estão fazendo. A criptografia é melhor do que a segurança acidental através da obscuridade, mas se você estiver criptografando assim como você pode torná-lo binário e ser feito com ele.

Debatable

mais fácil de analisar . As pessoas têm reclamado que tanto texto e binário são mais fáceis de analisar. Agora claramente o mais fácil de parse é quando seu idioma ou biblioteca suporta a análise, e isto é verdade para alguns binário e alguns formatos mais legíveis, de modo que realmente não apoiar qualquer um. formatos binários podem claramente ser escolhido de modo que eles são fáceis de analisar, mas isso pode legível (pense CSV ou largura fixa) então eu acho que este ponto é discutível. Alguns formatos binários podem apenas ser despejado na memória e usada como é, então isso poderia ser dito ser o mais fácil de analisar, especialmente se os números (e não apenas cordas estão envolvidos. No entanto eu acho que a maioria das pessoas diria análise legível é mais fácil de depurar , pois é mais fácil ver o que está acontecendo no depurador (ligeiramente).

mais fácil de controlar . Sim, é mais provável que alguém vai mangle dados de texto em seu editor, ou vai gemer quando um formato Unicode funciona e outra não. Com os dados binários que é menos provável. No entanto, as pessoas e hardware pode ainda dados binários mangle. E você pode (e deve) especificar uma codificação de texto para os dados legíveis, seja flexível ou fixo.

No final do dia, eu não acho que seja realmente pode reivindicar uma vantagem aqui.

Qualquer outra coisa

Você tem certeza que quer realmente um arquivo? Você já pensou em um banco de dados? : -)

Créditos

Um monte de esta resposta é se unindo stuff outras pessoas escreveram em outras respostas (você pode vê-los lá). E, especialmente, grande graças a Jon Skeet por seus comentários (tanto aqui e offline) para sugerir maneiras que poderia ser melhorado.

Outras dicas

Depende inteiramente a situação.

Benefícios de um formato legível:

Você pode lê-lo em seu formato "nativo"

Você pode escrever-se, por exemplo, para testes de unidade - ou mesmo para conteúdo real, dependendo do que é para

prováveis ??benefícios de um formato binário:

mais fácil de analisar (em termos de código)

Faster para analisar

Mais eficiente em termos de espaço

mais fácil de controlar (qualquer momento que você precisa o texto lá, você pode garantir que é UTF-8 codificado, eo comprimento prefixado etc)

Mais fácil de incluir dados binários opacos eficiência (imagens, etc - com um formato de texto que você estaria recebendo em base64)

Não se esqueça que você sempre pode implementar um binário ferramentas de formato, mas produzem para converter para / de um formato legível também. Isso é o que o quadro Protocol Buffers faz -. É realmente muito raro IME a necessidade de analisar uma versão de texto de um buffer de protocolo, mas é realmente útil para ser capaz de escrevê-lo como texto

EDIT: Apenas no caso de isso acaba sendo uma resposta aceita, você também deve ter em mente a afirmação feita pelo starblue: formas legíveis humanos são muito melhor para diffing. Eu suspeito que seria viável para projetar um formato binário que é apropriado para diffing (e onde um diff legível poderia ser gerado), mas out-of-the-box suporte de ferramentas diff existentes será melhor para o texto.

O controle de versão é mais fácil com formatos de texto, porque as mudanças podem ser facilmente visualizados e se fundiram.

Especialmente MS-Word está a dar-nos tristeza a este respeito.

formato Open - há pouco malabarismo binário

Legibilidade:)

Interchange entre plataformas

ajuda de depuração

facilmente analisado (e facilmente convertido para qualquer format)

Um ponto importante: você escrever um analisador uma vez, mas ler a saída muitas vezes. Esse tipo de inclina a balança a favor da HRF.

Uma das principais razões é que, se alguém precisa de ler dizem que os dados, 30 anos a partir de agora, o formato legível pode ser descoberto. Binário é muito mais difícil.

Se o seu tem grandes conjuntos de dados que são binário por natureza (por exemplo, imagens), que obviamente não pode ser armazenado em qualquer outro que forma binária. Mas, mesmo assim, os metadados podem (e devem!) Ser legível.

Há algo chamado The Art of Unix programação .

Eu não vou dizer que é bom ou ruim, mas é bastante famoso. Tem um capítulo inteiro chamado Textuality em que o autor afirma esse formato de arquivo legível são uma parte importante do caminho Unix de programação.

Eles abrem a possibilidade de ser criado / editado com outros do que os originais ferramentas. Novas e melhores ferramentas podem ser desenvolvidas por outros, a integração em aplicações de terceiros se torna possível. Pense sobre arquivos iCal binários, por exemplo? - seria o formato ter sido um sucesso

Além de que: arquivos legíveis Humanos melhorar a capacidade de depuração ou, para o usuário mais experiente, pelo menos, encontrar a razão um erro
.

Pros para binário:

rápido para analisar

dados geralmente menores

fácil de escrever um analisador para

Pros para legível:

fácil de entender ao ler - não "campo X está definido para 4 487 o que significa que o reator deve ser desligado AGORA"

se usando algo como XML fácil de escrever uma ferramenta que irá analisar qualquer arquivo

Eu tive que lidar com ambos os tipos. Se você estiver enviando dados e você quer mantê-lo pequeno binário é bom. Se você espera que as pessoas a lê-lo, em seguida, legível é bom.

Human readable geralmente um pouco auto documentando também. E com binário é bery fácil cometer erros -. E difícil de identificá-los

editável

legível (duh!)

para impressão

Bloco de notas e vi habilitado

O mais importante, a sua função pode ser decuded a partir do conteúdo (bem principalmente)

Porque você é um ser humano, e mais cedo ou mais tarde você (ou um de seus clientes) será capaz de ler os dados.

Nós usamos somente o formato binário se a velocidade é um problema. E mesmo assim a depuração é problemático para que adicionou um equivalente legível.

A interoperabilidade é o argumento padrão, ou seja, uma forma legível é mais fácil para desenvolvedores de sistemas diferentes para lidar com assim, portanto, confere alguma vantagem.

Pessoalmente, penso que não é verdade, e os benfits de arquivos binários de desempenho deve vencer esse argumento, especialmente se você publicar o seu protocolo. No entanto, a onipresença do XML / HTTP estruturas base para meios interações máquina que é mais fácil de adotar.

XML é o caminho mais utilizado.

Apenas uma ilustração rápida onde formato de documento legível pode ser uma escolha melhor:

documentos utilizados para a implantação do aplicativo na produção

Estamos habituados a ter o nosso notas de lançamento em formato de texto, mas esse documento notas de lançamento teve de ser aberto em vário ambiente (Linux, Solaris) em pré-produção e plateform produção.
Ele também teve de ser analisado a fim de extrair vários dados.

No final, nós mudamos para uma sintaxe baseada em wiki, ainda exibido muito bem em HTML através de um wiki, mas ainda usado como um arquivo de texto simples, em outra situação.

Como um adjuct para isso, existem diferentes níveis de legibilidade humana, e todos são reforçadas por meio de um editor bom ou espectador com coloração de código, dobrar ou navegação.

Por exemplo,

JSON é bastante legível mesmo em texto simples

XML tem a imposto cantoneira mas é utilizável quando usando um editor de boa

INI é principalmente legível

CSV pode ser legível, mas é melhor quando carregado em uma planilha.

Ninguém disse, por isso vou: humano-a legibilidade não é realmente uma propriedade de um formato de arquivo (todos os arquivos são binários depois de tudo), mas sim de uma combinação de formato de arquivo e aplicativo visualizador.

Os chamados formatos mais legíveis são todos baseados no topo da camada de abstração adicional de uma das codificações de texto existentes. E programas de espectador (muitas vezes também servindo como um editor) que são capazes de tornar estas codificações de uma forma legível por seres humanos são muito comuns.

padrões de codificação de texto são comuns e bastante maduros, que meios é improvável que evoluir muito no futuro previsível.

Normalmente, em cima da camada de codificação de texto do formato encontramos uma camada de sintaxe que é razoavelmente intuitiva dado o conhecimento do usuário-alvo e de fundo cultural.

Assim, os benefícios de formatos "legíveis":

Ubiquity de espectadores e editores adequados.

Timelessness (dado que as convenções culturais não vai mudar muito).

Facilidade de aprender, ler e modificar.

Reliance sobre a camada de abstração extra faz com que arquivos de texto codificado:

Space fome.

Mais lento para processar.

arquivos "binário" não recorrer a camada de abstração de codificação de texto como uma base (ou um denominador comum), mas pode ou não usar algum tipo de uma abstração adicional mais adequado para o seu propósito e, portanto, eles podem ser muito melhor otimizado para uma tarefa específica no sentido mão:

Processamento mais rápido.

pegada menor.

Por outro lado:

Os espectadores e editores são específicos para um determinado formato binário e fazer interoperabilidade mais difícil.

Os espectadores para qualquer formato são menos ampla disseminação, porque eles são mais especializada.

Formatos pode evoluir significativamente ou ir fora de uso ao longo do tempo: o seu principal benefício em ser muito bem adaptado para uma determinada tarefa e, como as exigências da tarefa ou tarefa evoluir, o mesmo acontece com o formato

Tome um momento e pensar sobre aplicação diferente do desenvolvimento web.

A suposição de que: A) Tem um significado que é "óbvio" em formato de texto é falsa. Coisas como sistemas de controle de uma usina siderúrgica, ou unidade de fabrico normalmente não têm qualquer vantagem em ser legível. O software para esses tipos de ambientes normalmente têm rotinas para exibir dados de forma gráfica significativa.

B) Produzir-lo no texto é mais fácil. conversões desnecessárias que realmente necessitam de mais código fazer um sistema menos robusto. O fato da matéria se você não estiver usando uma linguagem que trata todas as variáveis ??como strings em seguida, texto legível humano é uma conversão extra. OU SEJA meios de código extra mais código para ser verificado, testado e mais oportunidades de erros de introdução no aplicativo.

C) Você tem que analisá-lo de qualquer maneira. Ele muitos casos para os sistemas de DSP em que já trabalhei (ou seja, interface de legível nenhum ser humano para começar.) Os dados são transmitidos para fora do sistema em pacotes de tamanho uniforme. Registrando os dados para análise e posterior processamento é simplesmente uma questão de apontar para o início de um tampão e escrever um múltiplo do tamanho do bloco para o sistema de aquisição de dados. Isso me permite a análise de dados "intocado", como o sistema do cliente iria vê-lo onde, mais uma vez, convertendo-a em um formato diferente resultaria na possibilidade de introduzir erros. Não só isso, se você só salvar os "dados convertidos" poderá perder informações na tradução que podem ajudar a diagnosticar um problema.

D) Texto é um formato natural para os dados. Nenhum hardware que eu já vi usa uma interface "TEXT". (Meu primeiro trabalho fora da faculdade estava escrevendo um driver de dispositivo para uma câmera de varredura de linha câmera.) A construção do sistema em cima dela faz força, mas para cada "PC".

Para páginas web onde a informação tem um "natural", que significa em formato de texto, tão certo bater-se. Para o processamento de código-fonte é um acéfalo, é claro. Mas os ambientes de computação pervasiva, onde mesmo você geladeira e escova de dentes são vai ter um processador embutido, não tanto. Simplesmente sobrecarregar este tipo de sistemas com a sobrecarga de adicionar a capacidade de introduz texto processo de complexidade unnessary. Você não vai link "printf" no software para um micro de 8 bits que controla um mouse. (E sim, alguém tem de escrever que o software também.)

O mundo não é um lugar preto e branco, onde as únicas formas de computação que precisam ser considerados são PCs e servidores Web.

Mesmo em um PC, se eu posso carregar diretamente os dados diretamente em uma estrutura de dados usando uma única chamada de leitura OS e ser feito com ele sem escrever serialize e desserializar rotinas, isso é fantástico, verifique a blocos trabalho CRC - feito para o próximo problema.

Uhm ... porque formatos de arquivos legíveis pode ser lido por seres humanos? Parece ser uma boa razão bastante para mim.

(Bem, para arquivos de configuração que é inevitável que eles são lidos (e editado!) Por seres humanos. Arquivos para armazenamento persistente de algum tipo ou outro realmente não precisa ser lido ou editado por seres humanos.)

Por que eu deveria usar um arquivo legível formatar em detrimento de um binário? Há sempre uma situação quando esta não é o caso?

Sim, volumes compactados (zip, jpeg, mp3, etc) seria suboptimal se fossem legível.

Eu acho que não é bom na maioria das situações, provavelmente. Acho que a principal razão para esses formatos como JSON e XML é por causa do desenvolvimento web, e uso geral na web onde você precisa ser capaz de processar dados no lado do usuário do e você não pode necessariamente ler binário. Um bom exemplo de um caso ruim para usar um formato legível seria qualquer coisa não textuais, como imagens, vídeo, áudio. Ive notado o uso de formatos não-binários sendo usado no desenvolvimento web onde não faz sentido, eu me sinto culpado!

parte Muitas vezes, arquivos tornam-se da sua interface humana, portanto, eles devem ser humano amigável (não programador apenas)

A única vez que eu uso um fluxo binário para arquivos que não são arquivos é quando eu quero as coisas esconder o observador casual. Por exemplo, se eu estou fazendo arquivos temporários que única minha aplicação deve estar editando, eu vou usar binário.

A sua não é uma tentativa de ofuscar, em vez apenas a sua desencorajar o usuário edite o arquivo com a mão (o que poderia quebrar o aplicativo).

Um exemplo em que isso seria uma boa idéia é armazenar / salvar dados correndo sobre algum jogo .. ou seja, para salvar o seu jogo e continuar mais tarde. Outros cenários descreveria arquivos intermediários, mas esses são / byte normalmente binário compilado de qualquer maneira.

Por que eu deveria usar um arquivo legível formato em detrimento de um binário?

Depende do conteúdo e contexto, ou seja, onde está os dados vindo e indo. Se os dados são normalmente escritos diretamente por um ser humano, armazenando-o em um formato que pode ser manipulada através de um editor de texto é uma boa idéia. Por exemplo, o código fonte do programa será normalmente armazenado como legível com razão. No entanto, se estamos arquivando-lo ou compartilhá-lo usando um sistema de controle de versão, a nossa estratégia de armazenamento vai mudar.

O formato humano é simplier para análise e depuração se você tiver um problema com um campo (exemplo: um campo contém um número onde a especificação diz a esse campo deve ser uma cadeia), também o formato humano é Closier ao domínio de problema.

Eu prefiro o formato binário com uma grande quantidade de dados e tenho certeza que eu tenho o software para analisar ele:)

Ao ler a dissertação de Fielding sobre REST, eu realmente gostei do conceito de " Propriedades de arquitectura "; um que sticked era "Visibilidade". Isso é o que nós estamos falando aqui: ser capaz de 'ver' os dados. benefícios enormes quando a depuração do sistema.

Um aspecto que eu acho que falta em outras respostas: enforcing semântica .

A partir do momento que você vá para legível, você permite que o usuário notepad bobagem criar dados a serem alimentados no sistema. Não há forma de garantir esses dados faz sentido. Não há forma de garantir o sistema irá responder de uma forma sensata.

Assim, no caso de você não precisa notepad-inspecionar seus dados, e você deseja impor dados válidos (por exemplo, o uso de uma API), em vez de primeiros validá-lo, é melhor evitar dados legíveis humanos. Se debuggeability é um problema (que na maioria das vezes é), inspeção dos dados pode ser feito usando a API, também.

Não pode ser lido
humano é igual a mais fácil de ser analisado pelo código de máquina.

Tome linguagem natural humana como um exemplo. :) análise Máquina da linguagem humana ainda é um problema pendente para ser totalmente resolvido.

Então, eu concordo com https://stackoverflow.com/a/714111/2727173 que tem uma visão muito mais profunda sobre esta questão.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow