Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

XML 和 JSON

Posted on 01/25/201510/08/2024 by 四火

json 不久前看到一个讨论帖,说的是 XML 和 JSON 的比较,说着说着后来就变成了 JSON 到底比 XML 牛逼在哪里。不吹不黑,客观地来比较一下二者的异同。

XML 比 JSON 更胖吗?

有的情况下是的,但也不一定,比较这样的片段:

<user age="18">
    <address>
        <city name="Seattle" />
    </address>
</user>

和

{"user" : {
    "age" : 18,
    "address" : {
        city : {
            name : "Seattle"
        }
    }
}}

二者信息量几乎均等,XML 看起来并不显得多么冗余。有恰当的编辑器,二者都可以有比较美观的缩进表达。

当然,也有很多情况我们可以看到 XML 要比 JSON 啰嗦(有人说 JSON 是 fat-free alternative to XML),比如 XML 写这样的东西:

<employees>
    <employee>
        <address value="..."/>
    </employee>
    <employee>
        <address value="..."/>
    </employee>
    <employee>
        <address value="..."/>
    </employee>
<employees>

如果 employees 和 employee 这节点名字名字本身不重要的话,写成 JSON 就简单多了:

[{address:"..."}, {address:"..."}, {address:"..."}]

JSON 的表达直观在哪里?

继续就着上面的例子看:

XML 格式下,我无法得知 age 其实是一个数字,因为 XML 里面你无法进一步区分简单数据类型;但是 JSON 就不是了,18 是数字,”18″ 是字符串;true 是布尔真,”true” 是字符串;null 是空,”null” 是字符串。

如果要表达数组呢?XML 中可以在父节点下面累放节点,而 JSON 则有 [ ] 这样更直观的方式。

如果字符串中有换行符怎么办,JSON 不存在这个问题,而 XML 必须引入 CDATA 解决问题,比如:

<script>
<![CDATA[
function matchwo(a,b)
{
if (a < b && a < 0) then
  {
  return 1;
  }
else
  {
  return 0;
  }
}
]]>
</script>

XML 也有优势

比如 XML 可以有声明(declaration):

<?xml version='1.0' encoding='character encoding' standalone='yes|no'?>

规定了编码格式等等信息,但是 JSON 就没有这样的东西。

当上面的 standalone 为 yes 的时候表示 DTD 直接写到这个 XML 里面去,这样,就不需要额外的 DTD 文件了,也就是说,这个文件不但是自解释,还是自校验的了。而这一点,JSON 是不可能做到的。

另外,XML 还可以有命名空间,可以通过 xmlns 属性引入不同的定义文件,像编程语言的 import 来自由组合,这一点,JSON 也是做不到的:

<h:table xmlns:h="http://www.w3.org/TR/html4/">
   <h:tr>
   <h:td>Apples</h:td>
   <h:td>Bananas</h:td>
   </h:tr>
</h:table>

另外,在偶然出现格式错误的时候,由于起始和结束标签对应的关系,XML 的校验会比 JSON 更容易发现 “错在哪里”,换言之,修复的可能性更大。

和对象之间的互相转化

JSON 的一大好处是有些语言可以原生支持,比如 JavaScript,不需要一个 JSON Parser 这样的东西,代码里表示对象用的就是 JSON 格式的表达。但是直接支持 XML 的编程语言,好像没有吧,倒是有像 HTML 等等标记语言的解析器,可以处理任意 DOM 对象。

如果要把 JSON 转成对象,在支持 JSON 对象的浏览器中可以写:

var obj = JSON.parse(text);

如果不支持,则可以这样做:

var obj = eval ("(" + text + ")");

如果是反过来,要把对象表达成 JSON 表达式呢?

JSON.stringify(obj);

这些都是原生的支持,如果是 XML,要和对象之间互相转换,则要麻烦得多,需要借助第三方类库。支持注解的表达会让代码清晰很多,把 XML 这种声明式的表达,变成另一种类定义声明式的表达,比如这个例子:

<StepList>
  <Step>
    <Name>Name1</Name>
    <Desc>Desc1</Desc>
  </Step>
  <Step>
    <Name>Name2</Name>
    <Desc>Desc2</Desc>
  </Step>
</StepList>

带有注解的类定义声明式表达:

[XmlRoot("StepList")]
public class StepList
{
    [XmlElement("Step")]
    public List<Step> Steps { get; set; }
}

public class Step
{
    [XmlElement("Name")]
    public string Name { get; set; }
    [XmlElement("Desc")]
    public string Desc { get; set; }
}

