当我第一次看到XML时,我认为它基本上是树的表示.然后我想:重要的不是它是树木的特别好的代表,而是每个人都同意的.就像ASCII一样.一旦建立,由于网络效应,很难取代.取代它的新方案必须要好得多(可能好10倍).当然,为了国际化,ASCII(大部分)已被(大部分)取代为Unicode.
根据谷歌的趋势,XML有x43领先,但正在下降 - 而JSON增长.
[ 编辑 ]请问JSON会将XML替换为数据格式吗？
哪个任务？
哪些程序员/行业？
注意: S表达式(来自lisp)是树的另一种表示,但尚未获得主流采用.还有许多其他提议,例如YAML和Protocol Buffers(用于二进制格式).
我可以看到JSON主宰着与客户端AJAX(AJAJ？)进行通信的空间,这可能会传递回传播到其他系统.
基于SGML的XML比作为文档格式的 JSON更好.我对XML作为数据格式感兴趣.
XML具有JSON缺乏的已建立的生态系统,尤其是定义格式(XML Schema)和转换它们(XSLT)的方法.XML还有许多其他标准,特别是Web服务 - 但它们的重量和复杂性可以说是与XML相悖,并且让人们想要一个新的开始(类似于"Web服务"开始作为CORBA的新起点).
[2010年3月编辑 ]与NoSQL一样,JSON是无模式的.
简答:是和否(根据以下评论编辑)
存在根本的差异和权衡.XML是一种标记语言,特别适用于文本文档(xhtml,docbook,各种office文档).对于许多其他任务而言足够好.问题主要出现在它具有分层模型(而不是像SQL中的关系,或者像oo语言中的对象图).
JSON是一种对象表示法,意味着它更适合处理面向数据的用例; xml类型工作的情况,但是在克服对象和层次模型之间的阻抗方面需要更多成本.JSON不是一个完美的选择 - 它仍然是数据,而不是对象(没有身份,不能完整的图形) - 但它比XML更自然.因此,构建工具以进行良好的体面和简单的数据绑定更容易.
所以:两者都有足够的空间,我希望两者都可以使用很长时间.并不总是以最佳方式,但两者都可以充分利用大量用例.
值得一提的是,自从写完我原来的答案以来,我看到JSON绝对为我所工作过的公司的数据导向/数据交换用例歼灭了XML.SOAP(etc)将开始显着缩小,"普通的旧JSON"数据交换(例如,使用RESTish框架,例如Java的JAX-RS)将接管.
然而,XML对于文本标记来说要好得多.
我的大胆论点是,毕竟这种替换是不可能的,因为这些数据格式(JSON和XML)是不同的.
简短版本:XML不等同于JSON(或类似)格式,因为XML节点(标记)支持属性表示法和命名空间.事实证明这是至关重要的.
因此,回答这个问题的最佳方法实际上是展示这些格式是如何不同的,即完成比较.原谅我陈述显而易见但我只希望这会有趣甚至有用.如果我们首先同意简单的术语,它将有所帮助:
数据格式实际上是一种形式语言,它控制着如何识别数据(在其表示中,即如何根据存储在那里的方式从存储器中"读/写"它).
数据结构是一种建模(描述)数据如何组织或链接的抽象方式.
因此,实际上这两个概念都涉及数据维护的不同方面(例如IO).例如,特定数据类型的索引数组是(同质)结构,并且可以作为串行序列(连续格式)访问(读/写).
维基百科有一篇关于JSON的好文章,其中包含许多替代方案,如(已命名为lisp的)S-Expressions,Python嵌套结构,PHP数组,YAML等(请注意,我们不会考虑像.ini文件这样的字典,因为它们缺少多个嵌套).所有这些格式都可以看作是某种数据结构的表示 - 树.我们可以说它们在这个意义上是同构的.可以以不应该进行额外处理的方式将每个表示映射到树(例如,不改变正式语言的语法).还存在反向映射.
那么你可以说这是"一些"理论但它对实践意味着什么呢？这意味着如果我们通过以下方式比较XML和JSON:
设计目的和动力
应用程序域 - 用于解决格式的任务集
语法复杂性(嗯,简单 - 扩展格式更易读/可写/人性化/等)
成熟度(就像格式有多少个版本一样)
等等
我们将发现进一步的实际差异.其中主要的是XML是MARKUP语言(如上所述).是的,要进行折叠,它可以混合名称空间和属性,从而产生更高级别的"并行"嵌套.
在过去的两年里,我忙于将XML表示转换为python嵌套结构.对我唯一的痛苦结论,他们非常纯粹兼容.为了表示属性和命名空间,应该在树表示中转义(例如,使用前缀)此信息.因此,XML绝对不是树;-)它立即(不需要编码,封装或转义)允许表示比树更复杂的结构,因为"标记"功能,即类型树.具有特殊类型顶点的树(同样由名称空间和属性).
还有其他困难和危险,如解析和映射
The marked up text
没有一些预先确定的约定(如何打破"The .. text"？)或保留XML中的顺序.
显然,不相等的东西自然难以互相替代.从这个意义上讲,XML比嵌套结构更复杂.
关于行业问题的部分似乎很好地回答了XML将保留服务器端和面向文档的技术的预测.主要是因为其出色的数据打字能力.此外,还有很多研究由XML作为标记语言进行.
请原谅我远离主题,讨论JSON的受欢迎程度,但似乎部分相关;)
我想强调JSON(作为对象表示法)完全无法掌握任何自定义类型信息(它枚举类型而不提供"运行时"参考或上下文)的设计(它是JavaScript),因此无法通过高度耦合的客观化数据.类型信息将始终抽象为JSON本机类型.这限制了面向类型开发的能力(类型检查,约束,转换,委托等).但恕我直言这个非常关键的问题是由大多数现代编程语言(我知道)与JSON共享的,它缺乏像XML那样复杂的嵌套自定义数据类型(对象或函数不是文档).似乎XML本身只是偶然而非设计.
因此,在使用JSON时,应用类似的策略,就像处理流行动态语言中的"duck"类型数据一样.所以这是JSON的另一个特性 - 允许快速编码,但是当增长过大(嵌套和复杂)时风险会变得笨重.
JSON比XML更像是瑞士刀,因为它更简单.
因此,JSON无助于与Java等强类型语言进行互操作,但另一方面,它允许通过鼓励抽象分解来降低耦合.由于丢失类型信息有时可能是一件好事(缩减因子),因此它允许更简单的架构.ActionScript更喜欢在JSON中进行事实上的通信(但他们也提出了自己的AMF).最后,JSON适用于KISS(例如RESTful)设计.JSON以快速和简单的方式购买.但人们通常倾向于忽视的是KISS是不可能的,域逻辑太复杂 - 设计DTD和XSD,思考格式等等 - 是应该由某人完成的工作(通常在以后很酷的KISS方法失败时缺乏设计能力和经验).关键是JSON是一个缺乏应用规模的好工具.
我认为JSON已经在很大程度上取代了XML,用于与Web服务器进行客户端通信,但这很可能是它的主导地位.如您所述,XML提供了适合服务器到服务器交互的优势.
京公网安备 11010802040832号 | 京ICP备19059560号-6 