JSON会取代XML成为一种数据格式吗?

When I first saw XML, I thought it was basically a representation of trees. Then I thought: the important thing isn't that it's a particularly good representation of trees, but that it is one that everyone agrees on. Just like ASCII. And once established, it's hard to displace due to network effects. The new alternative would have to be much better (maybe 10 times better) to displace it. Of course, ASCII has been (mostly) replaced by Unicode, for internationalization.

当我第一次看到XML时，我认为它基本上是树的表示。然后我想:重要的不是它是树的一个特别好的代表，而是每个人都同意的。就像ASCII。一旦建立起来，由于网络效应，它就很难被取代。为了取代它，新的替代方案必须更好(可能是原来的10倍)。当然，为了国际化，ASCII(大部分)已经被Unicode所取代。

According to google trends, XML has a x43 lead, but is declining - while JSON grows.

根据谷歌趋势，XML领先x43，但正在下降——而JSON在增长。

[edited] Will JSON replace XML as a data format?

JSON会取代XML成为一种数据格式吗?

1. for which tasks?
2. 哪些任务?
3. for which programmers/industries?
4. 的程序员/行业吗?

---

NOTES: S-expressions (from lisp) are another representation of trees, but which has not gained mainstream adoption. There are many, many other proposals, such as YAML and Protocol Buffers (for binary formats).

NOTES: s -表达式(来自lisp)是树的另一种表示形式，但是没有得到主流的采用。还有很多其他的提议，比如YAML和协议缓冲区(用于二进制格式)。

I can see JSON dominating the space of communicating with client-side AJAX (AJAJ?), and this possibly could back-spread into other systems transitively.

我可以看到JSON在与客户端AJAX (AJAJ?)通信的空间中占据着主导地位，这可能会间接地扩展到其他系统。

XML, being based on SGML, is better than JSON as a document format. I'm interested in XML as a data format.

基于SGML的XML比作为文档格式的JSON要好。我对XML作为一种数据格式感兴趣。

XML has an established ecosystem that JSON lacks, especially ways of defining formats (XML Schema) and transforming them (XSLT). XML also has many other standards, esp for web services - but their weight and complexity can arguably count against XML, and make people want a fresh start (similar to "web services" beginning as a fresh start over CORBA).

XML具有JSON所缺乏的已建立的生态系统，特别是定义格式(XML模式)和转换格式(XSLT)的方法。XML也有许多其他的标准，特别是web服务的标准——但是它们的重量和复杂性可能不利于XML，并使人们希望有一个新的开始(类似于“web服务”，从CORBA开始新的开始)。

[edited Mar2010] Like NoSQL, JSON is schemaless.

与NoSQL一样，JSON也是无模式的。

4 个解决方案

#1

I think JSON has already largely replaced XML for client-side communications with a web server, but that will likely be the extent of its dominance. As you stated, XML provides advantages that are appropriate for server-to-server interactions.

我认为JSON已经在很大程度上取代了使用web服务器进行客户端通信的XML，但这很可能是它的主导地位。如前所述，XML提供了适合于服务器到服务器交互的优势。

#2

Short answer: yes and no (EDITED as per comments below)

简短回答:是和否(以下评论编辑)

There are fundamental differences and trade-offs. XML is a markup language, particularly suitable for textual documents (xhtml, docbook, various kinds of office docs). And good enough for many other tasks. Problems mostly arise for it having hierarchic model (instead of, relational as in SQL, or object-graph as in oo languages).

存在根本的差异和权衡。XML是一种标记语言，特别适合文本文档(xhtml、docbook、各种office文档)。对于很多其他任务来说都足够好了。出现问题的主要原因是它具有层次模型(而不是SQL中的关系，或者对象图，比如oo语言)。

JSON is an object notation, meaning it has bit more natural fit for handling data-oriented use cases; cases where xml sort of works, but where there is more cost in overcoming impedance between object and hierarchic models. JSON is not a perfect fit -- it's still data, not objects (no identity, can't do full graphs) -- but it is more natural than XML. And as such, it is easier to build tools to do good decent and simple data binding.

