Question

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

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

XML序列化以大多数现代语言实现，非常易于使用，
比二进制序列化要慢，XML序列化在使用来自多种编程语言的相同数据或者打算阅读和理解的地方非常有用，即使对于调试，也是如此。人类（例如，JSON，更难以理解），
XML支持 unicode ，如果使用得当，不同的编码，字符等都没有问题。
有很多工具可以轻松使用XML数据。 XSLT 就是一个例子，可以轻松呈现和转换数据。 XPath 是另一个，可以轻松搜索数据，
XML可以存储在某些SQL服务器中，这样就可以保存和操作太复杂而无法轻松存储在SQL表中的数据。例如，JSON或二进制数据不能通过SQL直接操作（除非通过操作字符串，这在大多数情况下都很疯狂），
XML不需要安装任何应用程序。如果我希望我的应用程序使用数据库，我必须首先安装数据库服务器。如果我希望我的应用使用XML，我不需要安装任何东西，
XML比例如Windows注册表或INI文件显式和可扩展更多
在大多数情况下，由于XML提供的抽象级别，没有CR-LF问题。

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

XML过于冗长，并且比大多数其他形式的数据需要更多的地方，特别是在涉及Base64编码时。

当然，有很多情况下XML根本不适合。在服务器端的XML文件中存储SO的问题和答案将是绝对错误的。或者，当存储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的粉丝。但是，我可以告诉你一个我听过的主要抱怨：

很难使用。在这里，硬意味着它需要知道一个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开发人员的snakeyaml）。

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

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推荐，而男孩你是在一个受伤的世界。

XML有哪些缺点？

6 个答案: