5

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

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

  • XML 序列化是用大多数现代语言实现的，并且非常易于使用，
  • XML 序列化比二进制序列化要慢，当涉及到使用来自多种编程语言的相同数据或打算由人类阅读和理解（甚至用于调试）的情况下（例如，JSON 更难）时，XML 序列化非常有用了解），
  • 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的弱点是什么？

对于那些认为这个问题不是一个真正的问题的人：

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

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

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

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

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

4

6 回答 6

6 
<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>
于 2010-08-27T02:26:12.770 回答
5

一些弱点：

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

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

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

于 2010-08-27T02:03:20.680 回答
1

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

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

于 2010-08-27T02:16:13.093 回答
1

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 开发人员的蛇形代码）。

与所有事情一样，正确工作的正确工具是遵循的最佳规则。

于 2010-08-27T17:23:29.877 回答
0

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

这有效：

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

这不会：

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

XAML 反序列化在从 XML 流中读取属性值时对其进行分配。因此，在第二个示例中，分配属性时，尚未设置SelectedItem控件，并且将属性分配给尚未知道存在的项。ItemsSourceSelectedItem

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

于 2010-08-27T22:19:32.713 回答