Pourquoi devrais-je utiliser un format de fichier lisible par l'homme?

cela dépend entièrement de la situation.

avantages d'un format lisible par l'homme:

• vous pouvez le lire dans son format "native
• vous pouvez l'écrire vous-même, par exemple pour des tests unitaires - ou même pour du contenu réel, selon ce que c'est pour

avantages probables d'un format binaire:

• plus facile à déchiffrer (en termes de code)
• plus Rapide à analyser
• Plus efficace en termes d'espace
• plus facile à contrôler (chaque fois que vous avez besoin de texte, vous pouvez vous assurer QU'il est encodé UTF-8, et la longueur préfixée etc)
• plus facile d'inclure efficacement des données binaires opaques (images, etc - avec un format de texte que vous obtiendriez en base64)

N'oubliez pas que vous pouvez toujours mettre en œuvre un format binaire, mais produire des outils pour passer à / de un format lisible par l'homme. C'est ce que fait le protocole Buffers framework - en fait, il est assez rare de devoir analyser une version texte d'un protocole buffer, mais c'est très pratique de pouvoir l'écrire sous forme de texte.

EDIT: Juste au cas où cela finit par être accepté de répondre, vous devez également garder à l'esprit la remarque faite par starblue : lisible par les formes sont beaucoup mieux pour comparaison. Je soupçonne il serait faisable pour concevoir un format binaire qui est approprié pour diffing (et où une diff lisible par l'homme pourrait être générée) mais le soutien out-of-the-box des outils existants de diff sera meilleur pour le texte.

contrôle de Version est plus facile avec les formats de texte, parce que les changements peuvent facilement être consultés et fusionnés.

surtout MS-Word nous attriste à cet égard.