JSON是一种对象表示法，这意味着它更适合处理面向数据的用例;在这种情况下，xml是可行的，但是在克服对象和层次模型之间的阻抗方面有更多的成本。JSON不是一个完美的选择——它仍然是数据，而不是对象(没有标识，不能做全图)——但它比XML更自然。因此，更容易构建工具来实现良好的、简单的数据绑定。

So: there's plenty room for both, and I would expect both to be used for long time to come. Not always in optimal way, but both can do plenty of use cases well enough.

所以:两者都有足够的空间，我希望两者都能长期使用。不总是最理想的方式，但是两者都可以做大量的用例。

For what it is worth, since writing my original answer, I have seen JSON absolutely annihilate XML for data-oriented/data-interchange use cases for companies I have worked for. SOAP (etc) will start significantly shrinking, and "plain old JSON" data interchange (esp. with RESTish frameworks, JAX-RS for Java for example) will take over.

因为写我最初的答案，我已经看到了JSON绝对是为我所工作的公司的面向数据/数据交换用例的XML。SOAP(等等)将开始显著收缩，“普通的*SON”数据交换(尤其是RESTish框架，比如Java的JAX-RS)将接管。

And yet XML is much better for textual markup.

然而，XML对于文本标记来说要好得多。

#3

My bold thesis is that such replacement is impossible after all, since these data-formats (JSON and XML) are different.

我大胆的论点是，这种替换毕竟是不可能的，因为这些数据格式(JSON和XML)是不同的。

Short version: XML is not equivalent to JSON (or similar) format since XML nodes (tags) support attribute notation and namespacing. It turns out to be crucial.

短版本:XML不等同于JSON(或类似的)格式，因为XML节点(标记)支持属性表示法和命名空间。这是至关重要的。

So, the best way to answer this question is actually to show how these formats are different, i.e. to complete the comparison. Forgive me for stating the obvious but I only hope this will be interesting or even useful. It will help if we first agree with simple terminology that:

所以，回答这个问题的最好方法是展示这些格式是如何不同的，即完成比较。请原谅我说的显而易见，但我只希望这将是有趣的，甚至是有用的。如果我们首先同意简单的术语:

1. Data-format is actually a formal language, which governs how data can be recognized (in its representation, i.e. how to "read/write" it from memory according to the way it is stored there).
2. data -format实际上是一种正式的语言，它控制如何识别数据(在其表示中，即如何根据数据存储的方式从内存中“读/写”数据)。
3. Data-structure is an abstract way of modeling (describing) how this data is organized or linked.
4. 数据结构是一种抽象的建模(描述)数据如何组织或链接的方法。

So, actually both concepts address different aspects of data maintenance (e.g. IO). For example, indexed array of a particular data-type is a (homogenues) structure and it can be accessed (read/written) as a serial sequence (contiguous format).

实际上，这两个概念都涉及到数据维护的不同方面(例如IO)。例如，一个特定数据类型的索引数组是一个(同质)结构，它可以作为一个串行序列(连续格式)访问(读/写)。

