[RFC 首页] [文本|PDF|HTML] [跟踪器] [IPR] [勘误] [信息页]
互联网
标准
存在勘误
互联网工程任务组 (IETF) T. Bray，编辑
征求意见稿：8259 Textuality
废止：7159 2017 年 12 月
类别：标准跟踪
ISSN: 2070-1721
JavaScript 对象表示法（JSON）数据交换格式
摘要
JavaScript 对象表示法（JSON）是一种轻量级、基于文本且
与语言无关的数据交换格式。它源自
ECMAScript 编程语言标准。JSON 定义了一小组
格式化规则，用于结构化数据的可移植表示。
本文档消除了与其他 JSON 规范之间的不一致，
修正了规范错误，并提供了基于实践经验的
互操作性指导。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组
（IETF）的产物。它代表了 IETF 社区的共识。它已经
接受公开审查，并经互联网工程指导组（IESG）
批准发布。有关互联网标准的更多信息，
请参阅 RFC 7841 第 2 节。
有关本文档的当前状态、任何勘误，
以及如何提供反馈的信息，可在
https://www.rfc-editor.org/info/rfc8259 获取。
Bray 标准跟踪 [第 1 页]
RFC 8259 JSON 2017 年 12 月
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Bray 标准跟踪 [第 2 页]
RFC 8259 JSON 2017 年 12 月
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 本文档中使用的约定 . . . . . . . . . . . . 4
1.2. JSON 规范 . . . . . . . . . . . . . . . . . 4
1.3. 本次修订简介 . . . . . . . . . . . . . . . 5
2. JSON 语法 . . . . . . . . . . . . . . . . . . . . 5
3. 值 . . . . . . . . . . . . . . . . . . . . . . . . 6
4. 对象 . . . . . . . . . . . . . . . . . . . . . . . 6
5. 数组 . . . . . . . . . . . . . . . . . . . . . . . 7
6. 数字 . . . . . . . . . . . . . . . . . . . . . . . 7
7. 字符串 . . . . . . . . . . . . . . . . . . . . . . 8
8. 字符串和字符问题 . . . . . . . . . . . . . . . . 9
8.1. 字符编码 . . . . . . . . . . . . . . . . . . 9
8.2. Unicode 字符 . . . . . . . . . . . . . . . . 10
8.3. 字符串比较 . . . . . . . . . . . . . . . . . 10
9. 解析器 . . . . . . . . . . . . . . . . . . . . . . 10
10. 生成器 . . . . . . . . . . . . . . . . . . . . . 10
11. IANA 注意事项 . . . . . . . . . . . . . . . . . . 11
12. 安全注意事项 . . . . . . . . . . . . . . . . . . . 12
13. 示例 . . . . . . . . . . . . . . . . . . . . . . . 12
14. 参考文献 . . . . . . . . . . . . . . . . . . . . . 14
14.1. 规范性参考文献 . . . . . . . . . . . . . . . 14
14.2. 资料性参考文献 . . . . . . . . . . . . . . . 14
附录 A. 与 RFC 7159 相比的变更 . . . . . . . . . . . . . . . 16
贡献者 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . 16
1. 引言
JavaScript 对象表示法（JSON）是一种用于
序列化结构化数据的文本格式。它源自 JavaScript 的对象
字面量，如 ECMAScript 编程语言
标准第三版 [ECMA-262] 中所定义。
JSON 可以表示四种基本类型（字符串、数字、布尔值和
null）以及两种结构化类型（对象和数组）。
字符串是由零个或多个 Unicode 字符组成的序列 [UNICODE]。
请注意，此引用指向 Unicode 的最新版本，
而不是某个特定版本。预计 Unicode 规范未来的
变更不会影响 JSON 的语法。
对象是由零个或多个名称/值
对组成的无序集合，其中名称是字符串，而值可以是字符串、数字、
布尔值、null、对象或数组。
数组是由零个或多个值组成的有序序列。
Bray 标准跟踪 [第 3 页]
RFC 8259 JSON 2017 年 12 月
“object”和“array”这两个术语来自
JavaScript 的惯例。
JSON 的设计目标是使其保持精简、可移植、基于文本，并且
是 JavaScript 的一个子集。
1.1. 本文档中使用的约定
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、
"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和
"OPTIONAL"，当且仅当它们像这里所示以全大写形式出现时，
应按照 BCP
14 [RFC2119] [RFC8174] 中的描述进行解释。
本文档中的语法规则应按照
[RFC5234] 中的描述进行解释。
1.2. JSON 规范
本文档取代 [RFC7159]。[RFC7159] 废止了 [RFC4627]，
后者最初描述了 JSON 并注册了媒体类型
"application/json"。
[ECMA-404] 也描述了 JSON。
上一句中对 ECMA-404 的引用是规范性的，但并不是
通常意义上的，即实现者需要查阅它才能
理解本文档；而是为了强调，在任何
JSON 规范中对术语 "JSON text" 的定义都不存在
不一致。不过请注意，ECMA-404 允许若干
做法，而本规范为了实现最大程度的互操作性，
建议避免这些做法。
其意图是两份文档中的语法相同，
尽管使用了不同的描述方式。如果发现二者之间
存在差异，ECMA 和 IETF 将共同更新
两份文档。
如果任一文档中发现错误，则应
检查另一份文档是否存在类似错误；如果存在，则应
尽可能修复。
如果未来任一文档发生变更，ECMA 和 IETF 将
共同确保两份文档在整个
变更过程中保持一致。
Bray 标准跟踪 [第 4 页]
RFC 8259 JSON 2017 年 12 月
1.3. 本次修订简介
自 RFC 4627 发布以来的这些年里，JSON 得到了非常
广泛的使用。这些经验揭示了某些模式，虽然
其规范允许这些模式，但它们会造成互操作性问题。
此外，关于 RFC 4627 已报告了少量勘误
（参见 RFC 勘误 ID 607 [Err607] 和 3607 [Err3607]），关于
RFC 7159 也已报告勘误（参见 RFC 勘误 ID 3915 [Err3915]、4264 [Err4264]、4336
[Err4336] 和 4388 [Err4388]）。
本文档的目标是应用这些勘误、消除
与其他 JSON 规范之间的不一致，并强调可能
导致互操作性问题的做法。
2. JSON 语法
JSON 文本是一个记号序列。记号集合包括六个
结构字符、字符串、数字以及三个字面量名称。
JSON 文本是一个序列化后的值。请注意，此前的某些
JSON 规范将 JSON 文本限制为对象或
数组。在需要 JSON 文本的地方仅生成对象或数组的
实现具有互操作性，也就是说，所有
实现都会接受它们作为符合要求的 JSON 文本。
JSON-text = ws value ws
以下是六个结构字符：
begin-array = ws %x5B ws ; [ 左方括号
begin-object = ws %x7B ws ; { 左花括号
end-array = ws %x5D ws ; ] 右方括号
end-object = ws %x7D ws ; } 右花括号
name-separator = ws %x3A ws ; : 冒号
value-separator = ws %x2C ws ; , 逗号
Bray 标准跟踪 [第 5 页]
RFC 8259 JSON 2017 年 12 月
六个结构字符中的任何一个之前或之后都允许出现
无关紧要的空白。
ws = *(
%x20 / ; 空格
%x09 / ; 水平制表符
%x0A / ; 换行符或新行
%x0D ) ; 回车符
3. 值
JSON 值 MUST 是对象、数组、数字或字符串，或者是
以下三个字面量名称之一：
false
null
true
字面量名称 MUST 使用小写形式。不允许使用其他
字面量名称。
value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
true = %x74.72.75.65 ; true
4. 对象
对象结构表示为一对花括号，
其中包围零个或多个名称/值对（或成员）。名称是
字符串。每个名称之后紧跟一个冒号，用于将名称
与值分隔开。单个逗号将一个值与后续
名称分隔开。对象中的名称 SHOULD 是唯一的。
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
名称全部唯一的对象具有互操作性，也就是说，
接收该对象的所有软件实现都会对
名称-值映射达成一致。当对象中的名称
不唯一时，接收此类对象的软件的行为
不可预测。许多实现只报告最后一个名称/值对。
其他实现会报告错误或无法解析该
Bray 标准跟踪 [第 6 页]
RFC 8259 JSON 2017 年 12 月
对象，还有一些实现会报告所有名称/值对，
包括重复项。
已观察到不同 JSON 解析库在是否
向调用软件暴露对象成员顺序方面存在差异。
行为不依赖成员顺序的实现具有
互操作性，也就是说，它们不会受到这些
差异的影响。
5. 数组
数组结构表示为一对方括号，其中包围零个
或多个值（或元素）。元素之间用逗号分隔。
array = begin-array [ value *( value-separator value ) ] end-array
并不要求数组中的值属于相同的
类型。
6. 数字
数字的表示方式与大多数
编程语言中使用的方式类似。数字使用
十进制数字以基数 10 表示。它包含一个整数部分，
其前面可以有一个可选的负号，后面可以跟
小数部分和/或指数部分。不允许
前导零。
小数部分是一个小数点，后跟一个或多个数字。
指数部分以大写或小写字母 E 开头，
后面可以跟加号或减号。E 和可选的
符号之后跟一个或多个数字。
不允许使用无法由以下语法表示的数值（例如
Infinity 和 NaN）。
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
Bray 标准跟踪 [第 7 页]
RFC 8259 JSON 2017 年 12 月
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
plus = %x2B ; +
zero = %x30 ; 0
本规范允许实现对所接受数字的范围
和精度设置限制。由于实现
IEEE 754 binary64（双精度）数字 [IEEE754] 的软件通常
可用且被广泛使用，因此，如果实现所期望的
精度或范围不超过这种表示方式所提供的能力，就可以实现良好的
互操作性，也就是说，实现将能在预期精度内近似表示 JSON
数字。诸如 1E400
或 3.141592653589793238462643383279 这样的 JSON 数字可能表明存在潜在的
互操作性问题，因为它暗示创建该数字的软件
期望接收方软件在数值大小和精度方面具有
超出普遍可用水平的能力。
请注意，使用此类软件时，属于整数并且
位于 [-(2**53)+1, (2**53)-1] 范围内的数字具有互操作性，
也就是说，实现会对其数值
完全一致。
7. 字符串
字符串的表示方式类似于 C
语言家族中使用的惯例。字符串以
引号开始并以引号结束。除 MUST 转义的字符之外，
所有 Unicode 字符都可以放在引号中：
引号、反斜线以及控制字符（U+0000
至 U+001F）。
任何字符都可以被转义。如果字符位于基本
多文种平面（U+0000 至 U+FFFF）中，则可以
表示为一个六字符序列：一个反斜线，后跟
小写字母 u，再后跟四个用于
编码该字符码点的十六进制数字。十六进制字母 A 到
F 可以使用大写或小写形式。例如，一个
仅包含单个反斜线字符的字符串可以表示为
"\u005C"。
或者，一些常用字符也有双字符序列形式的
转义表示。例如，一个
仅包含单个反斜线字符的字符串可以更紧凑地
表示为 "\\"。
Bray 标准跟踪 [第 8 页]
RFC 8259 JSON 2017 年 12 月
要转义不在基本多文种
平面中的扩展字符，该字符表示为一个 12 字符序列，
对 UTF-16 代理对进行编码。例如，一个
仅包含高音谱号字符（U+1D11E）的字符串可以表示为
"\uD834\uDD1E"。
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " 引号 U+0022
%x5C / ; \ 反斜线 U+005C
%x2F / ; / 斜线 U+002F
%x62 / ; b 退格 U+0008
%x66 / ; f 换页 U+000C
%x6E / ; n 换行 U+000A
%x72 / ; r 回车 U+000D
%x74 / ; t 制表符 U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
8. 字符串和字符问题
8.1. 字符编码
在不属于封闭生态系统的系统之间交换的 JSON 文本
MUST 使用 UTF-8 [RFC3629] 编码。
此前的 JSON 规范在传输 JSON 文本时
并未要求使用 UTF-8。然而，绝大多数基于 JSON
的软件实现都选择使用 UTF-8 编码，
以至于它成为唯一能够实现
互操作性的编码。
实现 MUST NOT 在通过网络传输的 JSON 文本
开头添加字节顺序标记（U+FEFF）。为了实现
互操作性，解析 JSON 文本的实现 MAY 忽略
字节顺序标记的存在，而不是将其视为
错误。
Bray 标准跟踪 [第 9 页]
RFC 8259 JSON 2017 年 12 月
8.2. Unicode 字符
当 JSON 文本中表示的所有字符串都完全由
Unicode 字符 [UNICODE] 组成时（无论如何转义），该 JSON
文本具有互操作性，也就是说，所有解析该文本的
软件实现都会对对象和数组中的名称以及字符串
值的内容达成一致。
然而，本规范中的 ABNF 允许成员名称和
字符串值包含无法编码 Unicode
字符的位序列；例如 "\uDEAD"（单个未配对的 UTF-16
代理项）。已经观察到此类情况，例如，
某个库在截断 UTF-16 字符串时未检查
截断位置是否拆分了一个代理对。软件在
接收到包含此类值的 JSON 文本时的行为不可预测；例如，
实现可能会对字符串值的长度返回不同的值，
甚至遭遇致命的运行时异常。
8.3. 字符串比较
软件实现通常需要测试对象成员的
名称是否相等。将文本表示转换为
Unicode 代码单元序列，然后
按代码单元逐个进行数值比较的实现具有
互操作性，也就是说，实现在所有情况下都会
对两个字符串相等或不相等达成一致。例如，
对含有转义字符但未将其转换的字符串进行比较的
实现可能会错误地认为 "a\\b" 和 "a\u005Cb"
不相等。
9. 解析器
JSON 解析器将 JSON 文本转换为另一种表示形式。
JSON 解析器 MUST 接受所有符合 JSON 语法的文本。
JSON 解析器 MAY 接受非 JSON 形式或扩展。
实现可以对其接受的文本大小设置限制。
实现可以对最大嵌套深度设置限制。
实现可以对数字的范围和精度设置限制。
实现可以对字符串的长度和
字符内容设置限制。
10. 生成器
JSON 生成器生成 JSON 文本。生成的文本 MUST
严格符合 JSON 语法。
Bray 标准跟踪 [第 10 页]
RFC 8259 JSON 2017 年 12 月
11. IANA 注意事项
JSON 文本的媒体类型是 application/json。
类型名称： application
子类型名称： json
必需参数： 不适用
可选参数： 不适用
编码注意事项： 二进制
安全注意事项： 参见 RFC 8259 第 12 节
互操作性注意事项： 在 RFC 8259 中描述
已发布的规范： RFC 8259
使用此媒体类型的应用程序：
JSON 已用于在使用以下所有编程语言编写的应用程序之间
交换数据：ActionScript、C、C#、
Clojure、ColdFusion、Common Lisp、E、Erlang、Go、Java、JavaScript、
Lua、Objective CAML、Perl、PHP、Python、Rebol、Ruby、Scala 和
Scheme。
其他信息：
魔数：不适用
文件扩展名：.json
Macintosh 文件类型代码：TEXT
如需更多信息，请联系以下人员及电子邮件地址：
IESG
<iesg@ietf.org>
预期用途： COMMON
使用限制： 无
作者：
Douglas Crockford
<douglas@crockford.com>
变更控制者：
IESG
<iesg@ietf.org>
Bray 标准跟踪 [第 11 页]
RFC 8259 JSON 2017 年 12 月
注：此注册未定义 "charset" 参数。
添加该参数实际上不会对符合要求的接收方产生任何影响。
12. 安全注意事项
一般而言，脚本语言存在安全问题。JSON
是 JavaScript 的一个子集，但排除了赋值和调用。
由于 JSON 的语法借鉴自 JavaScript，因此可以
使用该语言的 "eval()" 函数解析大多数 JSON 文本（但
并非全部；某些字符，例如 U+2028 行分隔符和 U+2029
段落分隔符，在 JSON 中合法，但在 JavaScript 中
不合法）。这通常会构成不可接受的安全风险，因为文本
可能在数据声明之外还包含可执行代码。同样的
考虑也适用于任何其他编程语言中使用类似 eval() 的函数，
前提是 JSON 文本符合该
语言的语法。
13. 示例
这是一个 JSON 对象：
{
"Image": {
"Width": 800,
"Height": 600,
"Title": "15 楼的景色",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": 100
},
"Animated" : false,
"IDs": [116, 943, 234, 38793]
}
}
它的 Image 成员是一个对象，该对象的 Thumbnail 成员也是一个对象，
而其 IDs 成员是一个数字数组。
Bray 标准跟踪 [第 12 页]
RFC 8259 JSON 2017 年 12 月
这是一个包含两个对象的 JSON 数组：
[
{
"precision": "zip",
"Latitude": 37.7668,
"Longitude": -122.3959,
"Address": "",
"City": "SAN FRANCISCO",
"State": "CA",
"Zip": "94107",
"Country": "US"
},
{
"precision": "zip",
"Latitude": 37.371991,
"Longitude": -122.026020,
"Address": "",
"City": "SUNNYVALE",
"State": "CA",
"Zip": "94085",
"Country": "US"
}
]
以下是三个仅包含值的小型 JSON 文本：
"你好，世界！"
42
true
Bray 标准跟踪 [第 13 页]
RFC 8259 JSON 2017 年 12 月
14. 参考文献
14.1. 规范性参考文献
[ECMA-404] Ecma International，“JSON 数据交换格式”，
标准 ECMA-404，
<http://www.ecma-international.org/publications/
standards/Ecma-404.htm>。
[IEEE754] IEEE，“IEEE 浮点算术标准”，
IEEE 754。
[RFC2119] Bradner, S.，“RFC 中用于表示
要求级别的关键词”，BCP 14，RFC 2119，
DOI 10.17487/RFC2119，1997 年 3 月，
<https://www.rfc-editor.org/info/rfc2119>。
[RFC3629] Yergeau, F.，“UTF-8，ISO
10646 的一种转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003 年 11 月，
<https://www.rfc-editor.org/info/rfc3629>。
[RFC5234] Crocker, D.，编辑；P. Overell，“语法
规范的扩充 BNF：ABNF”，STD 68，RFC 5234，
DOI 10.17487/RFC5234，2008 年 1 月，
<https://www.rfc-editor.org/info/rfc5234>。
[RFC8174] Leiba, B.，“RFC
2119 关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，
2017 年 5 月，<https://www.rfc-editor.org/info/rfc8174>。
[UNICODE] Unicode Consortium，“Unicode 标准”，
<http://www.unicode.org/versions/latest/>。
14.2. 资料性参考文献
[ECMA-262] Ecma International，“ECMAScript 语言规范”，
标准 ECMA-262，第三版，1999 年 12 月，
<http://www.ecma-international.org/publications/files/
ECMA-ST-ARCH/
ECMA-262,%203rd%20edition,%20December%201999.pdf>。
[Err3607] RFC 勘误，勘误 ID 3607，RFC 4627，
<https://www.rfc-editor.org/errata/eid3607>。
[Err3915] RFC 勘误，勘误 ID 3915，RFC 7159，
<https://www.rfc-editor.org/errata/eid3915>。
Bray 标准跟踪 [第 14 页]
RFC 8259 JSON 2017 年 12 月
[Err4264] RFC 勘误，勘误 ID 4264，RFC 7159，
<https://www.rfc-editor.org/errata/eid4264>。
[Err4336] RFC 勘误，勘误 ID 4336，RFC 7159，
<https://www.rfc-editor.org/errata/eid4336>。
[Err4388] RFC 勘误，勘误 ID 4388，RFC 7159，
<https://www.rfc-editor.org/errata/eid4388>。
[Err607] RFC 勘误，勘误 ID 607，RFC 4627，
<https://www.rfc-editor.org/errata/eid607>。
[RFC4627] Crockford, D.，“JavaScript 对象表示法（JSON）的
application/json 媒体类型”，RFC 4627，
DOI 10.17487/RFC4627，2006 年 7 月，
<https://www.rfc-editor.org/info/rfc4627>。
[RFC7159] Bray, T.，编辑，“JavaScript 对象表示法（JSON）数据
交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014 年 3 月，
<https://www.rfc-editor.org/info/rfc7159>。
Bray 标准跟踪 [第 15 页]
RFC 8259 JSON 2017 年 12 月
附录 A. 与 RFC 7159 相比的变更
本节列出了本文档与
RFC 7159 文本之间的变更。
o 第 1.2 节 已更新，以反映 ECMA-262 中删除了一个 JSON
规范，将 ECMA-404 设为规范性
引用，并解释“规范性”的特定含义。
o 第 1.3 节 已更新，以反映针对
RFC 7159 而非 RFC 4627 提交的勘误。
o 第 8.1 节 已修改，要求通过网络
传输时使用 UTF-8。
o 第 12 节 已更新，以提高
对使用 ECMAScript "eval()" 函数所带来的
安全风险描述的精确度。
o 第 14.1 节 已更新，将 ECMA-404 纳入规范性
参考文献。
o 第 14.2 节 已更新，以移除 ECMA-404、更新
ECMA-262 的版本，并刷新勘误列表。
贡献者
RFC 4627 由 Douglas Crockford 编写。本文档是在
该文档基础上进行数量相对较少的修改而形成的；
因此，这里的绝大部分文本均出自他之手。
作者地址
Tim Bray（编辑）
Textuality
电子邮件：tbray@textuality.com
Bray 标准跟踪 [第 16 页]