为什么我应该使用人类可读的文件格式？答案

【问题标题】：Why should I use a human readable file format?为什么我应该使用人类可读的文件格式？
【发布时间】：2010-10-08 19:03:50
【问题描述】：

为什么我应该使用人类可读的文件格式而不是二进制格式？有没有这种情况不是这样的？

编辑：最初发布问题时，我确实将其作为解释，但现在已不那么相关了：

在回答 this question 时，我想向提问者推荐一个标准的 SO 答案，说明为什么使用人类可读的文件格式是一个好主意。然后我找了一个，没找到。那么问题来了

【问题讨论】：

这真的是个问题吗？您制作了一种人类可读的文件格式，这样......好吧，人类可以阅读（并修复它）！
我认为是。许多开发人员（包括我提到的问题）正在不明智地发明自己的二进制格式。也许它可以更好地表述为“什么时候人类可读的格式比二进制格式更可取”

标签： file encoding formatting binary abstraction

【解决方案1】：

这取决于

正确的答案是视情况而定。例如，如果您正在编写音频/视频数据，如果您将其转换为人类可读的格式，那么它的可读性将不高！ Word 文档是人们希望它们是人类可读的、更灵活的经典示例，并且通过迁移到 XML，MS 正在朝着这个方向发展。

比二进制或文本更重要的是标准或非标准。如果您使用标准格式，那么您和下一个人很可能不必编写解析器，这对每个人来说都是一个胜利。

以下是一些固执己见的原因，如果您必须编写自己的格式（和解析器），您可能希望选择其中一个。

为什么要使用人类可读的？

下一个人。考虑一下维护开发人员在 30 年或 6 个月后查看您的代码。是的，他应该有源代码。是的，他应该有文件和 cmets。但他很可能不会。作为那个人，我不得不拯救或转换非常有价值的旧数据，我会感谢你让它成为我可以看到和理解的东西。
让我用我自己的工具阅读和写作。如果我是 emacs 用户，我可以使用它。或者 Vim，或者记事本，或者……即使你已经创建了很棒的工具或库，它们也可能无法在我的平台上运行，甚至根本无法运行。此外，我还可以使用我的工具创建新数据。
税并不高 - 存储是免费的。几乎总是磁盘空间是空闲的。如果不是，你会知道的。不要担心几个尖括号或逗号，通常不会有太大的不同。过早的优化是万恶之源。如果您真的很担心，只需使用标准压缩工具，然后您就有了一种人类可读的小格式 - 任何人都可以运行 unzip。
税并不高 - 电脑很快。解析二进制文件可能更快。直到您需要添加额外的列或数据类型，或者同时支持旧文件和新文件。（尽管 Protocol Buffers 可以缓解这种情况）
有很多很好的格式。即使您不喜欢 XML。试试 CSV。或 JSON。或 .properties。甚至是 XML。已经有很多工具可以用很多语言来解析这些。如果神秘地所有源代码都丢失了，只需 5 分钟即可重新编写它们。
差异变得容易。当您签入版本控制时，更容易看到发生了什么变化。并在网上查看。或者你的 iPhone。二进制，你知道有些东西发生了变化，但你依靠 cmets 来告诉你什么。
合并变得容易。您仍然会在网络上收到有关如何将一个 PDF 附加到另一个 PDF 的问题。文本不会发生这种情况。
如果损坏更容易修复。尝试修复损坏的文本文档与损坏的 zip 存档。说得够多了。
每种语言（和平台）都可以读取或写入。当然，二进制是计算机的本机语言，因此每种语言也都支持二进制。但是许多经典的小工具脚本语言在处理文本数据时效果要好得多。我想不出一种语言可以很好地处理二进制而不是文本（可能是汇编程序），但反过来不行。这意味着您的程序可以与您甚至没有想到的其他程序进行交互，或者那些比您早 30 年编写的程序。 Unix 成功是有原因的。

为什么不呢，改用二进制？