• format Ouvert-pas de binaire de jonglerie
• lisibilité:)
• l'Échange entre les plates-formes
• Débogage aide
• facilement déchiffré (et facilement converti en n'importe quel format)

un point important: vous écrivez un analyseur une fois, mais lisez la sortie de nombreuses fois. Cela fait pencher la balance en faveur de HRF.

une raison majeure est que si quelqu'un a besoin de lire les données dire, dans 30 ans, le format lisible par l'homme peut être compris. Binaire est beaucoup plus difficile.

si vous avez de grands ensembles de données qui sont binaires par nature (par exemple des images), ils ne peuvent évidemment pas être stockés sous une forme autre que binaire. Mais même dans ce cas, les métadonnées pourraient (et devraient!) être lisible par l'homme.

il y a quelque chose qui s'appelle L'Art de la programmation Unix .

Je ne dirais pas que c'est bon ou mauvais, mais c'est assez célèbre. Il a un chapitre entier appelé Textuality dans lequel l'auteur affirme que le format de fichier lisible par l'homme sont une partie importante de la façon Unix de programmation.

ils ouvrent la possibilité d'être créé/édité avec des outils autres que les originaux. Des outils nouveaux et de meilleure qualité peuvent être développés par d'autres, l'intégration dans des applications tierces devient possible. Pensez aux fichiers binaires iCal, par exemple - le format aurait-il été un succès?

en dehors de cela: les fichiers lisibles par L'homme améliorent la possibilité de déboguer ou, pour l'utilisateur averti, au moins trouver la raison d'une erreur.

Pros pour binaire:

• rapide à analyser
• données généralement plus petites
• facile à écrire un analyseur pour

Pros pour lisible par l'homme:

• plus facile à comprendre en lisant-aucun "champ X est réglé à 4 487 ce qui signifie que le réacteur doit être arrêté maintenant"
• si l'utilisation de quelque chose comme XML facile à écrire un outil qui sera analyser n'importe quel fichier

j'ai dû traiter avec les deux types. Si vous envoyez des données et que vous voulez le garder petit binaire est bon. Si vous souhaitez lire, puis lisible par l'homme est bon.

lisible par l'homme généralement un peu auto-documentant aussi bien. Et avec le binaire, il est très facile de faire des erreurs, et difficile de les repérer.

• modifiable
• lisible (duh!)
• imprimable
• Bloc-Notes et vi activé

le plus important , leur fonction peut être décodée à partir du contenu (bien souvent)

Parce que vous êtes un humain, et tôt ou tard, vous (ou l'un de vos clients) sera en mesure de lire les données.

nous n'utilisons le format binaire que si la vitesse est un problème. Et même alors, le débogage est gênant, donc nous avons ajouté un homme lisible équivalent.

L'interopérabilité est l'argument standard, c'est-à-dire qu'une forme lisible par l'homme est plus facile à traiter pour les développeurs de systèmes disparates, ce qui confère donc un certain avantage.

personnellement, je pense que ce n'est pas vrai, et les avantages de performance des fichiers binaires devrait battre cet argument, surtout si vous publiez votre protocole. Toutefois, L'ubiquité des cadres XML/HTTP pour les interactions machine signifie qu'il est plus facile à adopter.

XML est sur-utilisé.

Juste une petite illustration où lisible format de document peut être un meilleur choix:

documents utilisés pour déployer l'application en production

nous avions nos notes de version en format word, mais ce document de notes de version a dû être ouvert sur divers environnements (Linux, Solaris) dans la pré-production et la plateforme de production.

Il a également dû être analysé afin d'extraire des données différentes.

en fin de compte, nous sommes passés à une syntaxe basée sur wiki, toujours bien affichée en HTML via un wiki, mais toujours utilisée comme un simple fichier texte dans d'autres situations.

pour tenir compte de cela, il existe différents niveaux de lisibilité humaine, et tous sont rehaussés par l'utilisation d'un bon éditeur ou d'un bon visualiseur avec un code de couleur, de pliage ou de navigation.

par exemple,

• JSON est très lisible même en clair
• XML a le angle bracket tax mais est utilisable lorsqu'on utilise un bon éditeur
• INI est principalement humain lisible
• CSV peut être lisible, mais est préférable lorsqu'il est chargé dans une feuille de calcul.

personne n'a dit, donc je le ferai: la lisibilité humaine n'est pas vraiment une propriété d'un format de fichier (Tous les fichiers sont binaires après tout), mais plutôt d'un format de fichier et d'une combinaison d'application de visualisation.

les formats dits "lisibles par l'homme" sont tous basés sur la couche supérieure d'abstraction d'un des encodages de texte existants. Et les programmes de visualisation (souvent aussi servant d'éditeur) qui sont capables de rendre ces encodages sous une forme lisible par les humains sont très courants.

les normes d'encodage du texte sont répandues et assez matures, ce qui signifie qu'il est peu probable qu'elles évoluent beaucoup dans un avenir prévisible.

habituellement, au-dessus de la couche de codage du texte du format, nous trouvons une couche de syntaxe qui est raisonnablement intuitive compte tenu de la connaissance de l'utilisateur cible et de l'arrière-plan culturel.

D'où les avantages des formats "lisibles par l'homme":

• à l'Omniprésence de l'convient de téléspectateurs et éditeur.

• intemporalité (étant donné que les conventions culturelles ne changeront pas beaucoup).

• facilité d'apprentissage, de lecture et de modification.

la confiance dans la couche d'abstraction supplémentaire produit des fichiers encodés:

• l'Espace de la faim.

• plus lent à traiter.

les fichiers "binaires" ne recourent pas à la couche d'abstraction de texte comme base (ou comme dénominateur commun), mais ils pourraient ou non utiliser une sorte d'abstraction Supplémentaire plus appropriée à leur usage et donc, ils peuvent être beaucoup mieux optimisés pour une tâche spécifique à portée de main signification:

• traitement plus rapide.

• petite empreinte.

d'autre part:

• les lecteurs et les éditeurs sont spécifiques à un format binaire particulier et rendent l'interopérabilité plus difficile.

• les téléspectateurs de n'importe quel format sont moins répandus, parce qu'ils sont plus spécialisés.

• les Formats peuvent évoluer de manière significative ou devenir obsolètes au fil du temps: leur principal avantage est d'être très bien adapté pour une tâche donnée, et que la tâche ou les exigences des tâches évoluer, le format.

prenez un moment et pensez à une application autre que le développement web.

L'hypothèse que: A) Il a un sens qui est "évident" dans le format de texte est faux. Des choses comme les systèmes de contrôle pour une aciérie ou une usine de fabrication n'ont généralement aucun avantage à être lisibles par l'homme. Le logiciel pour ces types d'environnements aura généralement des routines pour afficher des données d'une manière graphiquement significative.

B) L'Outputting it in le texte est plus facile. Les conversions inutiles qui nécessitent plus de code rendent un système moins robuste. Le fait de la question si vous n'utilisez pas une langue qui traite toutes les variables comme des chaînes alors le texte lisible par l'homme est une conversion supplémentaire. C'est-à-dire que le code supplémentaire signifie plus de code à vérifier, à tester et plus d'occasions d'introduire des erreurs dans l'application.

C) vous devez la Parser de toute façon. Il y a de nombreux cas pour les systèmes DSP sur lesquels j'ai travaillé (C'est-à-dire pas d'interface lisible par L'homme). pour commencer avec.) Les données sont rayées du système en paquets de taille uniforme. La journalisation des données pour l'analyse et le traitement ultérieur est simplement une question de pointer vers le début d'un tampon et d'écrire un multiple de la taille du bloc sur le système d'enregistreur de données. Cela me permet d'analyser les données "intactes" comme le système du client le verrait là où, encore une fois, leur conversion à un format différent entraînerait éventuellement l'introduction d'erreurs. Non seulement cela, si vous n'enregistrez les "convertis données" vous pouvez perdre des informations dans la traduction qui peuvent vous aider à diagnostiquer un problème.

D) le texte est un format naturel pour les données. Aucun matériel que j'ai vu n'utilise une interface "texte". (Mon premier travail en dehors de l'université était d'écrire un pilote de périphérique pour une caméra de balayage de ligne de caméra.) Le système construit sur le dessus de lui fait pourrait, mais pour chaque "PC".

