XML的弱点是什么？ [关闭

StackOverflow https://stackoverflow.com/questions/3580819

题

阅读Joel Spolsky和Jeff Atwood的Stackoverflow并聆听播客，我开始相信许多开发人员讨厌使用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根本不适合。将问题和答案存储在XML文件中 在服务器端 绝对是错误的。或者，当存储AVI视频或一堆JPG图像时，XML是最糟糕的事情。

但是其他场景呢？ XML的弱点是什么？

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

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

但 这是一个Wiki，因为没有 独特 这个问题的好答案。

根据这样，“不是真正的问题”是一个问题 “很难说出这里的要求。这个问题是模棱两可，模糊，不完整或修辞的，无法以当前形式合理地回答。”

  • 这里问什么: ：我认为问题本身非常清楚，上面的几段文本使它变得更加清晰，
  • 这个问题是模棱两可，含糊，不完整的: ：同样，没有什么歧义，既不含糊也不完整，
  • 或修辞: ：不是：我问题的答案不是明显的，
  • 并且不能合理地回答: ：几个人已经对这个问题给出了很好的答案，表明该问题可以合理地回答。

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

有帮助吗？

解决方案

一些弱点：

  • 将XML文件和外部资源关联起来有些困难，这就是为什么新的Office文档格式使用包含骨架XML文件和捆绑在一起的资源文件的ZIP信封的原因。使用base64编码的另一个选项是非常详细的，不允许随机访问，这使一个要点是：
  • 随机访问很困难。读取XML文件的两种传统模式都没有 - 构造DOM或仅向前的SAX样式阅读允许真正的随机访问。
  • 同时写对文件不同部分的写入访问很困难，这就是为什么它在Windows可执行清单中使用的原因是错误的。
  • XML文件使用什么编码？严格来说，您首先猜测编码，然后读取文件并验证编码正确。
  • 很难版本的文件部分。因此，如果您想提供颗粒状版本，则需要拆分数据。这不仅是文件格式问题，而且还因为工具通常提供每文件的语义 - 版本控制工具，诸如Dropbox之类的同步工具等。

其他提示

<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>

我不是合适的人，因为我本人是XML的忠实拥护者。但是，我可以告诉您我听到的主要投诉之一：

这是 难的 跟...共事。在这里，硬意味着要知道API，并且您需要编写相对较大的代码来解析XML。虽然我不会说这确实很难，但我只能同意，当使用支持动态创建对象的语言时，可以更轻松地访问一种描述对象的语言。

我认为总体而言，这种反应仅仅是因为XML被过度使用。

但是，如果我讨厌XML的一个词，那么激情就是名称空间。围绕名称空间问题的生产力损失是可怕的。

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）。

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

我最喜欢的讨厌问题是使用XML属性的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建议的属性订购并不重要，而男孩是您受伤的世界。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top