3

我有一个应用程序，它将在 XML 文件中存储一系列（浮点）值。可能有超过 100,000 个值，所以我有兴趣减小大小，但我也希望第三方可以轻松访问文件。

就在 XML 中编码数据而言，似乎有多种方法可供我使用：

1.

<data>
  <value>12.34</value>
  <value>56.78</value>
  ...
  <value>90.12</value>
</data>

2.

<data>
  <value v="12.34"/>
  <value v="56.78"/>
  ...
  <value v="90.12"/>
</data>

3.

<data>12.34
56.78
  ...
90.12
</data>

4.

<data>12.34, 56.78, ... 90.12</data>

并且可能还有更多变化。

我只是想知道这些方法的缺点（如果有的话）。例如，有些可能不合规。

4

4 回答 4

3

我认为没有“更好”的方式来做到这一点。阅读我上面的评论以获取替代方案。但是，如果您迷上了 XML，那么请选择适合您的任何方法。我个人更喜欢这样的东西

<data>
   <item key="somekey1" value="somevalue1" />
   <item key="somekey2" value="somevalue2" />
   <item key="somekey3" value="somevalue3" />
</data>

仅仅是因为它美观且易于阅读，并且标签更小。

编辑：

请记住，XML 中的字符越少，它就越小。（再次，为什么我建议使用 JSON），所以如果你能把它弄得又好又紧，一定要去做。

<d>
   <i k="somekey1" v="somevalue1" />
   <i k="somekey2" v="somevalue2" />
   <i k="somekey3" v="somevalue3" />
</d>

编辑：

另外，我知道你没有问，但我想我会向你展示 JSON 的样子

   [{ "key": "somevalue1", "value": "somevalue1"},
    { "key": "somevalue2", "value": "somevalue2"}]
于 2010-06-05T04:32:55.220 回答
3

从语义上讲，1 和 2 之间没有“区别”。同样，3 和 4 之间也没有区别，除了一个是分隔的。另请注意，空格在 XML 中是/可以忽略的，因此如果您阅读 #3，它很可能会出现为“一长行”而没有任何换行符分隔它们。

至于哪个更好，这取决于您的应用程序，以及您计划如何使用数据。

序列化版本（每个数字都在其自己的元素中）使用户可以“直接”访问各个数字。

使用分隔的“blob”需要用户自己解析它，所以这取决于您希望提供什么样的接口。

此外，“blob”技术往往会阻止 XML 被“流式传输”，因为您将拥有一个巨大的元素，而不是一堆小元素。这可能会产生很大的内存影响。

至于整体文件大小，了解您实际压缩此数据可能会有所帮助，无论采用何种技术，最终的压缩大小可能会非常接近。不知道该属性是否重要。

于 2010-06-05T04:35:09.147 回答
2

前两种形式优于后两种形式，第一种是最好的。后两者需要读取数据内容并在使用之前对其进行拆分。但是，前两个允许您枚举数据并在任何给定时间仅使用您需要的部分。但是，第二种形式通过属性将值嵌入到另一个层中，这使得它不如第一种形式（假设每个特定数据点没有其他元素/属性）。

于 2010-06-05T04:33:03.140 回答
1

如果您的文件将处理的唯一数据始终是那些浮点值，请不要使用 XML。仅使用每行带有值的纯文本文件。它的读写速度会快很多倍，而且与您编写的 XML 示例相比，它的自我描述性也不会差一点。

XML 可能是一项要求，例如，您将使用来自具有不同文化（TR、EN、FR）的不同应用程序/系统/用户的此 XML 文件。有些人用'.'写浮点数 （12.34）而有些人用'，'（12,34）来写它们。XML 解析器将为您处理所有这些内容。因此，如果需要 XML，那么您编写的第 3 和第 4 个示例完全忽略了 XML 的意义。实际上，它们与使用纯文本文件没有什么不同，除了值班的慢速 XML 解析器。

你写的第一个和第二个样本在含义/解释上只有细微的差别。第一个暗示您想要呈现的实际数据是 12.34，它是一个“值”。第二个意味着有一个“值”，与之关联的“v”数据是 12.34。

于 2010-06-29T00:44:39.900 回答