C++ 的“最佳”输入文件格式？ [关闭]

Question

我正在着手开发一款新软件，该软件最终需要一些强大且可扩展的文件 IO。那里有很多格式。 XML、JSON、INI 等。然而，总有优缺点，所以我想我会征求一些社区意见。

以下是一些粗略的要求：

1. 格式是“标准”...如果我不需要，我不想重新发明轮子。它不一定是正式的 IEEE 标准，但作为新用户，您可以通过谷歌搜索并获取一些信息，可能有一些超出 vi 的支持工具（编辑器）。 （尽管软件用户通常会精通计算机并乐于使用 vi。）
2. 与 C++ 轻松集成。我不想使用 100mb 的库和三个不同的编译器来启动和运行它。
3. 支持表格输入（二维、n 维）
4. 支持 POD 类型
5. 可以在需要更多输入时进行扩展，很好地绑定到变量等。
6. 解析速度并不是很重要
7. 理想情况下，写（反映）和读一样容易
8. 在 Windows 和 Linux 上运行良好
9. 支持合成（一个文件引用另一个要读取的文件，依此类推。）
10. 人类可读

在一个完美的世界里，我会使用一个仅包含标头的库或一些干净的 STL 实现，但如果它运行良好，我可以使用 Boost 或一些小型外部库。

那么，您对各种格式有何看法？缺点？优势？

编辑

要考虑的选项？还有什么要补充的吗？

• XML
• YAML
• SQLite
• Google 协议缓冲区
• Boost 序列化
• INI
• JSON

Answer 1

有一种出色的格式可以满足您的所有标准：

SQLite！

请阅读 article 关于使用 SQLite 作为应用程序文件格式的信息。另外，请由 D. Richard Hipp（SQLite 作者）watch Google Tech Talk 讨论这个主题。

现在，让我们看看 SQLite 如何满足您的要求：

格式是“标准”

SQLite 已成为大多数移动环境和许多桌面应用程序（Firefox、Thunderbird、Google Chrome、Adobe Reader 等等）的首选格式。

轻松与 C++ 集成

SQLite 有standard C interface，只有一个源文件和一个头文件。有C++ wrappers too。

支持表格输入（2d、n 维）

SQLite 表就像您想象的那样是表格的。要表示 3 维数据，请创建包含 x,y,z,value 列的表并将您的数据存储为一组行，如下所示：

x1,y1,z1,value1
x2,y2,z2,value2
...

支持 POD 类型

我假设 POD 是指普通旧数据或 BLOB。 SQLite 允许您按原样存储 BLOB 字段。

可以根据需要进行更多输入扩展，很好地绑定到变量

这是它真正闪耀的地方。

解析速度并不是很重要

但是 SQLite 的速度非常棒。其实解析基本上是透明的。

理想情况下，写（反映）和阅读一样容易

只需使用INSERT 写作和SELECT 阅读 - 还有什么比这更容易的呢？

在 Windows 和 Linux 上运行良好

您打赌，所有其他平台也是如此。

支持合成（一个文件引用另一个文件读取）

您可以将一个数据库附加到另一个数据库。

人类可读

不是二进制的，但是有很多优秀的 SQLite 浏览器/编辑器。我喜欢 Windows 上的 SQLite Expert Personal 和 Linux 上的 sqliteman。还有SQLite editor plugin for Firefox。

---

SQLite 免费为您提供的其他优势：

• 数据是可索引的，这使得搜索速度非常快。使用 XML、JSON 或任何其他纯文本格式是无法做到这一点的。

• 即使数据量非常大，也可以部分编辑数据。您不必为了编辑一个值而重写几 GB。

• SQLite 完全是事务性的：它保证您的数据在任何时候都是一致的。即使您的应用程序（或整台计算机）崩溃，您的数据也会在下次首次尝试连接到数据库时自动恢复到上次已知的一致状态。

• SQLite 存储您的数据逐字记录：您无需担心转义数据中的垃圾字符（包括字符串中嵌入的零字节） - 只需始终使用 prepared statements，即使其透明所需的一切。在处理文本数据格式（尤其是 XML）时，这可能是一个大而烦人的问题。

