如果XML太糟糕了……为什么会有那么多人使用它？[关闭]

我了解XML的目的，但是我总是听到人们抱怨它的错误程度如何？我真的不明白这有什么不好的吗？我通常会听到“ blo肿”和“慢速”这两个词。

但是我想作为程序员，您主要将其用于什么？而且您真的认为它“不好”吗？...因为确实如此，所以很多人都用它来传输数据...

Xml非常适合其设计初衷-平台中立的，人类可读的数据传输协议，具有一些功能，可以在较低级别上强制执行数据验证。我怀疑以这种方式使用Xml的人是否会有真正的抱怨。它是最简洁的线格式吗？不，但是还有更糟糕的选择。它和读取自定义二进制格式一样快吗？不会。但是您的业务合作伙伴可以使用任何堆栈读取它。

然而，问题在于人类-尤其是被称为企业建筑师的人-是邪恶的，会接受好东西并使他们变得不好。以Xml为例，在本世纪初，Xml被视为解决每个IT问题的通用工具。通过委员会进行一些小的设计，最终会导致一些可怕的怪事，例如SOAP和oXML。敌人，没关系的朋友或同事都不希望这样做。

XML只是具有多种口味和用途的工具。XML在某些方面很擅长，而另一些方面则很烂。我认为问题之一是，人们已经看到“企业” XML不必要地复杂化了名称空间和乱七八糟的东西（SOAP，有人吗？）。为人类设计XML格式的诀窍是为数据添加真实含义，同时又不至于使它们难以阅读。

人们所质疑的一件事是，XML有时会在某些字符或某些缺少的括号中引起阻塞。但是，这既有上行也有下行。好处是，您不会像使用HTML那样具有歧义性，在HTML中，对半无效语法的不同情况可以有不同的解释。

缺点是，编写和学习起来有点困难。我同意有一个论点是，如果HTML像XML一样严格，那么网络就不会发展得如此之快，但是我也认为如果今天这样做我们会感到高兴。:)

另外，不要仅仅因为可以，有理智和判断力适当地使用它就将它用于所有事情。如果您拥有的只是XML，那么您往往总是远离所需的XSLT转换。:)

我认为格式仅在人类需要与之交互时才真正重要。如果您正在编写一些序列化某些程序并将其发送到另一个程序要使用的程序的地方，那么谁会在乎它的外观，只要它尽可能高效即可？对于我所关心的全部使用二进制格式或兔子和独角兽。

XML的优点

• 涵盖了很多YAML和JSON不具备的优势
• 有出色的工具可以解析和验证各种不同平台和语言的XML
• XML可以轻松强大地转换为另一种格式（通过XSLT之类的东西）
• 合理的XML文档对于人类来说很容易阅读和编辑。不要告诉我JSON更容易，不是:)
• XML在某种程度上是自我描述的，即，它直接包含有关其结构和含义的信息（与大多数二进制格式相反）
• 处理编码
• 与空白无关，这使得跨平台使用更加容易
• 如果格式不正确则中断（确保数据在结构上正确）
• 不是SGML

缺点

• 详细
• 解析速度不如二进制文件快
• 如果格式不正确则中断（破坏您的应用程序）

很好的用途

• 配置文件
• 数据交换格式
• 版本弹性文件格式
• 将文档存储在数据库中

不太好用

• 数据传输格式
• 序列化对象
• 在数据库中存储关系数据
• 高性能I / O方案的文件格式

Jeff Atwood在XML上有一篇非常不错的博客文章：如果您想让消息来源谈论这个问题，可以用Angle Bracket Tax来解决。

我最常用的用途是：

• 服务互相交谈。例如，使用内容管理系统的网站必须将一些数据发送到客户关系管理系统中，而这是通过XML完成的。

• 配置存储。Web.config和app.config是常见示例，但是nAnt脚本也可以对它们使用一些XML。

我认为这不是最佳选择，但仅此一项就不会令我感到失望。