Wikipedia has a great article about JSON containing a lot of alternatives like (already named lisp's) S-Expressions, Python Nested Structures, PHP arrays, YAML, etc (note we are not considering dictionaries like .ini files since they lack multiple nesting). All these formats can be seen as representation of a certain data-structure - a tree. We can state that they are isomorphic in that sense. Each representation can be mapped to a tree in such manner that no extra processing should be done (e.g. grammar of a formal language is not changed). Also there exists a reverse mapping.

Wikipedia有一篇关于JSON的很棒的文章，其中包含了许多替代方法，比如(已经命名为lisp的)s表达式、Python嵌套结构、PHP数组、YAML等等(注意，我们不考虑像.ini文件这样的字典，因为它们缺少多个嵌套)。所有这些格式都可以看作是某种数据结构——树的表示。我们可以说它们是同构的。每个表示都可以映射到树，这样就不需要额外的处理(例如，正式语言的语法没有改变)。还有一个反向映射。

Well you may say that's "some" theory but what does it mean for practice? Implications are that if we compare XML and JSON by:

你可能会说这是“一些”理论但是它对实践意味着什么呢?如果我们比较XML和JSON的含义是:

• design purpose and motivation
• 设计目的和动机
• application domain - set of task a format is used to solve
• 应用程序域-用于解决任务a格式的一组任务
• syntactical complexity (well, simplicity - to which extend format is more readable/writable/human friendly/etc)
• 语法复杂性(嗯，简单——扩展格式更容易读/可写/对人友好等)
• maturity (like how many versions the format is around)
• 成熟度(比如格式有多少个版本)
• and so on
• 等等

we will discover further practical differences. Major of them all is that XML is a MARKUP language (as been mentioned). Yes, to do folding it is able to mix namespaces and attributes which results in a higher-order of "parallel" nesting.

我们会发现更多的实际差异。其中最主要的是XML是一种标记语言(如前所述)。是的，要折叠它，可以混合名称空间和属性，从而产生高阶的“并行”嵌套。

For the past two years I was busy transforming XML representation into python nested structures back and forth. To my only bitter conclusion they are very purely compatible. To represent attributes and namespacing one should escape (e.g. with prefixes) this information in the tree representation. So once again XML is definitely not a tree ;-) it immediately (without the need to encode, encapsulate or escape) allows representation of much more sophisticated structures than trees due to "markup" capabilities, i.e. typed trees. Trees with specialized types of vertexes (again by namespaces and attributes).

在过去的两年中，我一直忙于将XML表示转换为python嵌套结构。我唯一痛苦的结论是，它们完全相容。要表示属性和命名空间，应该在树表示中转义(例如用前缀)此信息。因此，XML绝对不是树;-)它立即(不需要编码、封装或转义)允许表示比树复杂得多的结构，因为有“标记”功能，例如类型化树。具有特定类型的vertexes的树(同样是通过名称空间和属性)。

There are other difficulties and dangers like parsing and mapping

还有其他困难和危险，如解析和映射

<body>The <strong>marked up</strong> text</body>

into a tree without some pre-decided convention (How to break "The .. text"?) or preserving order followed in XML.

在没有预先决定的约定的情况下(如何打破…或者保留XML中遵循的顺序。

Obviously things which are not equivalent are naturally having trouble to substitute each other. In that sense XML is more complex than nested structures.

很明显，不相等的东西自然很难互相替代。从这个意义上说，XML比嵌套结构更复杂。

The part of the question regarding industries seems pretty well answered by a prognoses that XML will stay server-side and document-oriented technology. Mainly because of its superior data-typing abilities. Also there have been done a lot of research motivated by XML solely as a markup language.

关于行业的部分问题似乎得到了一个很好的回答，即XML将保持服务器端和面向文档的技术。主要是因为它优越的数据类型能力。另外，也有很多研究是由XML作为标记语言来驱动的。

Excuse me for being far off the topic further, discussing the popularity of JSON but it seems partially relevant ;)

请原谅我离题太远了，讨论JSON的流行程度，但它似乎有部分相关性;)

I want to emphasize that JSON (being an object notation) completely fails to grasp any of the custom typing information (it enumerates the type without providing a "runtime"-reference or a context) by design (it is JavaScript), hence fails to pass highly-coupled objectified data. Type information will be always abstracted to JSON native types. This limits the abilities for type oriented development (type checking, constraining, casting, delegation, etc.). But IMHO this very crucial problem is shared with JSON by the most of modern programming languages (I know), which lack sophisticated nested custom data-typing as XML does (objects or functions are not documents). It seems that XML itself is doing this only by accident and not by design.

我想强调的是，JSON(作为对象表示法)完全无法通过设计(它是JavaScript)获取任何自定义类型信息(它在不提供“运行时”引用或上下文的情况下枚举类型)，因此无法传递高度耦合的目标数据。类型信息将总是抽象为JSON本机类型。这限制了面向类型开发的能力(类型检查、约束、铸造、委托等)。但是，IMHO这个非常关键的问题是由大多数现代编程语言(我知道)与JSON共享的，它们与XML一样缺乏复杂的嵌套自定义数据类型(对象或函数不是文档)。似乎XML本身只是出于偶然，而不是故意的。

