我们可以完全用JSON替换XML吗？[关闭]

78

我确信很多开发人员都熟悉XML和JSON，并且他们都使用了它们。因此，即使是简短的解释，也没有必要解释它们的含义和目的。

如果我们尝试映射他们的概念，我们可以说（如果我错了，请纠正我）：

  1. XML标签等同于JSON {}
  2. XML属性等效于JSON属性
  3. XML标记集合等效于JSON []

我唯一想到的是XML命名空间，它在JSON中不存在。

问题是，考虑到此映射，并考虑到JSON在此映射中要轻得多，我们能否在没有XML的情况下看到未来的世界（或者至少从理论上讲是一个世界），但是使用JSON可以完成XML的所有工作？我们可以在所有使用XML的地方使用JSON吗？

PS：请注意，我已经看到了这个问题。这和我在这里要问的完全不同。因此，请不要提及重复。

xml  json 
— 赛义德·纳马蒂（Saeed Neamati）
source
14
显然，我们可以（并且应该）用S表达式替换所有那些过分设计错误的东西。的确，没有XML的世界确实会好得多，但是不幸的是，这只是一厢情愿的想法。
— SK-logic
19
啊。我讨厌这些问题。我认为这确实是为工作使用正确工具的情况，而不是一个人是否可以完全替换另一个人。即使使用计算机，世界上也没有那么多的绝对事物。我无法想象使用JSON做任何事情，至少在现在的各个技术都如此。
— 菲利普·里根
2
@Philip，这不是拆卸东西的问题。它只是试图查看JSON缺少什么，以便我们可以对其进行改进。:)
— Saeed Neamati 2011年
4
讨论两种技术之间的差异以了解可在何处进行改进，与询问是否可以用另一种替代非常不同。前者比后者更具学术性，后者听起来比挫折更令人
— Philip Regan
12
这不是假设。JSON似乎缺少XML具备的功能。
— S.Lott

Answers:

153

赋予XML功能和很多复杂性的是混合内容。像这样的东西：

<p>A <b>fine</b> mess we're in!</p>

甚至不要尝试使用JSON进行操作，也不要尝试使用常规的编程语言对其进行操作。他们不是为这份工作而设计的。

这类问题通常来自忘记了XML中的M代表标记的人们。这是获取纯文本并添加标记以创建结构化文本的方法。它对于老式数据也非常方便，但这不是它的设计目的或主要优势所在。处理简单数据的方法有很多，JSON是其中一种。

— 迈克尔·凯
source
33
+1：这是与众不同的功能。优点。
— S.Lott
7
@Michael，您刚刚教给我一些有价值的东西。这是一个很好的答案。+1。
— Saeed Neamati 2011年
9
....有3个节点，分别是P，A B元素和“我们所在的地方！”。这是一个数组，您可以简单地用JSON进行解释。
— 隐身
5
@Rob不，但是我在解释，您可以更清晰地定义HTML表示的内容，并且可以通过JSON更快地进行解析（因为查找不同类型的节点需要较少的文本解析）。如果HTML是JSON-ML，我们可能会有更多的开发人员真正了解DOM，文本节点和绑定。
— 隐身
5
@ByrneReese：是的，它是XML，是有效的。也是HTML无关紧要；实际上，XHTML也是有效的XML。:-)
— Martijn
31

我认为，主要的区别在于XML被设计成可以用其dtd和所有内容进行自我解释。

使用JSON，您必须假设有关接收到的数据很多。

— 马丁·鲁昂（Maarten van Leunen）
source
7
“ XML被设计为不言自明的”。您可以为此提供链接或参考吗？我没有在XML的W3C标准中看到它，我想知道这个概念从何而来。我似乎更像是一个城市传奇，而不是既定的设计目标。
— S.Lott
6
@ S.Lott：我想他的意思是XML标记的本质本身允许标记的内容不言自明，即DTD是可选的，因此格式良好的XML可以不用一个就进行解析。但是，我同意您对此问题的看法，因为从技术上讲，JSON具有相同的功能，所以我完全不认为自我解释是主要区别（我不确定为什么会继续投票赞成），而是迈克尔·凯（Michael Kay）更有成就感。
— 菲利普·里根
5
@ S.Lott同意。我不得不在这里说JSON。json.org/example.html比相关的XML更容易理解和更好地自我记录，因为它缺乏冗长性。
— Doug T.
4
@Michael Borgwardt：没有完整的XSD（包括某种本体支持），标签名称什么也没告诉我。通常，“有意义的”很难实现。这使我不清楚答案中“自我解释”的含义。而且我没有证据表明这甚至是XML的设计目标。
— S.Lott
4
@Philip Regan：与“自解释代码”一样，它似乎不是XML 的功能。如果这只是适用于所有软件语言（代码，数据访问，标记等）的通用实现目标，那么也许人们不应该特别提及XML。
— S.Lott
21

文字转换为JSON通常不太简洁，也不太清楚。考虑：

<foo>
   <x:bar x:prop1="g">
      <quuz />
   </bar>
</foo>

我见过的最有效的JSON表示形式：

{"localName":"foo",
 "children": // you need to have a special array to hold all children
 [
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 
        "attributes":[
            {"localName":"prop1",
             "namespace":"x",
             "value":"g"}
        ],
         "children":[
             {"name":"quux"}
         ]
     }
 ]}

现在，想象一下整个XML文件。我并不是说JSON没有它的位置，但是不应该排除XML。