两个原因：

1. 那里有很多糟糕的程序员。XML可能很糟糕，但是它也很简单（至少从表面上看），并且使编写不好的软件非常容易。有点像VB。
2. 做出这些决定的很多人都不是程序员，而是只听说过“每个人都在使用XML”的业务类型，因此他们决定也希望他们的产品也使用XML。

我通常会听到“ blo肿”和“慢速”这两个词。

它不是最紧凑的语法，但显然是最富表现力的一种。可读吗？取决于您如何设计语言。大多数人没有为XML设计语言，他们只是将对象序列化为XML。

…为什么有那么多人使用它？

无处不在。您可以使用XQuery查询XML数据库，使用XSLT转换为XHTML或Atom，从其他Web服务获取Atom或其他XML格式，使用XForms从用户获取XML，使用XMLSchema，Relax NG或Schematron对其进行验证，然后使用XProc，使用XQuery Update将其保存回数据库。所有这些工具都了解XML，因此无需在不同表示形式之间进行映射。

XML不是序列化技术，它是一种通用信息集。

在这里，我们将其用于不同供应商制造的具有不同内部表示形式的不同系统之间的数据交换。我们建立了一个XML转换/交换系统来来回传送数据。为此很好。

XML并不是天生就坏，但是我承认使用XML设计“好的”解决方案并非易事。

“ XML的本质是这样的：它解决的问题并不难，而且不能很好地解决问题。” -Phil Wadler，2003年POPL

我个人的观点是，只要您不关心验证，模式，XSLT和其他丑陋的东西，并且将文件的大小保持在很小的范围内（否则解析就变慢了），您可以找到XML的一些良好用法（例如用于配置您的应用程序，而不使用INI文件）。

以我的经验，人们大多抱怨它的使用方式，而不是技术本身。

人们抱怨的and肿且缓慢的位通常是用于从中获取信息的库/方法。

我用它来存储少量结构化信息，这些信息要存储在磁盘上（没有数据库或二进制序列化），或者传递给另一个应用程序（本质上也描述SOAP）。

其优点是：

它是多个异构系统可以用来与之通信的标准“接口”。并且是“人类”可读的（有点，请尝试凝视5 MB XML）

不好的原因是：

其肿，更大的大小=更多的带宽=更多的$$

还有其他原因，每个人都有不同的感受...

像其他任何技术一样：有许多可用的工具和库。

我不喜欢XML，特别是因为它很时髦，当人们说它是人类可读的时，我认为他们是在开玩笑，或者当人们试图将xml嵌入属性时他们从未真正阅读过xml ... xml实体使其真正成为了现实。无法读取。此外，令人惊讶的是，由于冗余的末端标签以及混合自由文本和数据的能力，浪费了多少空间。

但：

• 可以指定Xml（xsd），并且可以使用工具检查Xml数据的一致性
• 许多工具（文本编辑器等）都支持Xml
• 许多库（关于每种编程语言）都支持Xml

在大多数情况下，它也具有优先级的优势。当您已经在Xml中提供了Web服务，并且要求提供一项新服务时...可能会在Xml中完成，因为这就是您所知道的。

对于必须由人类维护的文件，XML是一个糟糕的选择。标记和内容之间没有视觉上的分隔，使其难以阅读。在没有专用编辑器的情况下正确编写非常繁琐。XML文档中的任何错误都是致命的。XML文档不能被部分处理。当XML文件无效时，产生的错误消息通常无济于事。

对于必须由人类维护的任何文件，我更喜欢使用JSON，YAML或某种解释语言（Python，Ruby，Groovy等）的源代码中的任何一种。我们发现，为遗留代码创建XML配置的一种好方法是使用Groovy MarkupBuilder。另一个不错的选择是创建特定领域的语言。使用Ruby，Groovy和许多其他语言很容易做到这一点。

解析相对容易，同时又易于阅读。

并且一些不错的解析器（例如Xerces {c ++}）也很容易获得。