您可能有很多数据 - 可能是 TB。然后因子 2 可能真的很重要。但过早的优化仍然是万恶之源。现在使用人类如何，然后再转换？不会花太多时间。
存储可能是免费的，但带宽不是（cmets 中的 Jon Skeet）。如果您在网络上扔文件，那么大小确实会有所作为。甚至来自磁盘的带宽也可能是一个限制因素。
真正的性能密集型代码。二进制可以认真优化。数据库通常没有自己的纯文本格式是有原因的。
二进制格式可能是标准格式。因此，请使用 PNG、MP3 或 MPEG。它让下一个人的工作更轻松（至少在未来 10 年内）。
有很多很好的二进制格式。有些是该类型数据的全球标准。或者可能是硬件设备的标准。有些是标准的序列化框架。一个很好的例子是Google Protocol Buffers。另一个例子：Bencode
更容易嵌入二进制文件。有些数据已经是二进制的，您需要嵌入它。这在二进制文件格式中自然有效，但在人类可读的格式中看起来很丑且效率非常低，并且通常会阻止它们成为人类可读的。
故意隐瞒。有时您不希望您的数据在做什么很明显。加密比通过默默无闻的意外安全要好，但如果您正在加密，您不妨将其设为二进制并完成。

值得商榷

更容易解析。人们声称文本和二进制都更容易解析。现在显然最容易解析的是当您的语言或库支持解析时，这对于某些二进制和一些人类可读的格式是正确的，因此也不真正支持。可以清楚地选择二进制格式，以便它们易于解析，但人类可读（想想 CSV 或固定宽度）也是如此，所以我认为这一点没有实际意义。一些二进制格式可以直接转储到内存中并按原样使用，所以这可以说是最容易解析的，特别是如果数字（不仅仅是字符串）。但是我认为大多数人会认为人类可读的解析更容易调试，因为更容易看到调试器中发生的事情（稍微）。
更容易控制。是的，更有可能有人会在他们的编辑器中破坏文本数据，或者当一种 Unicode 格式有效而另一种无效时会抱怨。使用不太可能的二进制数据。然而，人和硬件仍然可以破坏二进制数据。您可以（并且应该）为人类可读的数据指定文本编码，可以是灵活的也可以是固定的。

归根结底，我认为任何一方都无法在这里真正占据优势。

其他的

你确定你真的想要一个文件吗？你考虑过数据库吗？ :-)

学分

这个答案的很多内容都是将其他人在其他答案中写的东西合并在一起（你可以在那里看到它们）。尤其要感谢 Jon Skeet 的 cmets（在线和离线）提出了可以改进的方法。

【讨论】：

存储可能（几乎）免费，但传输不是。哦，顺便说一句，还有很多很好的二进制格式。
好点，我会补充的。我想我让我的偏见表现出来:-)
"你考虑过数据库吗？" - 那不也是一个文件吗？我认为这只是将责任转移到制作二进制数据库文件格式的人身上，但谁知道那从现在起 30 年后会如何工作。
嗯，是的，也不是。它将它带入了一个全新的领域，这就是为什么我没有多说。我同意你的观点，但我认为存储在数据库中在某种意义上与文件有根本的不同，因为你通常通过 SQL 访问，通常是通过网络而不是流。
我只是说这会使您的程序依赖于通常无法控制的复杂数据库服务器 API/库。如果 db 格式由于某种原因不再支持，您将再次遇到“无法理解的二进制内容”问题，您需要显式迁移数据。

【解决方案2】：

这完全取决于情况。

人类可读格式的好处：

您可以阅读它的“原生”格式
您可以自己编写，例如用于单元测试 - 甚至是真实内容，具体取决于它的用途

二进制格式的可能好处：

更容易解析（就代码而言）
解析速度更快
在空间方面更高效
更易于控制（任何时候您需要其中的文本，您都可以确保它是 UTF-8 编码的，并且以长度为前缀等）
更容易有效地包含不透明的二进制数据（图像等 - 使用 base64 格式的文本格式）

