JSON
此条目需要补充更多来源。 (2017年5月11日) |
JSON(JavaScript Object Notation, /ˈdʒeɪsən/, JavaScript物件表示法)是由美国程式设计师道格拉斯·克罗克福特构想和设计的一种轻量级资料交换格式。其内容由属性和值所组成,因此也有易于阅读和处理的优势。JSON是独立于程式语言的资料格式,其不仅是JavaScript的子集,也采用了C语言家族的习惯用法,目前也有许多程式语言都能够将其解析和字串化,其广泛使用的程度也使其成为通用的资料格式。
扩展名 |
.json |
---|---|
互联网媒体类型 |
application/json |
类型代码 | TEXT |
统一类型标识 | public.json |
格式类型 | 数据交换 |
扩展自 | JavaScript |
标准 | RFC 7159, ECMA-404 |
网站 | json |
简介
JSON格式是1999年《JavaScript Programming Language, Standard ECMA-262 3rd Edition》的子集合,所以可以在JavaScript以eval()
函式(javascript通过eval()调用解析器)读入。不过这并不代表JSON无法使用于其他语言,事实上几乎所有与网络开发相关的语言都有JSON函式库。
JSON的基本数据类型:
- 数值:十进制数,不能有前导0,可以为负数,可以有小数部分。还可以用
e
或者E
表示指数部分。不能包含非数,如NaN。不区分整数与浮点数。JavaScript用双精度浮点数表示所有数值(后来也支持 BigInt[1])。 - 字串:以双引号
""
括起来的零个或多个Unicode码位。支持反斜杠开始的转义字符序列。 - 布尔值:表示为
true
或者false
。 - 阵列:有序的零个或者多个值。每个值可以为任意类型。数组使用方括号
[]
包裹。多个数组元素之间用逗号,
分隔,形如:[value, value]
。 - 物件:若干无序的“键-值对”(key-value pairs),其中键只能是字符串[2]。建议但不强制要求对象中的键是独一无二的。对象以花括号
{}
包裹。多个键-值对之间使用逗号,
分隔。键与值之间用冒号:
分隔。 - 空值:值写为
null
token(6种标点符号、字符串、数值、3种字面量)之间可以存在有限的空白符并被忽略。四个特定字符被认为是空白符:空格符、水平制表符、回车符、换行符。空白符不能出现在token内部(但空格符可以出现在字符串内部)。JSON标准不允许有字节序掩码,不提供注释的句法。 一个有效的JSON文档的根节点必须是一个对象或一个数组。
JSON交换时必须编码为UTF-8。[3]转义序列可以为:“\\”、“\"”、“\/”、“\b”、“\f”、“\n”、“\r”、“\t”,或Unicode16进制转义字符序列(\u后面跟随4位16进制数字)。对于不在基本多文种平面上的码位,必须用UTF-16代理对(surrogate pair)表示,例如对于Emoji字符——喜极而泣的表情(U+1F602 😂 FACE WITH TEARS OF JOY)在JSON中应表示为:
{ "face": "😂" }
// or
{ "face": "\uD83D\uDE02" }
JSON的格式描述可以参考RFC 4627。
历史
JSON 源于对实时服务器到浏览器会话通信协议的需求,无需使用 Flash 或 Java 小程序等浏览器插件,这是 2000 年代初期使用的主要方法。
Crockford 首先指定并普及了 JSON 格式。这个缩写词起源于 State Software,这是一家由 Crockford 和其他人于 2001 年 3 月共同创立的公司。联合创始人同意构建一个使用标准浏览器功能的系统,并为 Web 开发人员提供一个抽象层来创建有状态的 Web 应用程序,该应用程序具有 通过保持两个超文本传输协议 (HTTP) 连接打开并在标准浏览器超时之前(如果没有进一步交换数据)回收这些连接,实现与 Web 服务器的持久双工连接。 联合创始人进行了讨论,并投票决定将数据格式命名为 JSML(JavaScript 标记语言)还是 JSON(JavaScript 对象表示法),以及在何种许可类型下提供该格式。 JSON.org 网站于 2001 年推出。
JSON 库的前身被用于Cartoon Network的 Communities.com 上名为“Cartoon Orbit”的儿童数字资产交易游戏项目(State 联合创始人之前都曾在这家公司工作过),该项目 使用具有专有消息格式的浏览器端插件来操作 DHTML 元素(该系统也属于 3DO)。 在发现早期的 Ajax 功能后,digiGroups、Noosh 等公司使用框架将信息传递到用户浏览器的视野中,而无需刷新 Web 应用程序的视觉上下文,仅使用标准 HTTP、HTML 和 JavaScript 功能即可实现实时丰富的 Web 应用程序 Netscape 4.0.5+ 和 IE 5+。 Crockford 随后发现 JavaScript 可以用作此类系统的基于对象的消息传递格式。 该系统被出售给 Sun Microsystems、Amazon.com 和 EDS。
应用领域
Metadata和架构
JSON文本的官方媒体类型是双引号,这一点在大多数现代的安装中都采用了这种类型。由于传统原因,许多服务提供商、浏览器、服务器、Web 应用程序、库、框架和API也支持非官方的 MIME 类型 或内容类型。值得注意的例子包括谷歌搜索API,雅虎,脸书的API,Lift,和Dojo Toolkit。JSON 架构指定一种基于 JSON 的格式,用于定义用于验证、文档和交互控制的 JSON 数据的结构。它为给定应用程序所需的 JSON 数据以及如何修改该数据提供协定。JSON架构基于XML架构(XSD)中的概念,但基于JSON。与在 XSD 中一样,相同的序列化/反序列化工具可用于架构和数据,并且它是自描述的。它在IETF的互联网草案中指定,目前为2020-12年草案,于2021年1月28日发布。有几个验证器可用于不同的编程语言,每个验证器都有不同程度的一致性。标准文件扩展名为 .json。JSON 标准不支持对象引用,但存在基于 JSON 的对象引用的 IETF 草案标准。
WEB开发
JSON最开始被广泛的应用于WEB应用的开发。不过目前JSON使用在JavaScript、Java、Node.js、C#应用的情况比较多,PHP等开发的WEB应用主要还是使用XML。
NoSQL数据库
相对于传统的关系型数据库,一些基于文档存储的NoSQL非关系型数据库选择JSON作为其数据存储格式,比较出名的产品有:MongoDB、CouchDB、RavenDB等。
举例
{
"firstName": "John",
"lastName": "Smith",
"sex": "male",
"age": 25,
"address":
{
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021"
},
"phoneNumber":
[
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}
这种JSON格式也被不少游戏(如Minecraft)或应用软体用来当作的部分数据存储的格式:
[
{
"text": "This is the text",
"color": "dark_red",
"bold": true,
"strikethough": true,
"clickEvent":
{
"action": "open_url",
"value": "zh.wikipedia.org"
},
"hoverEvent":
{
"action": "show_text",
"value":
{
"text": "something"
}
}
},
{
"translate": "item.dirt.name",
"color": "blue",
"bold": false,
"italic": true
}
]
互操作性
RFC 8259 (页面存档备份,存于互联网档案馆)描述了 JSON 语法的某些方面,尽管这些方面符合规范,但可能会导致互操作性问题。
- 某些 JSON 实现仅接受表示对象或数组的 JSON 文本。为了实现互操作性,交换 JSON 的应用程序应传输对象或数组形式的消息。
- 该规范允许 JSON 对象包含多个具有相同名称的成员。处理具有重复名称的对象的实现的行为是不可预测的。为了实现互操作性,应用程序在传输 JSON 对象时应避免重复名称。
- 规范特别指出 JSON 对象中成员的顺序并不重要。为了实现互操作性,应用程序应该避免为成员排序赋予含义,即使解析软件使该排序可见。
- 虽然规范对 JSON 数字文字的大小或精度没有限制,但广泛使用的 JavaScript 实现将它们存储为 IEEE754“binary64”数量。为了实现互操作性,应用程序应避免传输无法以这种方式表示的数字,例如 1E400 或 3.141592653589793238462643383279。
- 虽然规范不限制 JSON 文本中 Unicode 字符的字符编码,但绝大多数实现都采用UTF-8编码;为了实现互操作性,应用程序应始终且仅使用 UTF-8 对 JSON 消息进行编码。
- 该规范并不禁止传输不能正确表示 Unicode 字符的字节序列。为了实现互操作性,应用程序应传输不包含此类字节序列的消息。
- 该规范不限制应用程序如何比较 Unicode 字符串。为了实现互操作性,应用程序应始终逐个代码单元执行此类比较。
2015 年,IETF 发布了RFC7493 (页面存档备份,存于互联网档案馆),描述了“I-JSON 消息格式”,这是 JSON 的受限配置文件,它限制了 JSON 的语法和处理,以尽可能避免这些互操作性问题
安全问题
读取JSON
由于JSON是JavaScript的子集,所以一般都会使用eval()
作为读取资料的方式,如果是针对可靠的数据来源,在不支持原生JSON解析的浏览器上面这是最快速的方法。然而由于eval方法同样可以执行任意的JavaScript代码,因此当数据来源不可靠时则可能产生安全问题。如下面的例子,直接用eval执行时会跳转:
var json= eval("{message:(function (){ window.location='http://zh.wikipedia.org/wiki/JSON#.E5.AE.89.E5.85.A8.E6.80.A7.E5.95.8F.E9.A1.8C'; })()}");
其中一种防止不安全程式码出现的解决办法,是通过浏览器原生支持的JSON.parse(str)
方法读取JSON资料,目前已经得到大部分主流浏览器的支持(IE8+,Firefox 3.5+,Chrome4+/Safari4+,Opera10+),在不支持原生JSON对象的浏览器上面可以使用parseJSON
方法进行读取[4],parseJSON
采用解析器验证读入的程式码是否真的是JSON程式码,这样就更安全。但由于这是用模拟的方式读取,速度上会比eval()
慢。
跨站存取问题
另外一个安全上的问题则是跨站请求伪造(Cross-site request forgery,简称CSRF或XSRF)。这个问题在JavaScript中的状况是,由于JavaScript采用了称为“沙盒”的机制,这种机制限制JavaScript引擎仅能引入同一个站点的程式码,因而某种程度上提高了安全性。
与其他格式的比较
XML
JSON与XML最大的不同在于XML是一个完整的标记语言,而JSON不是。这使得XML在程式判读上需要比较多的功夫。主要的原因在于XML的设计理念与JSON不同。XML利用标记语言的特性提供了绝佳的延展性(如XPath),在数据存储,扩展及高级检索方面具备对JSON的优势,而JSON则由于比XML更加小巧,以及浏览器的内建快速解析支持,使得其更适用于网络数据传输领域。
YAML
在功能和语法上,JSON 都是 YAML 语言的一个子集。特别是,YAML 1.2规范指定“任何JSON格式的文件都是YAML格式的有效文件"。最常见的YAML解析器也能够处理JSON。版本 1.2 之前的 YAML 规范没有完全涵盖 JSON,主要是由于 YAML 中缺乏本机 UTF-32 支持,以及对逗号分隔空格的要求;此外,JSON 规范还包括 /* */ 样式的注释。YAML 最重要的区别是语法扩展集,它们在 JSON 中没有类似物:关系数据支持:在 YAML 文档中,可以引用以前在文件/流中找到的锚点;通过这种方式,您可以表达递归结构。支持除基元之外的可扩展数据类型,如字符串、数字、布尔值等。支持带缩进的块语法;它允许您在不使用不必要的符号的情况下描述结构化数据:各种括号、引号等。
MessagePack
MessagePack宣称比JSON更短小,快速。
格式化工具
JSON格式取代了XML给网络传输带来了很大的便利,但是却没有了XML的一目了然,尤其是JSON数据很长的时候,会让人陷入繁琐复杂的数据节点查找中。开发者可以通过在线JSON格式化工具,来更方便的对JSON数据进行节点查找和解析。
参考文献
- ^ BigInt - MDN Web Docs Glossary: Definitions of Web-related terms | MDN. developer.mozilla.org. 2023-06-08 [2023-06-12]. (原始内容存档于2023-02-03) (美国英语).
- ^ MDN-JSON标准. [2021-10-30]. (原始内容存档于2022-04-03).
- ^ The JavaScript Object Notation (JSON) Data Interchange Format. IETF. December 2017 [16 February 2018]. (原始内容存档于2021-01-20).
- ^ JSON and Browser Security. [2007-07-14]. (原始内容存档于2020-07-16).