对于 XML 和 JSON 之间的互相转化,除了类库,还有一些在线的工具,用起来很方便,比如这个。

XML DTD 和 JSON Schema

DTD 指的是 Document Type Definition,用于定义 XML 文件的节点属性格式和含义,比如这样的 DTD 文件:

<!DOCTYPE NEWSPAPER [

<!ELEMENT NEWSPAPER (ARTICLE+)>
<!ELEMENT ARTICLE (HEADLINE,BYLINE,LEAD,BODY,NOTES)>
<!ELEMENT HEADLINE (#PCDATA)>
<!ELEMENT BYLINE (#PCDATA)>
<!ELEMENT LEAD (#PCDATA)>
<!ELEMENT BODY (#PCDATA)>
<!ELEMENT NOTES (#PCDATA)> 

<!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED>
<!ATTLIST ARTICLE EDITOR CDATA #IMPLIED>
<!ATTLIST ARTICLE DATE CDATA #IMPLIED>
<!ATTLIST ARTICLE EDITION CDATA #IMPLIED>

]>

XML 除了 DTD 本身,还有一个真正的 schema,叫做 XML Schema,它本身也是 XML。其实,XML Schema 是针对 DTD 无法解决问题而发明的进化版本,可以定义数据类型,包括集合类型,可以指定顺序,元素出现次数,支持命名空间,以及定义缺省值等等。另外,哪怕就从这一点上看,XML 的功能性上确实要比 JSON 更强大:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="note">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="to" type="xs:string"/>
      <xs:element name="from" type="xs:string"/>
      <xs:element name="heading" type="xs:string"/>
      <xs:element name="body" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

</xs:schema>

相应地,JSON 也有类似的东西,叫做 JSON Schema,它本身也是 JSON。比如这个例子:

{
	"title": "Example Schema",
	"type": "object",
	"properties": {
		"firstName": {
			"type": "string"
		},
		"lastName": {
			"type": "string"
		},
		"age": {
			"description": "Age in years",
			"type": "integer",
			"minimum": 0
		}
	},
	"required": ["firstName", "lastName"]
}

从 XPath 到 JSONPath

我们经常需要一种表达式来访问整个 XML 中间的某个节点或者属性,XPath 就是这样的表达式,比如下面这个 XPath 表达式就是 XPath 维基百科页上面 XPath 标题的节点:

//*[@id="firstHeading"]/span

为什么很少提及 JSON 数据的 path?主要原因是因为一旦有了语言原生支持,我们就不自觉地使用了,比如 JavaScript 中使用对象的某一个属性一样自然。但是,无论如何,一个 path 的表达式还是不可替代的,除了各色的开源项目,还有一个叫做 JSON Pointer 的规范,虽然没能得到足够多的赞成票;也有人拟了一个 JSONPath 的东西,这个看起来就完备得多了:

XPathAndJSONPath

还有其它的替代品吗?

有。比如 YAML,表意更加丰富,还省掉了很多格式化的符号,比如 JSON 的引号和 XML 的标签记号。YAML 官网的介绍,记录了它和 JSON 以及 XML 之间的比较:

JSON’s foremost design goal is simplicity and universality. In contrast, YAML’s foremost design goals are human readability and support for serializing arbitrary native data structures. Thus, YAML allows for extremely readable files, but is more complex to generate and parse.

YAML is primarily a data serialization language. XML was designed to support structured documentation. XML therefore had many design constraints placed on it that YAML does not share.

看看下面的例子,不得不说,就清晰简洁为上的可读性上而言,YAML 是三者中最好的:

---
receipt:     Oz-Ware Purchase Invoice
date:        2007-08-06
customer:
    given:   Dorothy
    family:  Gale
   
items:
    - part_no:   A4786
      descrip:   Water Bucket (Filled)
      price:     1.47
      quantity:  4

    - part_no:   E1628
      descrip:   High Heeled "Ruby" Slippers 
      price:     100.27
      quantity:  1

bill-to:  &id001
    street: | 
            123 Tornado Alley
            Suite 16
    city:   East Westville
    state:  KS

ship-to:  *id001   

specialDelivery:  >
    Follow the Yellow Brick
    Road to the Emerald City.
    Pay no attention to the 
    man behind the curtain.
...

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 过多 if-else 分支的优化
  2. 动手实现随机验证码
  3. 泛型趣谈
  4. 学习 OpenAPI 的一点记录
  5. 对象转换的问题

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme