使用基于文本的数据格式绝对没有错。几十年来，它一直是事实上的标准。大型大型机金融系统至今仍在使用它。其好处是生产起来微不足道，消费起来微不足道，而且重量轻得令人难以置信。那么日志文件呢？您知道不以分隔文本格式生成日志文件的生产平台吗（web、应用程序、数据库服务器）？

平面文本文件的缺点是，如果格式发生更改，则必须对生产者和消费者端进行非常规的修改，以便能够支持格式更改。当然，如果这只是一个人在消耗结果，那么你只需要更换制作人。

XML的美妙之处在于，数据的解析不仅独立于数据，而且独立于数据的格式。从逻辑上讲，您将数据和数据格式都传递给它，然后presto！一切正常。事情并没有那么简单，但这是前提。你可以改变数据的格式，而你的生产者和消费者只需要细微的改变（如果有的话）。

XML的丑陋之处在于，它可能是一只巨大的性能狗（SOAP有人吗？），而且重量非常重。你肯定要为它的可扩展性付出代价。在某些情况下，它绝对是给定问题领域的优化技术解决方案，而在其他情况下则不然。

所以，如果这是一个人类将要读取的简单日志，请将其保存为平面文件。如果它是一个简单的应用程序，与另一个应用程序通信和，那么通信不会随着时间的推移而发生显著变化，平面文件实现起来肯定更快、更轻，但XML不是一个糟糕的选择。如果多个应用程序需要使用您提供的数据，或者通信量变化很大，那么就使用XML。随着时间的推移，界面的维护将更加容易。

我想到了几个好处：

• It s easier to parse into other applications
• It s easier to understand what the document holds at a glance
• Makes it easier to pull data into a managerial dashboard
• Makes the management happy with little pain for you

在我看来，缺点是：

• Means changing existing code, probably unnecessarily
• Possible slight performance degradation, depending on how you build the documents compared to how you build the current docs
• It s XML for XML s sake, which is effin stupid

最后，引用一句讽刺的话：＜i＞XML就像暴力。如果它不能解决你的问题，那就是你用得不够

在这种情况下，XML的主要特征是XML可以被验证&；受约束的。在文本版本中，如何能够以编程方式验证文件的格式是否正确？XML被设计用于创建结构化、有效的文档，由此带来的好处是格式受到严格控制，并且结构可靠。维护从XML节点读取的代码也将比维护一系列用于读取文本文件的正则表达式更容易，逻辑布局也更合理。

如果使用XML，那么在某些方面，数据将更加“可移植”。在大多数环境中，基本上都可以使用数据解析器，因此编写一个分析数据的工具可能会更容易。此外，如果它是XML格式的，那么您可以编写一个XSLT将其转换为各种其他格式，使其更易于阅读。

也就是说，如果您改用XML，即使是像您给出的示例这样的简单格式，您的日志文件也会变得更大。

除了XML之外，还有一些选项可以使用。杰夫尖括号税博客文章对此进行了一些讨论。

实际上，您应该做的是了解如何使用这些日志，然后确定什么格式可以使这些使用最容易实现。

使用regex、xml和xsl可以很容易地进行解析。

说实话，除非将数据发送到另一个系统，否则使用XML并没有真正的“优势”。

XML是一种元格式，这意味着它可以更容易地定义数据的格式。这使得多个程序（包括不同公司的程序）更容易以相同的格式读取和写入数据。它特别适合作为复杂的、分层的数据的描述。

在上面概述的示例中，数据看起来是固定格式的隔离记录，没有结构或层次结构——在这种情况下，我看不出使用XML有什么好处。然而，该示例可能不具有代表性——您的其他文件可能包含更多结构化数据。

这是一个正在进行的日志文件吗？

你打算如何编写来创建一个有效的文档？还是你要把它读进去，添加新的条目，每次都写出来？

日志文件是结构良好的纯文本行的完美候选者，您只需将其附加到其中即可。

在大多数情况下（并非总是如此），XML使数据更容易理解，因为突然之间，您的资产周围就有了元数据，这些元数据描述了您面前的内容（人类可读）。

XML也非常容易访问。我的意思是，既然你提到了这一点，你就不想在XML上使用正则表达式。有类似于XPATH（XML路径语言），它使查询XML变得有趣。当您可以使用XPATH之类的东西轻松地遍历XML时，无需提取其他人无法读取的内容。

在某些情况下，XML会起到相反的作用（就可读性而言），有时XML也是开销。当您在系统之间交换数据时，它并不总是最好的选择（例如，看看像JSON）。而且这种交换也不需要在网络上进行。

虽然将XML用于数据文件意味着您的数据可以自我描述，也许可以更好地组织，但最终结果往往是数据文件比以前大得多。

问问自己，这些文件是用来做什么的？它们会被改变吗？如果是这样的话，谁来买单，谁来做预算？

在某些情况下我喜欢XML，而在其他情况下我讨厌它！

在您所说的系统批处理编程的情况下，xml的一个主要特性是几乎所有地方都支持它。因此，您现在编写了一个程序来使用xml处理一些数据，10年后，当您需要彻底修改该程序并希望使用一个完全不同的平台时，您的xml数据仍将得到很好的支持。

如果您使用.NET（尤其是带有LINQ to XML的.NET 3.5）进行开发，那么与只使用纯文本文件相比，您将编写更少的代码来读取/写入XML。此外，XML只是让任何人都更容易阅读文件，并确切地知道文件中的内容和用途。而且，不要担心XML会占用更多的磁盘空间，磁盘空间很便宜。