pour les pages web où l'information a un sens" naturel " dans le format de texte, donc assommez-vous. Pour traiter le code source, c'est évident. Mais les environnements informatiques envahissants où même vous réfrigérateur et brosse à dents vont avoir un processeur intégré, pas tellement. Le simple fait de surcharger ces types de systèmes d'ajouter la capacité de traiter du texte introduit une complexité inutile. Vous n'allez pas lier "printf" dans le logiciel pour un micro 8-bit qui contrôle une souris. (Et, oui, quelqu'un doit écrire que les logiciels.)

Le monde n'est pas un endroit noir sur blanc où les seules formes de calcul qui doivent être considérées sont les ordinateurs personnels et les serveurs Web.

même sur un PC, si je peux charger directement les données directement dans une infrastructure de données en utilisant un seul appel de lecture OS et être fait avec elle sans écrire serialize et deserizing routines, c'est fantastique, vérifier un travail CRC blocs -- fait sur le problème suivant.

Uhm ... parce que les formats de fichiers lisibles par l'homme peuvent être lus par les humains? Semble être une très bonne raison de moi.

(Eh bien, pour les fichiers de configuration, il est inévitable qu'ils soient lus (et édités!) par les humains. Les fichiers pour stockage persistant d'une sorte ou de l'autre n'ont pas vraiment besoin d'être lus ou édités par les humains.)

Pourquoi devrais-je utiliser un fichier lisible par l'homme format de préférence à un binaire? Est-il jamais une situation où cette n'est-ce pas le cas?

Oui, les volumes compressés (zip, jpeg, mp3, etc.) seraient sous-optimaux s'ils étaient lisibles par un humain.

je suppose que ce n'est pas bon dans la plupart des situations probablement. Je pense que la principale raison pour ces formats tels que JSON et XML est en raison du développement web, et l'utilisation générale sur le web où vous devez être en mesure de traiter des données du côté de l'utilisateur et vous ne pouvez pas nécessairement lire binaire. Un bon exemple d'un mauvais cas d'utiliser un format lisible par l'être humain serait toute chose non textuelle comme les images, la vidéo, l'audio. J'ai remarqué l'utilisation de formats non binaires utilisés dans le développement web où il ne faire sens, je me sens coupable!

souvent les fichiers font partie de votre interface humaine donc ils devraient être conviviaux pour l'homme (pas seulement programmeur)

la seule fois où j'utilise un flux binaire pour des fichiers qui ne sont pas des archives, c'est quand je veux cacher des choses à l'observateur occasionnel. Par exemple, si je fais des fichiers temporaires que seulement mon application devrait éditer, j'utiliserai du binaire.

ce n'est pas une tentative d'obscurcir, mais plutôt de décourager l'utilisateur d'éditer le fichier à la main (ce qui pourrait casser l'application).

un cas où cela une bonne idée est de stocker / sauvegarder les données en cours d'exécution sur un jeu.. c'est à dire pour enregistrer votre jeu et continuer plus tard. D'autres scénarios décriraient des fichiers intermédiaires, mais ceux-ci sont généralement binaires / byte compilés de toute façon.

Pourquoi devrais-je utiliser un fichier lisible par l'homme format de préférence à un binaire?

dépend du contenu et du contexte, c'est-à-dire de l'origine et de la destination des données. Si les données sont typiquement écrites directement par un humain, les stocker dans un format qui peut être manipulé par un éditeur de texte est une bonne idée. Par exemple, le code source du programme sera normalement stocké sous une forme lisible par l'utilisateur avec une bonne raison. Cependant, si nous sommes d'archivage cela, ou le partager en utilisant un système de contrôle de version, notre stratégie de stockage va changer.

le format humain est plus simple à analyser et déboguer si vous avez un problème avec un champ (exemple: un champ contient un nombre où la spécification dit que ce champ doit être une chaîne de caractères), aussi le format humain est plus closier au domaine de problème.

je préfère le format binaire avec beaucoup de données et je suis sûr que j'ai le logiciel pour l'analyser:)

en lisant la thèse de Fielding sur le repos, j'ai vraiment aimé le concept de propriétés architecturales "; un qui collé était "visibilité". C'est ce dont nous parlons ici: être en mesure de "voir" les données. Avantages énormes lors du débogage du système.

l'Un des aspects que je trouve manquant dans l'autre répond: "151950920 de" faire respecter la sémantique .

à Partir du moment où vous allez pour lisible par l'homme, vous permettez à l'utilisateur notepad stupide de créer des données à être introduites dans le système. Aucune garantie de ces données fait sens. Aucun moyen de garantir que le système répondra de manière raisonnable.

ainsi, dans le cas où vous n'avez pas besoin de notepad-inspecter vos données, et vous voulez appliquer des données valides (par exemple l'utilisation d'une API) plutôt que de valider d'abord, vous feriez mieux d'éviter les données lisibles par l'homme. Si debuggeability est un problème (le plus souvent), de l'inspection des données peut être effectuée en utilisant les API, trop.

lisible par l'homme n'est pas égal à plus facile à déchiffrer par code machine.

prenez le langage naturel humain comme exemple. :) L'analyse automatique du langage humain est encore un problème à résoudre.

donc je suis d'accord avec https://stackoverflow.com/a/714111/2727173 qui a beaucoup plus de perspicacité sur cette question.