为什么我应该使用人类可读的文件格式？
为什么我应该使用人类可读的文件格式而不是二进制文件？ 当情况不是这样的时候，有没有这种情况？
编辑：最初发布这个问题时，我确实有这个解释，但是现在并不那么重要：
当回答这个问题时，我想引用提问者一个标准的答案，为什么使用人类可读的文件格式是一个好主意。 然后我search了一个，找不到一个。 所以这是个问题
这取决于
正确的答案是取决于。 如果你正在写audio/video数据，例如，如果你把它撬成一个人类可读的格式，它将不会很可读！ Word文档是人们希望它们是人类可读的，所以更加灵活的，通过转向XML MS的典型例子就是这样。
比二进制或文本更重要的是标准或不是标准。 如果你使用标准格式，那么你和下一个家伙就不必写一个parsing器，这对每个人都是一个胜利。
以下是一些自己的理由，如果你必须编写自己的格式（和parsing器），你可能会select一个。
为什么使用人类可读？
- 下一个人 考虑维护开发人员从现在起30年或6个月后查看您的代码。 是的，他应该有源代码。 是的，他应该有文件和意见。 但他很可能不会。 如果是那个人，不得不挽救或者转换旧的，极其有价值的数据，那么我会感谢你为我提供了一些我可以看的和理解的东西。
- 让我看看，并用我自己的工具写 。 如果我是emacs用户，我可以使用它。 或Vim，或记事本或…即使你已经创build了很棒的工具或库，它们可能不能在我的平台上运行，甚至不能运行。 另外，我可以用我的工具创build新的数据。
- 税不是那么大 – 存储是免费的 。 几乎总是光盘空间是免费的。 如果不是，你会知道的。 不要担心一些尖括号或逗号，通常不会有太大的区别。 不成熟的优化是万恶之源。 如果你真的担心只是使用标准的压缩工具，然后你有一个小的人类可读的格式 – 任何人都可以运行解压缩。
- 税收不是那么大 – 电脑很快 。 parsing二进制文件可能会更快。 直到您需要添加额外的列或数据types，或者同时支持旧文件和新文件。 （虽然这是协议缓冲器缓解）
- 那里有很多好的格式 。 即使你不喜欢XML。 尝试CSV。 或者JSON。 或.properties。 甚至XML。 现在有许多工具可以用很多种语言来parsing这些工具。 如果神秘地将所有的源代码丢失，只需要5分钟就可以再次写入。
- 差异变得容易 。 当你登入版本控制时，更容易看到改变了什么。 并在网上查看。 或者你的iPhone。 二进制，你知道事情已经改变，但你依靠评论告诉你什么。
- 合并变得容易 。 您仍然在网上询问如何将一个PDF附加到另一个。 Text不会发生这种情况。
- 更容易修复，如果损坏 。 尝试并修复损坏的文本文档与损坏的zip压缩文件。 说够了。
- 每种语言（和平台）都可以读取或写入 。 当然，二进制是计算机的本地语言，所以每种语言也会支持二进制。 但是很多经典的小工具脚本语言在文本数据方面效果更好。 我想不出一种能与二进制文件（而不是文本文件）兼容的语言（可能是汇编语言），而不是相反。 这意味着你的程序可以和其他你甚至没有想过的程序交互，或者是在你之前30年写的程序。 Unix有成功的原因。
为什么不，并使用二进制代替？
- 你可能有很多数据 – 也许是TB。 然后，2的因素可能真的很重要。 但不成熟的优化仍然是万恶之源。 现在如何使用一个人，然后转换？ 这将不会花费太多时间。
- 存储可能是免费的，但带宽不是 （Jon Skeet在评论中）。 如果你在networking上扔文件，那么大小真的可以有所作为。 即使从光盘进出带宽也是一个限制因素。
- 真正的性能密集的代码 。 二进制可以认真优化。 数据库通常没有自己的纯文本格式是有原因的。
- 二进制格式可能是标准 。 所以使用PNG，MP3或MPEG。 这使得下一个家伙的工作更容易（至less在未来10年）。
- 那里有很多好的二进制格式 。 有些是这类数据的全球标准。 或者可能是硬件设备的标准。 有些是标准的序列化框架。 Google Protocol Buffers就是一个很好的例子。 又如： Bencode
- 更容易embedded二进制 。 一些数据已经是二进制的，你需要embedded它。 这在二进制文件格式中很自然，但看起来很丑，在人们可读的文件中效率很低，通常会阻止它们被人类读取。
- 故意默默无闻 有时你不希望看到你的数据在做什么。 通过默默无闻的方式，encryption比偶然的安全要好，但是如果你正在encryption，你可能会把它变成二进制文件，并用它来完成。
值得商榷
- 更容易parsing 。 人们声称，文本和二进制文件更容易parsing。 现在显然最容易parsing的是当你的语言或库支持parsing时，对于一些二进制和一些人类可读的格式来说，这是真的，所以也不支持。 二进制格式显然可以select，所以他们很容易parsing，但人类可读（认为CSV或固定宽度），所以我觉得这一点是没有意义的。 一些二进制格式可以被转储到内存中，因此可以说是最容易parsing的，尤其是数字（不仅仅是string），但是我想大多数人会认为人类可读的parsing更容易debugging，因为它更容易看到debugging器中发生了什么（略）。
- 更容易控制 。 是的，更有可能有人会在他们的编辑器中破坏文本数据，或者当一个Unicode格式工作而另一个不工作时会呻吟。 二进制数据不太可能。 但是，人员和硬件仍然可以篡改二进制数据。 你可以（也应该）为可读的数据指定一个文本编码，无论是灵活的还是固定的。
在这一天结束的时候，我不认为这两者都能在这里获得优势。
还要别的吗
你确定你真的想要一个文件吗？ 你考虑过一个数据库吗？ 🙂
积分
很多这个答案是合并在一起其他人在其他答案写的东西（你可以在那里看到他们）。 特别要感谢Jon Skeet提出的build议（可以在这里和在线）提出改进的方法。
完全取决于情况。
可读格式的好处：
- 你可以阅读它的“原生”格式
- 你可以自己写，例如unit testing – 甚至是真正的内容，这取决于它的用途
二进制格式的可能的好处：
- 更容易parsing（在代码方面）
- 更快parsing
- 空间效率更高
- 更容易控制（任何时候你需要文本，你可以确保它是UTF-8编码，长度前缀等）
- 更容易包含不透明的二进制数据（图像等 – 与文本格式，你会进入base64）
不要忘记，你总是可以实现一个二进制格式，但也可以生成工具来转换成可读的格式。 这就是协议缓冲区框架所做的 – 实际上，它是非常罕见的IME，需要parsing协议缓冲区的文本版本，但是能够将其作为文本写出来真的很方便。
编辑：为了以防万一这是一个被接受的答案，你也应该牢记starblue提出的观点 ：人类可读的forms更好的差异。 我怀疑devise一个适合差异的二进制格式（以及可以生成人类可读的差异的地方）是可行的，但是现有的差异工具的开箱即用支持对于文本来说更好。
文本格式的版本控制更容易，因为更改可以很容易地查看和合并。
特别是MS-Word在这方面给我们带来了悲伤。
- 打开格式 – 没有二进制位杂耍
- 可读性:)
- 跨平台互换
- debugging援助
- 轻松parsing（并可轻松转换为任何格式）
重要的一点是：你只写一次parsing器，但是多次读取输出。 这种倾向于平衡有利于HRF。
一个主要的原因是，如果有人需要阅读数据说，从现在起30年，人们可读的格式可以计算出来。 二进制比较困难。
如果你的大型数据集本质上是二进制的（例如图像），那么它们显然不能以二进制forms存储。 但即使如此，元数据可能（也应该）是人类可读的。
有一种叫做“Unix编程艺术”的东西。
我不会说这是好事还是坏事，但它是相当有名的。 它有一个叫“文本性”的整章 ，作者声称人类可读的文件格式是Unix编程方式的重要组成部分。
他们打开的可能性是用原来的工具以外的工具创build/编辑的。 新的更好的工具可以被其他人开发，集成到第三方应用程序变得可能。 想想二元iCal文件，例如 – 格式是否成功？
除此之外：人类可读的文件提高了debugging的能力，或者对于精明的用户来说，至less可以find错误的原因。
二元优点：
- 快速parsing
- 一般较小的数据
- 容易写一个parsing器
人类可读的优点：
- 阅读时更容易理解 – 无“字段X设置为4 487，这意味着反应堆应该立即closures”
- 如果使用像XML这样的东西容易编写一个工具，将parsing任何文件
我必须处理这两种types。 如果你正在发送数据，你想保持它小二进制是好的。 如果你期望人们阅读它，那么人类可读性好。
人类通常也可以自我logging。 而用二进制的话很容易出错，而且很难发现它们。
- 可编辑
- 可读（duh！）
- 可打印
- 记事本和vi启用
最重要的是，他们的function可以从内容（主要是）
因为你是一个人，迟早你（或你的一个客户）将能够读取数据。
如果速度是一个问题，我们只使用二进制格式。 即使这样，debugging也很麻烦，所以我们添加了一个可读的等价物。
互操作性是标准的论点，即对于不同系统的开发者来说，人可读forms更容易处理，因此具有一些优点。
就我个人而言，我认为这是不正确的，二进制文件的性能优势应该击败这一论点，特别是如果你发布你的协议。 然而，基于XML / HTTP的机器交互框架的无处不在意味着更容易采用。
XML是被过度使用的。
只是一个快速的例子，人类可读的文档格式可以是一个更好的select：
用于在生产中部署应用程序的文档
我们曾经以word格式发布发行说明 ，但发行说明文件必须在各种环境（Linux，Solaris）上以预生产和生产平台的forms打开。
它也必须被parsing以提取各种数据。
最后，我们切换到基于wiki的语法，仍然通过wiki在HTML中很好地显示，但在其他情况下仍然用作简单的文本文件。
作为这一点的佐证，人类的可读性水平是不同的，并且通过使用具有代码着色，折叠或导航的良好的编辑器或查看器来增强所有这些。
例如，
- 即使是纯文本，JSON也是非常可读的
- XML具有尖括号税，但在使用良好的编辑器时可用
- INI主要是人类可读的
- CSV可以被读取，但在加载到电子表格中时是最好的。
没有人说，所以我会：人类的可读性不是文件格式的属性（所有文件都是二进制文件），而是文件格式和查看器应用程序的组合。
所谓的人类可读格式都是基于现有文本编码之一的附加抽象层的顶层。 而能够以人类可读forms呈现这些编码的浏览器程序（通常也用作编辑器）是非常普遍的。
文本编码标准普遍而且相当成熟，这意味着它们在可预见的未来不太可能发展。
通常在格式的文本编码层的顶部，我们find了一个语法层，根据目标用户的知识和文化背景，这个语法层是合理的。
因此，“人类可读”格式的好处：
-
无处不在的合适的观众和编辑。
-
永恒（因为文化习俗不会有太大变化）。
-
轻松学习，阅读和修改。
依赖额外的抽象层使文本编码文件：
-
空间饿了。
-
处理速度较慢。
“二进制”文件不会将文本编码抽象层作为一个基础（或一个公分母），但是他们可能会或可能不会使用某种更适合其目的的额外抽象，因此它们可以更好地进行优化手头的一项具体任务意味着：
-
更快的处理。
-
占地面积较小。
另一方面：
-
观众和编辑者是特定的二进制格式，使互操作性更难。
-
对于任何给定的格式，观众的传播范围较小，因为他们更专业化。
-
格式可能会随着时间的推移而显着演化或失效：它们的主要优点是非常适合特定的任务，随着任务或任务要求的发展，格式也会随之演变。
花一点时间思考应用程序而不是Web开发。
假设：A）文本格式中的“明显”含义是错误的。 像钢铁厂或制造工厂的控制系统通常在人类可读性方面没有任何优势。 针对这些types的环境的软件通常具有以graphics方式显示数据的例程。
B）以文字输出更容易。 实际上需要更多代码的不必要的转换使得系统更加稳定。 事实上，如果您不使用将所有variables作为string处理的语言，那么人类可读文本就是额外的转换。 IE额外的代码意味着更多的代码被validation，testing和更多的机会介绍应用程序中的错误。
C）无论如何你必须parsing它。 对于我曾经工作过的DSP系统，很多情况下（IE NO人类可读界面开始）。数据以统一大小的数据包stream出系统。 logging数据以供分析和稍后处理仅仅是指向缓冲区的开始并将块大小的倍数写入数据logging器系统。 这使我能够在客户的系统看到数据时“分离”数据，再一次将数据转换为不同的格式将导致可能引入错误。 不仅如此，如果只保存“转换的数据”，则可能会在翻译中丢失信息，这可能会帮助您诊断问题。
D）文本是数据的自然格式。 我见过的硬件没有使用“TEXT”界面。 （我的大学第一份工作就是写一个摄像头行扫描摄像头的设备驱动程序。）build立在它上面的系统确实可能，但对于每个“PC”。
对于信息在文本格式中具有“自然”含义的网页，那么确定要把自己击倒。 对于处理源代码来说，这当然是不容易的。 但是普及计算的环境，即使你冰箱和牙刷都将有一个内置的处理器，而不是太多。 简单地使这些types的系统负担增加处理文本的能力会带来不合理的复杂性。 您不会将“printf”链接到控制鼠标的8位微控制器的软件中。 （是的，有人也必须写这个软件。）
世界不是一个黑白的地方，唯一需要考虑的计算forms是PC和Web服务器。
即使在PC上，如果我可以直接使用单个OS读取调用直接将数据加载到数据结构中，并且无需编写序列化和反序列化例程，也可以使用它，那太棒了，请检查块CRC作业 – 完成下一个问题。
呃…因为人类可读的文件格式可以被人读取吗？ 对我来说似乎是一个很好的理由。
（好吧，对于configuration文件来说，不可避免的是它们被人类读取（和编辑！），某种types或者其他types的持久存储文件并不需要被人类读取或者编辑。
为什么我应该使用人类可读的文件格式而不是二进制文件？ 当情况不是这样的时候，有没有这种情况？
是的，压缩卷（zip，jpeg，mp3等）如果是人类可读的，则不是最理想的。
我想大概在大多数情况下它不好。 我认为这些格式的主要原因，如JSON和XML，是因为Web开发，一般使用Web，你需要能够在用户端处理数据，你不能一定要阅读二进制。 使用人类可读格式的一个不好的例子就是任何非文本的东西，比如图像，video，audio。 我注意到在Web开发中使用的非二进制格式，这是没有意义的，我感到内疚！
通常文件成为你的人机界面的一部分，因此他们应该是人类友好（不只是程序员）
我唯一一次使用二进制stream来处理不是档案文件的时候，我想隐藏观察者的东西。 例如，如果我正在创build只有我的应用程序正在编辑的临时文件，我将使用二进制。
它不是试图混淆，而是仅仅阻止用户手动编辑文件（这可能会破坏应用程序）。
一个例子，这将是一个好主意是存储/保存有关某些游戏的运行数据..即保存您的游戏，并在以后继续。 其他场景将描述中间文件，但是这些文件通常是二进制/字节编译的。
为什么我应该使用人类可读的文件格式而不是二进制文件？
取决于内容和上下文，即来自哪里和来自哪里的数据。 如果数据通常是由人类直接编写的，那么将其存储为可以通过文本编辑器操作的格式是一个好主意。 例如，程序源代码通常会被存储为具有很好理由的可读性。 但是，如果我们将其归档或使用版本控制系统共享，我们的存储策略将会改变。
如果你有一个字段的问题（例如：一个字段包含一个数字，这个字段必须是一个string，这个字段必须是string），那么人类格式对于parsing和debugging来说也更简单，人类格式也更接近于问题领域。
我更喜欢有很多数据的二进制格式，我敢肯定，我有parsing他的软件:)
在阅读Fielding关于REST的论文时，我非常喜欢“ build筑属性 ”的概念。 一个坚持是“可见性”。 这就是我们在这里所说的：能够“查看”数据。 debugging系统时有巨大的好处。
我发现在其他答案中缺less一个方面： 强制执行语义 。
从人类可读的那一刻起，您可以让愚蠢的记事本用户创build要input到系统中的数据。 没有办法保证这个数据是有道理的。 没有办法保证系统会以合理的方式做出回应。
所以在这种情况下，你不需要记事本检查你的数据，并且你想强制有效的数据（比如使用API），而不是首先validation它，那么最好避免使用人类可读的数据。 如果可debugging性是最常见的问题，那么也可以使用API来检查数据。
人类可读性不等于更容易被机器码parsing。
以人类的自然语言为例。 :)人类语言的机器parsing仍然是一个待解决的问题。
所以我同意https://stackoverflow.com/a/714111/2727173对这个问题有更深入的了解。;
