55

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

编辑：我在最初发布问题时确实有这个解释，但现在它不那么相关了：

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

4

24 回答 24

80

这取决于

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

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

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

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

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

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

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

值得商榷

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

归根结底，我认为两者都不能真正在这里占据优势。

还要别的吗

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

学分

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

于 2009-02-20T08:52:06.987 回答
26

这完全取决于情况。

人类可读格式的好处：

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

二进制格式的可能好处：

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

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

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

于 2009-02-20T08:17:54.367 回答
17

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

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

于 2009-02-20T08:37:31.747 回答
7
  • 开放格式——没有二进制位杂耍
  • 可读性:)
  • 跨平台交换
  • 调试辅助
  • 易于解析（并轻松转换为任何格式）

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

于 2009-02-20T08:13:26.873 回答
6

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

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

于 2009-02-20T08:18:04.787 回答
6

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

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

于 2009-02-20T08:46:08.623 回答
4

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

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

于 2009-02-20T08:16:53.980 回答
4

二进制的优点：

  • 快速解析
  • 通常较小的数据
  • 易于编写解析器

人类可读的优点：

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

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

人类可读的通常也有点自我记录。使用二进制很容易出错 - 并且很难发现它们。

于 2009-02-20T08:18:23.070 回答
3

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

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

于 2009-02-20T08:14:06.933 回答
3
  • 可编辑
  • 可读（呃！）
  • 可打印
  • 记事本和 vi 已启用

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

于 2009-02-20T08:19:27.123 回答
2

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

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

XML 被过度使用了。

于 2009-02-20T08:16:29.957 回答
2

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

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

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

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

于 2009-02-20T08:23:45.490 回答
2

作为对此的补充，人类可读性有不同的水平，所有这些都可以通过使用带有代码着色、折叠或导航的优秀编辑器或查看器来增强。

例如，

  • 即使是明文，JSON 也非常易读
  • XML 有尖括号税，但在使用好的编辑器时可以使用
  • INI 主要是人类可读的
  • CSV 可以读取，但最好加载到电子表格中。
于 2009-02-20T08:24:36.427 回答
2

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

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

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

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

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

  • 合适的观众和编辑无处不在。

  • 永恒（鉴于文化习俗不会发生太大变化）。

  • 易于学习、阅读和修改。

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

  • 太空饥渴。

  • 处理速度较慢。

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

  • 处理速度更快。

  • 占地面积更小。

另一方面：

  • 查看器和编辑器特定于特定的二进制格式，使互操作性更加困难。

  • 任何给定格式的观众都不太广泛，因为他们更专业。

  • 格式可能会随着时间的推移发生显着变化或不再使用：它们的主要好处是非常适合特定任务，并且随着任务或任务要求的发展，格式也会发生变化。

于 2009-04-03T14:18:04.040 回答
2

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

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

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

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

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

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

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

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

于 2009-06-23T18:14:22.370 回答
1

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

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

于 2009-02-20T08:14:39.320 回答
1

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

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

于 2009-02-20T08:17:53.510 回答
1

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

于 2009-02-20T08:22:08.070 回答
0

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

于 2009-02-20T08:19:58.013 回答
0

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

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

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

于 2009-02-20T08:44:18.673 回答
0

为什么我应该使用人类可读的文件格式而不是二进制格式？

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

于 2009-02-20T08:44:45.850 回答
0

如果您对某个字段有问题（例如：一个字段包含一个数字，其中规范规定该字段必须是一个字符串），则人工格式更易于解析和调试，而且人工格式更接近问题领域。

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

于 2009-02-20T08:55:35.683 回答
0

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

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

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

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

于 2009-02-20T12:30:44.510 回答
0

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

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

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

于 2013-08-28T22:11:47.180 回答