我的需求只是从数据库中检索出一组值并在表格上显示它们。我正在使用jQuery。
19个回答
152
在以下情况下使用XML而不是JSON：
- 您需要消息验证
- 您正在使用XSLT
- 您的消息包括大量标记文本
- 您需要与不支持JSON的环境进行互操作
在以下所有情况都成立时，请使用JSON而不是XML：
- 消息不需要验证，或验证其反序列化很简单
- 您没有转换消息，或者转换其反序列化很简单
- 您的消息主要是数据，而不是标记文本
- 消息端点具有良好的JSON工具
- Robert Rossney
5
9在处理标记文本方面，JSON与XML相比没有任何优势。但我理解你的观点，也许说得有些夸张了。 - Robert Rossney
11当所有条件相等时，有两个原因倾向于选择JSON：JSON比XML更易于解析（对CPU友好），并且需要传输的数据量更少（对网络友好）。 - Roger Barreto
你什么时候会使用XSLT而不使用XML呢？如果你已经在使用XSLT，那么XML就是必须的。这并不应该成为使用XML的论据。这就像说如果你正在使用JSON.parse()，那么就使用JSON一样。此外，我认为转换JSON对象比编写XSLT转换更容易，但这可能是我的个人偏见。 - Spencer
我不完全同意JSON中的验证部分。JSON也是可验证的。请查看这个IETF草案：链接。虽然它只是一个草案，但仍然值得一看。 - yakya
@sotn 你没有像XML（例如XQuery）那样的PL/SQL用于JSON。这是一些NoSQL数据库（如eXist、MarkLogic Server、EMC Documentum xDB、BaseX、Zorba）的基础。 - Dmytro Melnychuk
82
除非必须使用XML，否则我会使用JSON。JSON更易于理解，并且（由于需要更少的配置开销）如果在您的上下文中可用库，则读写编程更容易。现在这些库相当普遍。
当亚马逊首次将其目录作为Web服务公开时，他们提供了JSON和XML两种格式。大约90％的实现者选择了JSON。
- doofledorfer
3
60“除非必须使用XML，否则我会使用JSON。” ～ 没错。 - EndangeredMassa
3更深层次的问题是，“为什么需要使用XML？” 这些原因是愚蠢的吗？还是只是从与您不同的观点和不同的关注点反映出来的？ - 13ren
6有几个可能的原因，包括我不想重写现有的软件。但最重要的是在我不能控制两端或需要使用正式标准且要求使用 XML 作为数据交换格式的情况下。如果只有我一个开发者，我可以任意选择。 - dkretz
15
考虑到你已经在客户端上使用JavaScript的具体情况，我会选择JSON，原因如下：
由于JSON是JavaScript本地支持的格式，因此在客户端编写代码时可以写更少的代码-只需
eval()（或者最好用JSON.parse()）JSON字符串，然后获取可用的对象。同时，在客户端上评估JSON将更有效率，因此更快。
与XML相比，JSON序列化会产生更短的字符串。使用JSON将减少通过网络传输的数据量，并从这方面提高性能。
这里有一些进一步阅读的材料：http://www.subbu.org/blog/2006/08/json-vs-xml
- urig
4
8使用
eval() 处理 JSON 是一个大忌，这个操作需要被改变。 - shoosh@Shy，JSON 的官方网站上说可以在 JSON 上使用 eval（用括号括起来）：http://www.json.org/js.html - strager
10摘自json.org: eval函数非常快。然而，它可以编译和执行任何JavaScript程序，因此可能存在安全问题。只有在源是可信且能力强时才建议使用eval。使用JSON解析器会更安全。 - sarego
3建议使用 JSON.parse() 替代 eval() 函数。 - Havvy
14
我在XML和JSON领域遇到的一些其他事情：
JSON非常适用于
- 名称/值对
- 嵌套这些对
这意味着它倾向于使用数组或嵌套数组。 然而，JSON缺少以下两个内容：
- 属性
- 命名空间
因此，如果您要组合两个或更多JSON服务，则可能会出现命名空间冲突。 话虽如此，根据我的经验，当交换数据时，JSON可以用于大约与XML相同的90％的事情。
- null
3
另一个Json的问题在于，您不能轻松地合并两个json消息以创建一个新的json消息。它通常不会格式良好。 - vtd-xml-author
7你需要属性是用来干什么的？如果你的元素包含其他值，就把它变成一个对象——成员就是你的“属性”。说实话，我认为XML的这种双分属性/容器结构完全是有害的。 - foo
我认为 JSON 没有属性是一种特性。 - brian
11
通常JSON更加紧凑，解析速度更快。
如果满足以下条件之一，请优先选择XML：
- 您需要在客户端上处理数据，并且可以利用XSL来完成这项工作。对于大块数据，XML + XSL链往往比JSON + JavaScript链更快。
- 其中一个好的用例是将数据转换为HTML片段。
- 各种遗留情况：
- 已经存在一个XML服务，由于某些原因使用JSON进行重写将会很麻烦。
- 在使用用户输入进行轻量级处理后，必须将此数据作为XML返回。
（几乎）等同于XML的一个重要用例：尝试检测何时发送HTML片段比发送原始数据更有利。 在简单的应用中，AHAH可以发挥奇妙的作用，但经常被忽视。通常，此样式假定服务器发送的HTML片段将被内联在网页中而无需处理。
通常，在AHAH情况下，CSS被充分利用以在视觉上操纵片段，并使用用户特定或应用程序特定设置实现简单的条件语句，例如隐藏/显示片段的相关部分。
- Eugene Lazutkin
9
在处理数据时，使用JSON格式始终比XML更可取，因为客户端浏览器需要进行的解析工作更少。此外，JSON是一种轻量级数据交换格式。
XML解析会占用大量浏览器资源，除非必要，否则应尽可能避免使用。
- Tejasvi
7
JSON易于解析，速度更快。XML解析稍微困难一些，解析和传输速度较慢（在大多数情况下）。
由于您正在使用jQuery，建议使用JSON：jQuery可以检索JSON数据并自动将其转换为Javascript对象。实际上，您可以 使用eval将JSON数据转换为Javascript对象。XML必须由您手动遍历（我不知道在Javascript中如何工作，但在我使用XML库的大多数语言中，这是困难/更烦人的）。
- strager
4
1JSON 的定义是 JavaScript 对象，jQuery 并没有做任何特殊的“转换”。只是想澄清一下。 - Brian Gianforcaro
5除非在JavaScript中实例化，否则JSON并不是JavaScript对象。它恰好遵循用于序列化JavaScript对象的格式，但可以通过大多数语言访问（使用适当的插件和内置函数），至少与XML一样容易。 - dkretz
@Gianforcaro，我明白了。我会编辑我的帖子，更清楚地表达这一点。@doofledorfer，我说的是“将其转换为JavaScript对象。”我并没有说JSON数据是一个JavaScript对象。 - strager
啊，抱歉，没听清楚。 - strager
7
我有一篇关于Web协议历史的博客文章（例如SOAP，XML，JSON，REST，POX等），其中提供了每种协议的摘要以及一些优缺点。您可以通过以下链接查看：http://www.servicestack.net/mythz_blog/?p=154
实际上，我认为通过比较动态（JSON）和静态（XML）语言之间的差异，可以发现XML和JSON之间存在许多相似之处。
基本上，XML是一种更严格、更严谨的序列化格式，可以选择使用附带的模式（XSD或DTD）进行验证。 XSD非常复杂，允许您描述许多不同类型，例如日期、时间、枚举、用户定义的类型甚至类型继承等。 SOAP有效地建立在XML特性集之上，通过WSDL提供了一种标准化的方式来描述您的Web服务（例如类型和操作）。 WSDL规范的冗长和复杂意味着它可能更加乏味，但同时有更多的工具可用于您，并且大多数现代语言都提供自动化工具来生成客户端代理，从而在尝试与外部服务进行交互时减轻了一些负担。（虽然与此同时，我发现生成的代理本身是处理经常更改的Web服务时的负担）。
JSON与XML在许多方面完全相反，它是非常松散类型的，并且只支持基本类型：数字、布尔值、字符串、对象和数组。其他所有内容本质上都必须适合一个字符串。当尝试跨语言边界进行通信时，这并不好，因为如果您想支持更具体的类型，则需要遵守一些非标准规范。但好的方面是，它有限的功能集非常适合大多数语言 - 并且非常适合JavaScript，因为JSON字符串可以直接转换为JavaScript对象。
大小和性能 我有一些Northwind数据库基准测试数据，比较了微软XML和JSON实现之间的大小和速度。基本上，XML的大小是JSON的两倍以上，但同时看起来微软在优化他们的XML DataContractSerializer方面花费了很多精力，因为它比他们的JSON快30%以上。似乎你必须在大小和性能之间做出权衡。不满足于这个事实，我决定编写自己快速的JsonSerializer，现在它比微软的XML更快2.6倍 - 所以两全其美 :)。
基本上，XML是一种更严格、更严谨的序列化格式，可以选择使用附带的模式（XSD或DTD）进行验证。 XSD非常复杂，允许您描述许多不同类型，例如日期、时间、枚举、用户定义的类型甚至类型继承等。 SOAP有效地建立在XML特性集之上，通过WSDL提供了一种标准化的方式来描述您的Web服务（例如类型和操作）。 WSDL规范的冗长和复杂意味着它可能更加乏味，但同时有更多的工具可用于您，并且大多数现代语言都提供自动化工具来生成客户端代理，从而在尝试与外部服务进行交互时减轻了一些负担。（虽然与此同时，我发现生成的代理本身是处理经常更改的Web服务时的负担）。
如果您有一个明确定义的“企业服务”或您的Web服务需要从许多不同的语言中访问，我仍然建议您使用XML作为您的Web服务。
尽管XML有许多好处，但也存在缺点。它依赖于命名空间以提供一种类型化的可扩展格式，并使您能够在同一文档中指定属性和元素。在一个文档中具有不同的命名空间意味着当使用Xml解析器提取数据时，大部分时间您还需要提供要检索/遍历的每个元素的命名空间。它还推断出有效载荷，使其比必须的更冗长。选择输出属性以及元素意味着您的类无法很好地映射到XML文档。这些特性使其在大多数语言中都不适合作为编程工具，使其更加繁琐和笨重。微软已经在他们的DataContract序列化程序中认识到并简化了这一点，通过取消XML属性，只将您的类的属性映射到Xml元素。JSON与XML在许多方面完全相反，它是非常松散类型的，并且只支持基本类型：数字、布尔值、字符串、对象和数组。其他所有内容本质上都必须适合一个字符串。当尝试跨语言边界进行通信时，这并不好，因为如果您想支持更具体的类型，则需要遵守一些非标准规范。但好的方面是，它有限的功能集非常适合大多数语言 - 并且非常适合JavaScript，因为JSON字符串可以直接转换为JavaScript对象。
大小和性能 我有一些Northwind数据库基准测试数据，比较了微软XML和JSON实现之间的大小和速度。基本上，XML的大小是JSON的两倍以上，但同时看起来微软在优化他们的XML DataContractSerializer方面花费了很多精力，因为它比他们的JSON快30%以上。似乎你必须在大小和性能之间做出权衡。不满足于这个事实，我决定编写自己快速的JsonSerializer，现在它比微软的XML更快2.6倍 - 所以两全其美 :)。
- mythz
6
如果我需要验证传入数据的块，我会选择XML而不是JSON，因为XML通过XSD天然支持此功能。
- lowglider
3
当您选择JSON路线时，您会遇到XML在10年前面临的相同问题：
将来自两个不同来源的数据混合到一个JSON数据包中可能会导致元素标签相互冲突。如果搞错了装箱单和发票，那么“From”地址可能意味着完全不同的东西。这就是为什么XML有命名空间。
在不同的JSON结构之间进行转换需要编写单调乏味的代码。更声明性的数据映射方式可以使工作变得更加容易。这就是为什么XML有XSLT。
描述JSON数据包的结构-其字段、数据类型等-对于人们连接到您的服务非常必要。因此，必须拥有元数据语言。这就是为什么XML有模式。
同时进行两个客户端-服务器对话需要小心处理。如果您向服务器提出两个问题并得到一个答案，那么您如何知道它回答了哪个问题？这就是为什么XML有WS-Correlation。
- Özgür
1
2命名空间只是另一种解决方法；如果您想要，您可以在JSON中完全相同。 WS-Correlation也是作为XML的事后添加而添加的，并不是“内置”的。您也可以将其添加到JSON中。结构描述（模式）并不特殊于XML；自eBNF发明以来，您可以以多种方式对任何形式语言进行描述。 XSLT是一个有效的卖点。 - foo
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接