XML的弱点是什么？ [关闭]

Question

阅读 StackOverflow 并收听 Joel Spolsky 和 ​​Jeff Atwood 的播客，我开始相信许多开发人员讨厌使用 XML，或者至少 尽量避免使用 XML 来存储或交换数据 .

另一方面，我很喜欢使用 XML 有几个原因：

• XML 序列化以大多数现代语言实现，并且非常易于使用，
• XML 序列化比二进制序列化慢，当涉及到使用来自多种编程语言的相同数据 或旨在阅读和理解（甚至用于调试）时，XML 序列化非常有用人类（例如，JSON 更难理解），
• XML支持unicode，使用得当，不同编码、字符等都没有问题。
• 有很多工具可以轻松处理 XML 数据。 XSLT 就是一个示例，它可以轻松呈现和转换数据。 XPath 是另一种，可以轻松搜索数据，
• XML可以存储在某些SQL服务器中，这使得数据过于复杂而无法轻松存储在SQL表中的场景必须进行保存和操作；例如，JSON 或二进制数据不能直接通过 SQL 进行操作（除了通过操作字符串，这在大多数情况下很疯狂），
• XML 不需要安装任何应用程序。如果我希望我的应用程序使用数据库，我必须先安装数据库服务器。如果我希望我的应用使用 XML，我不必安装任何东西，
• XML 比 Windows 注册表或 INI 文件等更明确且可扩展，
• 在大多数情况下，没有 CR-LF 问题，这要归功于 XML 提供的抽象级别。

那么，考虑到使用 XML 的所有好处，为什么这么多开发人员讨厌使用它？恕我直言，唯一的问题是：

• XML 过于冗长，并且比大多数其他形式的数据需要更多的空间，尤其是在 Base64 编码方面。

当然，在很多情况下 XML 根本不适合。将 SO 的问题和答案存储在服务器端的 XML 文件中是绝对错误的。或者，在存储 AVI 视频或一堆 JPG 图像时，最不适合使用 XML。

但是其他情况呢？ XML的弱点是什么？

---

致那些认为这个问题不是真正问题的人：

与非封闭式Significant new inventions in computing since 1980 之类的问题相反，我的问题是一个非常明确的问题，并且清楚地邀请解释其他人在使用 XML 时遇到的弱点以及他们为什么不喜欢它。它不邀请讨论，例如，XML 是好是坏。它也不需要扩展讨论；因此，目前收到的答案简短而准确，并提供了我想要的足够信息。

但是它是一个wiki，因为这个问题不可能有一个独特的很好的答案。

根据 SO，“不是真正的问题”是一个问题，“很难说出这里问的是什么。这个问题是模棱两可、含糊不清、不完整或修辞的，无法在目前的情况下得到合理的回答表格。”

• 这里要问什么：我觉得这个问题本身就很清楚了，上面几段文字就更清楚了，
• 这个问题是模棱两可的，模糊的，不完整的：再一次，没有什么是模棱两可的，既不模糊也不不完整，
• 或修辞：不是：我的问题的答案并不明显，
• 并且无法合理回答：已经有几个人对这个问题给出了很好的回答，表明这个问题可以得到合理的回答。

如何评价答案并确定接受的答案似乎也很明显。如果答案给出了 XML 问题的充分理由，那么这个答案很有可能会被投赞成票，然后被接受。

Answer 1

<xml>
    <noise>
        The
    </noise>
    <adjective>
        main
    </adjective>
    <noun>
        weakness
    </noun>
    <noise>
        of
    </noise>
    <subject>
        XML
    </subject>
    <noise>
        ,
    </noise>
    <whocares>
        in my opinion
    </whocares>
    <noise>
        ,
    </noise>
    <wildgeneralisation>
        is its verbosity
    </wildgeneralisation>
    <noise>
        .
    </noise>
</xml>

Answer 2

一些弱点：

• 将 xml 文件和外部资源关联起来有些困难，这就是为什么新的 Office 文档格式使用包含 xml 框架文件和捆绑在一起的资源文件的 zip 信封的原因。使用 base64 编码的另一种选择非常冗长，并且不允许良好的随机访问，这就引出了下一点：
• 随机访问很困难。两种读取 xml 文件的传统模式（构建 DOM 或只进 SAX 样式读取）都不允许真正的随机访问。
• 很难同时对文件的不同部分进行写访问，这就是为什么在 Windows 可执行清单中使用它很容易出错。
• xml 文件使用什么编码？严格来说，你先猜编码，然后读取文件并验证编码是否正确。
• 很难对文件的某些部分进行版本控制。因此，如果您想提供精细的版本控制，您需要拆分数据。这不仅仅是文件格式问题，还因为工具通常提供每个文件的语义——版本控制工具、DropBox 等同步工具等。