As the result while working with JSON one applies similar tactics as by processing "duck"- typed data in popular dynamical languages. So this is another characteristics for JSON - allows fast coding but risks to get bulky when is growing too big (nested and complex).

因此，在处理JSON时，我们采用了类似的策略，比如用流行的动态语言处理“鸭子”类型的数据。因此，这是JSON的另一个特点——允许快速编码，但当代码变得太大(嵌套和复杂)时，可能会变得太大。

JSON is more of a swiss-knife than XML since it is simpler.

JSON更像是瑞士刀而不是XML，因为它更简单。

So, JSON does not help to interoperate with strongly-typed languages like Java but on the other hand it allows to lower the coupling by encouraging abstract decomposition. Since losing type information sometimes may be a good thing (reduction factor) it allows simpler architectures. ActionScript prefers to communicate de-facto in JSON (but they have also proposed own AMF). Finally, JSON works great with KISS (e.g. RESTful) designs. JSON buys with speed and simplicity. But what one usually tends to ignore is when KISS is impossible and domain logic is too complicated - designing DTDs and XSDs, thinking formats through and so on - is the work that should be done by someone (often later on when cool KISS approach failed because of lack of designing competence and experience). The point is JSON is a great tool which lacks application scale.

因此，JSON无助于与强类型语言(如Java)进行互操作，但另一方面，它允许通过鼓励抽象分解来降低耦合。由于有时丢失类型信息可能是一件好事(减少因素)，它允许更简单的体系结构。ActionScript更喜欢用JSON进行事实上的通信(但是他们也提出了自己的AMF)。最后，JSON适用于KISS(例如RESTful)设计。JSON以速度和简单性购买。但人们通常倾向于忽视当接吻是不可能和域逻辑太复杂,设计dtd和xsd、思维等等格式——是应该做的工作的人(通常是后来当酷吻方法失败是因为缺乏设计能力和经验)。关键是JSON是一个很好的工具，它缺乏应用程序的规模。

#4

Replace XML? Which XML?

取代XML呢?XML ?

There is "XML - the kind of data structuring" and "XML - the the textual representation of this structuring".

有“XML——这种数据结构”和“XML——这种结构的文本表示”。

So, while the textual representation of XML can be replaced by many means (JSON, YAML, ...), it would not replace the structural properties (there's a tree, elements with attributes, sub-elements and text nodes).

因此，虽然XML的文本表示可以被多种方式所替代(JSON、YAML、…)，但它不会取代结构属性(有一种树、带有属性、子元素和文本节点的元素)。

There are formats which store and/or process XML-structured data while neglecting the textual form. Examples:

有些格式存储和/或处理xml结构的数据，而忽略文本形式。例子:

1. DOM - stores an object tree in memory in an transformation-efficient form.
2. DOM -以转换效率的形式在内存中存储对象树。
3. EXI - future format to store/transmit XML data in binary-optimized form.
4. EXI -以二进制优化形式存储/传输XML数据的未来格式。

So, textual representation of XML can be "replaced" by transforming the standard XML notation to something else and back again. (XML to JSON, and back to XML)

因此，可以“替换”XML的文本表示形式，方法是将标准XML表示法转换为其他形式，然后再返回。(XML到JSON，再回到XML)

But, the structural properties and all technologies based on them, can not be "replaced", because this would just break all standards. So no one is doing this. There are just alternative textual representations being read to in-memory DOM or other formats, achieving a higher level of abstraction thus neglecting the underlying textual form.

但是，基于它们的结构特性和所有技术都不能被“取代”，因为这将打破所有的标准。所以没有人这么做。只有可选的文本表示被读到内存中的DOM或其他格式，从而实现更高层次的抽象，从而忽略了底层的文本形式。