• SQLite 以 Unicode 存储所有字符串：UTF-8（默认）或UTF-16。换句话说，您无需担心文本编码或数据格式的国际支持。

• SQLite 允许您以小块（实际上是逐行）处理数据，因此它在低内存条件 中运行良好。这对于任何基于文本的格式都是一个问题，因为它们通常需要将所有文本加载到内存中来解析它。诚然，市面上很少有高效的基于流的 XML 解析器，但总的来说，与 SQLite 相比，任何 XML 解析器都会非常消耗内存。

Answer 2

在使用 XML 和 json 进行了大量工作后，以下是我对两者作为可扩展序列化格式的相当主观的看法：

• 格式是“标准”：两者都可以
• 与 C++ 轻松集成：两者都支持。在每种情况下，您可能最终都会使用某种库来处理它。在 Linux 上，libxml2 是一个标准，而 libxml++ 是它的 C++ 包装器；您应该能够从发行版的包管理器中获得这两个。让那些在 Windows 上工作的人需要一点点努力。 Boost 中似乎对 json 有一些支持，但我没有使用过；我一直使用库来处理 json。确实，图书馆的路线对任何一方来说都不是很繁重。
• 支持表格输入（二维、n 维）：两者都支持
• 支持 POD 类型：两者都支持
• 可以在需要更多输入时进行扩展：两者都可以，这对他们来说都是一大优势。
• 很好地绑定到变量：如果您的意思是在文件本身内部以某种方式说“此 条数据必须在我的程序中自动反序列化为 this 变量"，那么两者都不是。
• 编写（反映）和阅读一样容易：取决于您使用的库，但根据我的经验，两者都可以。 （您实际上可以使用 printf() 完成编写 json 的工作。）
• 在 Windows 和 Linux 上运行良好：两者都可以，同样适用于 Mac OS X。
• 支持一个文件引用另一个文件来读取：如果您的意思类似于 C #include，那么 XML 具有执行此操作的能力（例如文档实体），而 json 则没有。
• 人类可读：两者通常都以 UTF-8 编写，并且允许换行和缩进，因此可以是人类可读的。但是，我刚刚处理了一个 479 KB 的 XML 文件，它全部在一行上，所以我必须通过漂亮的打印机运行它才能理解它。 json 也可能很难读取，但根据我的经验，它的格式通常比 XML 更好。

开始新项目的时候，我一般比较喜欢json；它更紧凑，更易于阅读。我可能会选择 XML 而不是 json 的主要原因是如果我担心收到格式错误的文档，因为 XML 支持自动文档格式验证，而您必须使用 json 编写自己的验证代码。

Answer 3

查看google buffers。这可以满足您的大部分要求。

From their documentation，高级步骤是：

在 .proto 文件中定义消息格式。
使用协议缓冲区编译器。
使用 C++ 协议缓冲区 API 来写入和读取消息。

Answer 4

出于我的目的，我认为要走的路是 XML。

1. 格式是一种标准，但允许对架构进行修改和灵活性，以便随着程序要求的发展而变化。
2. 有几个库选项。有些较大 (Xerces-C) 有些较小 (ezxml)，但有很多选择，因此我们不会局限于单一提供商或非常具体的解决方案。
3. 它可以支持表格输入（2d，n维）。这需要在“我们的”端进行更多的解析工作，这可能是 XML 的最薄弱环节。
4. 支持 POD 类型：绝对支持。
5. 可以根据需要更多输入进行扩展，通过架构修改和解析器修改很好地绑定到变量等。
6. 解析速度并不是很重要，因此处理一个或多个文本文件不是问题。
7. XML 可以通过编程方式编写，就像阅读一样容易。
8. 在 Windows 和 Linux 或任何其他支持 C 和文本文件的操作系统上运行良好。
9. 支持合成（一个文件引用另一个要读取的文件，依此类推。）
10. 人类可读的许多文本编辑器（Sublime、vi 等）支持开箱即用的语法突出显示。许多网络浏览器都能很好地显示数据。

感谢大家的好评！我认为如果我们想要一个纯粹的二进制解决方案，Protocol Buffers 或 boost::serialization 可能是我们应该采用的方式。