— Cwallenpoole
source
8
现在考虑SXML：(foo (x:bar (@ (x:prop1 "g")) (quuz)))
— SK-logic
2
@ SK-Logic：对于一个简单的例子来说，这很好，但是我无法想象用它来完成深度嵌套的混合内容（如书）。我认为SXML和其他任何东西一样都是学术活动。
— 菲利普·里根
3
@Philip Regan：当将人字形变的琐碎的1：1转换成不太冗长的形式时，如何比使用人字形炎更难写S-Exp？
— maaartinus 2011年
@maartinus：我的专长是图书出版：任何种类的教科书都是深奥的，复杂的野兽，内容丰富，需要明确的管理。DocBook和DITA比上面给出的示例更具可读性。
— 菲利普·里根
1
@Philip Regan，SXML非常易于编辑，与XML完全不同。当然，对于协议来说，这是一个更好的选择，不用说可用工具的优越性。
— SK-logic
14

JSON和XML都是格式化数据的方式。两者都能很好地做到这一点，那么JSON可以做XML所做的一切吗？是。

但是.....一个更相关的问题可能不是XML / JSON可以做什么，而是可以使用 XML / JSON 做什么。

有几件事情你可以做的与 XML，我不认为你可以使用JSON，如用XLST转换，使用XPath搜索，并用模式验证。都非常非常有用。

— Qwerky
source
5
数据包含标签的混合内容除外。JSON根本无法做到这一点。
— S.Lott
11

使用XSLT的功能很多，而JSON可能无法实现。因此，如果它们在功能上不等效，则无法相互替代。

— StuperUser
source
3
也就是说，您可以使用另一种语言对JSON进行反序列化，操作和序列化，而XSLT不是XML，因此这一点确实没有意义。
— StuperUser 2011年
3
XSLT 是 XML-在此处
— -treecoder
谢谢@greengit，我只简要介绍了一下，更新了答案。
— StuperUser 2011年
2
@StuperUser：JSON 怎么可能“不可能”？这只是一个转变，也许工具还没有。还是与JSON中缺少属性有关的问题？
— maaartinus 2011年
1
@StuperUser：XSLT是一种语言（XML的子集），某些解释器至少以另一种语言（可能是C，Java等）编写。可以对JSON执行相同的操作（定义一些JSON-T，编写解释器），不是吗？
— maaartinus 2011年
8

事实是，我们将不得不忍受很长一段时间，而成为JSON顽固者“被认为是有害的”。

— 斯科特·威尔逊
source
7

JSON是相当新的，遗留系统将不支持它。升级旧系统非常耗时，并且会引入一些错误。JSON不会在不久的将来替换XML。

— 汤姆·斯奎斯
source
2
感谢您的回复。我想到的是技术审查，而不是实施策略。我只是想知道，例如，对于那些旧系统的新版本，我们可以完全放弃XML并使用JSON吗？如果不是，我们在JSON中会错过什么？
— Saeed Neamati 2011年
另一方面，最近几年我没有使用任何XML，仅使用JSON。并且很好的摆脱。当然，XML更为实用。这对工作安全性很重要，而对效率却不太重要。
— gnasher729
6

我想说cwallenpoole是一个很好的观点。尽管大多数XML 都可以转换为JSON，但这样做是否更好是一个单独的问题。

JSON至少与XML一样适用于数据结构，并且可能更好，但在标记文本文档时XML比JSON更自然地读取，其中标记在较大的文本流中使用，而不是简单地作为划分层次结构的方式领域。

尽管HTML 5可能具有自己的解析器，但仍然留下诸如DocBook之类的应用程序。

— 索科洛
source
JSON显然可以包含可以包含HTML的字符串。
— gnasher729
6

它取决于域。在网络服务方面？绝对。供应商仍在向其客户推销SOAP，这简直可耻。一直使用REST + JSON。

现在，当您在谈论带有样式信息（例如Docbook或其他实现）的复杂的结构化数据时？这是XML的适当领域。

— 杰森·刘易斯
source
4

当YAML是一个超集并且比XML或JSON具有更强的表达性和功能，那么为什么将自己限制为JSON。

就是说，如果使用正确的序列化框架，则应该能够使用几行简单的代码对所有上述格式进行序列化和反序列化。

3

当您尝试在JSON中为这两个对象建模时，它变得很丑陋：

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

使用JSON的方式（在99％的情况下，通常会因为以下原因而迷路）：

{ name: "John Doe" }

现在，您必须添加一些元结构，而JSON的所有优点就荡然无存了。

— 米哈尔·蒂尔（Michal Till）
source
11
与您提供的XML等效的JSON是{ customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }。因此，从技术上讲，您的答案不正确。:)
— Saeed Neamati 2011年
当然，JSON唯一缺少的是属性，并且建模对象没有用（与标记不同）。有时，属性被用作可以使用嵌套数据（例如，在Hibernate配置文件中）表示的内容的快捷方式，这很方便，但实际上选择的存在使它变得更难。配置文件和建模对象是JSON明显优越的两个地方。
— maaartinus 2011年
2
@SaeedNeamati，那么您将如何<customer><name>John Doe</name></customer><customer><name>John Doe</name></customer>在JSON中建模？
— svick 2011年
6
{客户：[{名称：'John Doe'}，{名称：'John Doe'}]}}？
— scrwtp
2
@Stijn-正确，并且可行，但是它证实了原始答案的评论，即“您必须添加一些元结构”以对某些在XML中自然发生的事情进行建模。
— Matt R
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.