不要忘记，您始终可以实现二进制格式，但也可以制作工具来转换成人类可读的格式。这就是 Protocol Buffers 框架所做的——实际上，IME 很少需要解析协议缓冲区的文本版本，但能够将其写为文本真的很方便。

编辑：以防万一这最终成为一个公认的答案，您还应该记住the point made by starblue：人类可读的形式非常更适合区分。我怀疑设计一种适用于 diff 的二进制格式（并且可以生成人类可读的 diff）是可行的，但现有 diff 工具的开箱即用支持对于文本来说会更好。

【讨论】：

我不确定“更容易解析”这一点：我觉得在文本中实现“灵活”格式比在二进制中更容易（特别是如果您在手）。对于“固定”格式，您是完全正确的。
这取决于灵活性的意义所在。我知道我一直以协议缓冲区为例，但它们在狭窄的范围内很灵活，而且很容易解析（特别是如果你忽略了一些遗留的东西）。但是，是的，这取决于您的最终目标。
很容易设计一种易于区分的二进制格式：如果您的格式可以处理它，只需在明确定义的位置添加 EOL 字符 - 例如一次 1 条记录，EOL 终止。例如，这不适用于图像。基于文本的差异往往通过一次比较行来工作，二进制文件并不能很好地区分，因为它们实际上是 1 个巨大的行（大致）。

【解决方案3】：

版本控制使用文本格式更容易，因为可以轻松查看和合并更改。

尤其是 MS-Word 在这方面让我们感到悲痛。

【讨论】：

我同意；不幸的是，版本控制往往是基于行的。这实际上不适用于文本文档，其中一个段落可能很长，并且即使是轻微的错字修复也会被标记为完全更改...
我认为 XML 不是文本，基于两个观察结果：(1) 2 个 XML 文档的文本连接不会产生一个 XML 文档，以及 (2) 区分 2 个 XML 文档的文本使用无关紧要空格（换行符）而不是正确的结构（树）
@MSalters 通过同样的论点，您可能会争辩说大多数编程语言都不是文本，这表明您的论点是虚假的。
+1 能够将差异与版本控制一起使用对许多文件非常有帮助
那些设计文本文件格式的人还有两个愿望：如果您有列表，请将每个项目放在单独的行上。如果顺序无关紧要，请将项目按规范顺序放置（例如对它们进行排序）。

【解决方案4】：

开放格式——没有二进制位玩弄
可读性:)
跨平台交互
调试帮助
易于解析（并轻松转换为任何格式）

有一点很重要：您编写了一次解析器，但多次读取了输出。这种情况会使天平向有利于 HRF 的方向倾斜。

【讨论】：

其中，我想说只有 2 和 4 是有效的，而且它们本质上是相同的。格式可以是开放的，但仍然是二进制的；格式可以是平台中立的，但不是人类可读的（例如协议缓冲区），并且二进制数据比文本更容易解析。
2 适用于客户端，而 4 适用于开发人员/QA/QE。当然，有开放的二进制格式——但 HRF也是开放的。为什么 HRF 比二进制更难解析？会慢一些，我同意。毕竟，HRF 并不意味着它是由人类编写的 :)
其实，现在我在想，如果它根据一些格式规则形成良好的格式，它是否会更慢。
2 表示 4 IMO。至于解析：1）缺少不同的编码； 2）二进制格式可以很容易地“自然”形成良好的格式； 3) 使用固定长度标记而不是任意元素名称等更为常见。这是协议缓冲区比 XML 快得多的部分原因:)
> 3) 更常见的是做定长标记：这是 HRF 做不到的吗？看看任何编程语言，我敢打赌，简洁性（读取固定长度的标记）并不一定会影响可读性。

【解决方案5】：

一个主要原因是，如果有人需要读取数据，比如 30 年后，可以找出人类可读的格式。二进制要困难得多。