Answer 3

我不是问这个问题的合适人选，因为我自己是 xml 的忠实粉丝。不过，我可以告诉你我听到的主要抱怨之一：

很难合作。在这里，hard 意味着需要了解 API，并且您需要编写相对较多的代码来解析您的 xml。虽然我不会说这真的那么难，但我只能同意，当使用支持动态创建对象的语言时，可以更轻松地访问用于描述对象的语言。

Answer 4

我认为总的来说，这种反应仅仅是因为 XML 被过度使用了。

但是，如果有一个词是我讨厌的关于 XML 的热情，那就是名称空间。命名空间问题造成的生产力损失是可怕的。

Answer 5

XML 源自标记语言的曾祖父 SGML。 SGML 以及扩展的 XML 的目的是注释文本。 XML 在这方面做得很好，并且具有广泛的工具，可以增加其对各种应用程序的便利性。

在我看来，问题在于 XML 被频繁使用，不是用来注释文本，而是表示 结构化数据，这是一个微妙但重要的区别。实际上，出于各种原因，结构化数据需要简洁。性能是显而易见的，尤其是在带宽有限的情况下。这可能是 JSON 在 Web 应用程序中如此受欢迎的主要原因之一。网络上简洁的数据结构表示意味着更好的可扩展性。

不幸的是，如果没有额外的空白填充，JSON 的可读性就不是很好，这几乎总是被省略。另一方面，如果您曾尝试使用命令行编辑器编辑大型 XML 文件，那也可能会非常尴尬。

就我个人而言，我发现YAML 在这两个极端之间取得了很好的平衡。比较以下内容（从 yaml.org 复制，稍作改动）。

YAML：

invoice: 34843
  date: 2001-01-23
  billto: &id001
    given: Chris
    family: Dumars
    address:
      lines: |
        458 Walkman Dr.
        Suite #292
      city: Royal Oak
      state: MI
      postal: 48046
  shipto: *id001
  product:
  - sku: BL394D
    quantity: 4
    description: Basketball
    price: 450.00
  - sku: BL4438H
    quantity: 1
    description: Super Hoop
    price: 2392.00
  tax : 251.42
  total: 4443.52
  comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

XML：

<invoice>
   <number>34843</number>
   <date>2001-01-03</date>
   <billto id="id001">
      <given>Chris</given>
      <family>Dumars</family>
      <address>
        <lines>
          458 Walkman Dr.
          Suite #292
        </lines>
        <city>Royal Oak</city>
        <state>MI</state>
        <postal>48046</postal>
      </address>
   </billto>
   <shipto xref="id001" />
   <products>
      <product>
        <sku>BL394D</sku>
        <quantity>4</quantity>
        <description>Basketball</description>
        <price>450.00</price>
      </product>
      <product>
        <sku>BL4438</sku>
        <quantity>1</quantity>
        <description>Super Hoop</description>
        <price>2392.00</price>
      </product>
   </products>
   <tax>251.42</tax>
   <total>4443.52</total>
   <comments>
    Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338
   </comments>
</invoice>

它们都代表相同的数据，但 YAML 的大小缩小了 30% 以上，并且可以说更具可读性。您希望使用文本编辑器修改哪个？有许多库可用于解析和发出 YAML（即 Java 开发人员的蛇类）。

与所有事情一样，为正确的工作选择正确的工具是最好的规则。

Answer 6

我最喜欢的讨厌的问题是使用属性的 XML 序列化格式——比如 XAML。

这行得通：

<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>

这不是：

<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>

XAML 反序列化在从 XML 流中读取属性值时对其进行分配。所以在第二个例子中，当SelectedItem属性被赋值时，控件的ItemsSource还没有被设置，SelectedItem属性被赋值给一个尚知道存在的项。

如果您使用 Visual Studio 创建 XAML 文件，一切都会很酷，因为 Visual Studio 维护属性的顺序。但是在一些 XML 工具中修改你的 XAML，当它说属性的顺序并不重要时，它相信 XML 推荐，而且男孩你在一个受伤的世界里。