“表格数据”的 XML 或 CSV答案

【问题标题】：XML or CSV for "Tabular Data"“表格数据”的 XML 或 CSV
【发布时间】：2011-05-04 09:22:18
【问题描述】：

我有“表格数据”要从服务器发送到客户端 --- 我正在分析我应该使用 CSV 格式还是 XML。

我发送的数据可以以 MB 为单位，服务器将对其进行流式传输，客户端将逐行读取它以开始解析输出（客户端无法等待所有数据到来）。

按照我目前的想法，CSV 会很好 --- 它会减少数据大小并且可以更快地解析。

XML 是一种标准——我关心的是解析数据，因为它涉及到系统（实时解析）和数据大小。

最好的解决方案是什么？

感谢所有宝贵的建议。

【问题讨论】：

CSV 可以逐行读取（客户端希望在它出现时对其进行解析）。 XML 将不得不等待结束 </data> 标记。如果您同时拥有服务器和客户端，则可以使用 CSV。
@eumiro：我认为 SAX 解析器意味着用于流。
@Matthieu M 是的，我们当然可以使用 SAX 解析器，它解决了实时读取的问题，但即使是 SAX 也只有在节点结束后才返回

【解决方案1】：

如果是“表格数据”并且表格相对固定且规则，我会选择 CSV 格式。特别是如果它是一个服务器和一个客户端。

如果您有多个客户端并希望在使用数据之前验证文件格式，XML 会有一些优势。另一方面，XML 已经垄断了“代码膨胀”市场，因此转移的数量会大大更大。

【讨论】：

【解决方案2】：

我会使用 CSV，带有一个标头，指示每个字段的 id。

id, surname, givenname, phone-number
0, Doe, John, 555-937-911
1, Doe, Jane, 555-937-911

只要你不忘记标题，如果数据格式发生变化，你应该没问题。当然，客户端需要在服务器开始发送新流之前更新。

如果不是所有客户端都可以轻松更新，那么您需要一个更宽松的消息传递系统。

Google Protocol Buffer 专为此类向后/向前兼容性问题而设计，并将其与出色的（快速且紧凑的）二进制编码能力相结合以减小消息大小。

如果你这样做，那么想法很简单：每条消息代表一条线。如果要流式传输它们，则需要一个简单的“消息大小 | 消息 blob”结构。

就我个人而言，我一直认为 XML 在设计上过于臃肿。如果您曾经使用人类可读格式，那么至少选择 JSON，您将减少一半的标签开销。

【讨论】：

我已经尝试在我的解析器 CSV 标头之一中识别列索引非常方便 --- 如果 coleman 也有一些变化，这可以使您的解析器工作。我将研究 Google Protocol Buffer 以了解他们如何更好地实现这一点。

【解决方案3】：

我建议你选择 XML。有很多库可用于解析。而且，如果以后数据格式发生变化，XML的解析逻辑不会改变，只是业务逻辑可能需要改变。 But in case of CSV parsing logic might need a change

【讨论】：

【解决方案4】：

CSV 格式会更小，因为您只需删除第一行的标题，然后删除下面的数据行，中间只有逗号即可将任何额外字符添加到流大小。

【讨论】：