如果您有本质上是二进制的大型数据集（例如图像），那么它们显然不能以二进制形式存储。但即便如此，元数据也可以（而且应该！）是人类可读的。

【讨论】：

我花了大约一周的时间对暗黑破坏神 2 的存档进行逆向工程，我得到了一个令人发指的神谕！（游戏本身，非安全极客）

【解决方案6】：

有一种东西叫做Unix 编程的艺术。

我不会说它的好坏，但它相当有名。它有一个whole chapter called Textuality，作者在其中断言人类可读的文件格式是 Unix 编程方式的重要组成部分。

【讨论】：

【解决方案7】：

它们打开了使用原始工具以外的工具创建/编辑的可能性。其他人可以开发新的更好的工具，集成到第三方应用程序成为可能。例如，考虑二进制 iCal 文件 - 这种格式会成功吗？

除此之外：人类可读文件提高了调试能力，或者对于精明的用户来说，至少可以找到错误的原因。

【讨论】：

【解决方案8】：

二进制的优点：

解析速度快
通常较小的数据
轻松编写解析器

人类可读的优点：

阅读时更容易理解 - 没有“字段 X 设置为 4 487，这意味着应该立即关闭反应堆”
如果使用 XML 之类的东西很容易编写一个可以解析任何文件的工具

我不得不处理这两种类型。如果您要发送数据并且希望将其保持为小二进制，则很好。如果您希望人们阅读它，那么人类可读性很好。

人类可读的通常也有点自我记录。使用二进制文件很容易出错，而且很难发现。

【讨论】：

【解决方案9】：

可编辑
可读（呃！）
可打印
记事本和 vi 已启用

最重要的是，它们的功能可以从内容中推断出来（大多数情况下）

【讨论】：

可打印？哈哈。谢天谢地，我从来不用打印我的物品 :)

【解决方案10】：

因为您是人类，迟早您（或您的一位客户）将能够读取数据。

如果速度是一个问题，我们只使用二进制格式。即使这样调试也很麻烦，所以我们添加了一个人类可读的等效项。

【讨论】：

【解决方案11】：

互操作性是标准论点，即人类可读的形式对于不同系统的开发人员来说更容易处理，因此具有一些优势。

我个人认为这是不正确的，二进制文件的性能优势应该超过这个论点，特别是如果你发布你的协议。然而，基于 XML/HTTP 的机器交互框架无处不在，这意味着它更容易被采用。

XML 被过度使用了。

【讨论】：

【解决方案12】：

只是一个简单的说明，人类可读的文档格式可能是更好的选择：

用于在生产中部署应用程序的文档

我们以前的发行说明是word格式的，但发行说明文档必须在预生产和生产平台的各种环境（Linux、Solaris）上打开。
为了提取各种数据，还必须对其进行解析。

最后，我们切换到基于 wiki 的语法，仍然可以通过 wiki 很好地显示在 HTML 中，但在其他情况下仍然用作简单的文本文件。

【讨论】：

【解决方案13】：

除此之外，还有不同级别的人类可读性，所有这些都可以通过使用具有代码着色、折叠或导航功能的优秀编辑器或查看器来增强。

例如，

即使是明文，JSON 也非常易读
XML 有 angle bracket tax，但在使用好的编辑器时可以使用
INI 大部分是人类可读的
CSV 可读，但最好加载到电子表格中。

【讨论】：

【解决方案14】：

没有人说，所以我会说：人类可读性并不是文件格式的真正属性（毕竟所有文件都是二进制文件），而是文件格式和查看器应用程序组合的属性。

所谓的人类可读格式都是基于现有文本编码之一的附加抽象层之上的。能够以人类可读的形式呈现这些编码的查看器程序（通常也用作编辑器）非常常见。

文本编码标准广泛且相当成熟，这意味着它们在可预见的未来不太可能发生太大变化。

通常在格式的文本编码层之上，我们会找到一个语法层，该层在给定目标用户知识和文化背景的情况下相当直观。

因此“人类可读”格式的好处：

合适的查看器和编辑器无处不在。
永恒（鉴于文化习俗不会发生太大变化）。
易于学习、阅读和修改。

依赖额外的抽象层制作文本编码文件：

太空饥渴。
处理速度较慢。

“二进制”文件不使用文本编码抽象层作为基础（或公分母），但它们可能会或可能不会使用更适合其目的的某种额外抽象，因此，它们可以是很多更好地优化手头的特定任务含义：

处理速度更快。
占用空间更小。

另一方面：

查看器和编辑器特定于特定的二进制格式，使互操作性更加困难。
任何给定格式的观看者都不太广泛，因为他们更专业。
随着时间的推移，格式可能会发生显着变化或不再使用：它们的主要优点是非常适合特定任务，并且随着任务或任务要求的发展，格式也会发生变化。
李>

【讨论】：

非常好的观点。如果将“人类可读”格式存储在 Unicode 中并且我只有一个 ANSI 查看器，那么它就不是很好了。

【解决方案15】：

花点时间想想 Web 开发以外的应用程序。

假设： A）它具有“明显”的含义，在文本格式中是错误的。像钢厂或制造厂的控制系统这样的东西在人类可读方面通常没有任何优势。用于这些类型环境的软件通常具有以图形方式显示数据的例程。

B) 以文本形式输出更容易。实际上需要更多代码的不必要的转换使系统变得不那么健壮。事实上，如果您不使用将所有变量都视为字符串的语言，那么人类可读的文本就是额外的转换。 IE。额外的代码意味着有更多的代码需要验证、测试，并且有更多的机会在应用程序中引入错误。

C) 无论如何你都必须解析它。对于我工作过的 DSP 系统来说，很多情况下（即没有人类可读的界面开始。）数据以统一大小的数据包从系统中流出。记录数据以供分析和后续处理只需指向缓冲区的开头并将块大小的倍数写入数据记录器系统即可。这使我能够分析“未触及”的数据，因为客户的系统会看到它，再次将其转换为不同的格式会导致可能引入错误。不仅如此，如果您只保存“转换后的数据”，您可能会丢失翻译中可能帮助您诊断问题的信息。

D) 文本是数据的自然格式。我从未见过任何硬件使用“TEXT”接口。（我大学毕业后的第一份工作是为相机线扫描相机编写设备驱动程序。）建立在它之上的系统可能确实如此，但适用于每台“PC”。

对于信息在文本格式中具有“自然”含义的网页，请务必将自己击倒。当然，对于处理源代码来说，这是一件轻而易举的事。但是，即使是冰箱和牙刷也将内置处理器的普遍计算环境，并没有那么多。简单地给这些类型的系统增加处理文本的能力会带来不必要的复杂性。您不会将“printf”链接到控制鼠标的 8 位微控制器的软件中。（是的，也必须有人编写该软件。）

世界不是一个黑白分明的地方，需要考虑的唯一计算形式是 PC 和 Web 服务器。

即使在 PC 上，如果我可以使用单个 OS 读取调用直接将数据加载到数据结构中，并且无需编写序列化和反序列化例程就可以完成，那就太棒了，检查块 CRC 工作——完成下一个问题。

【讨论】：

【解决方案16】：

嗯……因为人类可读的文件格式可以被人类阅读？对我来说似乎是一个很好的理由。

（嗯，对于配置文件，它们不可避免地会被人类读取（和编辑！）。用于某种持久存储的文件实际上不需要人类读取或编辑。）

【讨论】：

【解决方案17】：

我为什么要使用人类可读的文件格式优先于二进制格式？有没有这样的情况不是吗？

是的，如果它们是人类可读的压缩卷（zip、jpeg、mp3 等）将不是最佳的。

【讨论】：

如果它们是二进制的，你就不需要压缩它们......唯一需要它的原因是因为文本格式过于臃肿。
@Simon：Word 文档（传统的）是二进制的，你可以很好地压缩它们。我敢说他们也很臃肿。
@Simon：我不知道你是否同意我的回答。由于膨胀，压缩工作......
@Simon：“如果它们是二进制的，你就不需要压缩它们”——你可能的意思是“你需要压缩它们，因为它们不是二进制的”。 'Y if X' 不等于。到 'X if Y' 等等。
@Simon Buchan：另外，“text => bloated”不等同于“not text => not bloated”。然而，真实的是“不臃肿 => 不是文本”。

【解决方案18】：

我想它在大多数情况下可能都不好。我认为这些格式（例如 JSON 和 XML）的主要原因是 Web 开发，以及在 Web 上的普遍使用，您需要能够在用户端处理数据，而您不一定能读取二进制文件。使用人类可读格式的坏情况的一个很好的例子是任何非文本的东西，例如图像、视频、音频。我注意到在 Web 开发中使用非二进制格式毫无意义，我感到内疚！

【讨论】：

【解决方案19】：

文件通常会成为人机界面的一部分，因此它们应该是人性化的（不仅仅是程序员）

【讨论】：

【解决方案20】：

我对非归档文件使用二进制流的唯一一次是我想对不经意的观察者隐藏一些东西。例如，如果我正在制作只有我的应用程序应该编辑的临时文件，我将使用二进制文件。

这不是试图混淆，而是阻止用户手动编辑文件（这可能会破坏应用程序）。

这将是一个好主意的一个实例是存储/保存有关某些游戏的运行数据..即保存您的游戏并稍后继续。其他场景将描述中间文件，但这些通常是二进制/字节编译的。

【讨论】：

【解决方案21】：

我为什么要使用人类可读的文件格式优先于二进制格式？

取决于内容和上下文，即数据的来源和去向。如果数据通常是由人直接编写的，那么将其存储为可以通过文本编辑器进行操作的格式是一个好主意。例如，程序源代码通常会被存储为人类可读的，这是有充分理由的。但是，如果我们将其归档或使用版本控制系统共享它，我们的存储策略就会发生变化。

【讨论】：

【解决方案22】：

如果字段有问题，人工格式更易于解析和调试（例如：字段包含一个数字，规范规定此字段必须是字符串），人工格式也更接近域问题。

我更喜欢包含大量数据的二进制格式，并且我确信我有解析他的软件:)

【讨论】：

【解决方案23】：

在阅读菲尔丁关于 REST 的论文时，我非常喜欢“Architectural Properties”的概念；一个坚持的是“可见性”。这就是我们在这里所说的：能够“看到”数据。调试系统时的巨大好处。

我发现其他答案中缺少一个方面：强制语义。

从您追求人类可读性的那一刻起，您就允许愚蠢的记事本用户创建要输入系统的数据。没有办法保证这些数据是有意义的。无法保证系统会以合理的方式做出响应。

因此，如果您不需要使用记事本检查数据，并且希望强制执行有效数据（例如通过使用 API）而不是首先验证数据，那么您最好避免使用人类可读的数据。如果可调试性是一个问题（通常是），也可以使用 API 来检查数据。

【讨论】：

人们不能使用二进制编辑器（故意）损坏二进制文件，也不能不小心因网络或磁盘访问错误而损坏二进制文件。我认为人类可读可能会使这种情况更有可能发生，但两者都没有提供任何保证
人类可读文件实际上是人类可写的不同属性。您可能应该将 CRC32 之类的内容附加到人类可读的文件中，以明确表明该格式不适用于直接编辑

【解决方案24】：

人类可读不等于更容易被机器码解析。

以人类自然语言为例。 :) 人类语言的机器解析仍然是一个有待完全解决的悬而未决的问题。

所以我同意https://stackoverflow.com/a/714111/2727173 对这个问题有更深入的了解。

【讨论】：