Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 7159 Google, Inc.
Obsoletes: 4627, 7158 March 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 7159 Google, Inc.
Obsoletes: 4627, 7158 March 2014
Category: Standards Track
ISSN: 2070-1721
The JavaScript Object Notation (JSON) Data Interchange Format
JavaScript对象表示法（JSON）数据交换格式
Abstract
摘要
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
JavaScript对象表示法（JSON）是一种轻量级、基于文本、独立于语言的数据交换格式。它源于ECMAScript编程语言标准。JSON为结构化数据的可移植表示定义了一小组格式化规则。
This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
本文档消除了与JSON其他规范的不一致之处，修复了规范错误，并提供了基于经验的互操作性指导。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7159.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7159.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Specifications of JSON .....................................4
1.3. Introduction to This Revision ..............................4
2. JSON Grammar ....................................................4
3. Values ..........................................................5
4. Objects .........................................................6
5. Arrays ..........................................................6
6. Numbers .........................................................6
7. Strings .........................................................8
8. String and Character Issues .....................................9
8.1. Character Encoding .........................................9
8.2. Unicode Characters .........................................9
8.3. String Comparison ..........................................9
9. Parsers ........................................................10
10. Generators ....................................................10
11. IANA Considerations ...........................................10
12. Security Considerations .......................................11
13. Examples ......................................................12
14. Contributors ..................................................13
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
Appendix A. Changes from RFC 4627 .................................15
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Specifications of JSON .....................................4
1.3. Introduction to This Revision ..............................4
2. JSON Grammar ....................................................4
3. Values ..........................................................5
4. Objects .........................................................6
5. Arrays ..........................................................6
6. Numbers .........................................................6
7. Strings .........................................................8
8. String and Character Issues .....................................9
8.1. Character Encoding .........................................9
8.2. Unicode Characters .........................................9
8.3. String Comparison ..........................................9
9. Parsers ........................................................10
10. Generators ....................................................10
11. IANA Considerations ...........................................10
12. Security Considerations .......................................11
13. Examples ......................................................12
14. Contributors ..................................................13
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
Appendix A. Changes from RFC 4627 .................................15
JavaScript Object Notation (JSON) is a text format for the serialization of structured data. It is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard, Third Edition [ECMA-262].
JavaScript对象表示法（JSON）是用于结构化数据序列化的文本格式。它源自JavaScript的对象文本，如ECMAScript编程语言标准第三版[ECMA-262]中所定义。
JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).
JSON可以表示四种基本类型（字符串、数字、布尔值和null）和两种结构化类型（对象和数组）。
A string is a sequence of zero or more Unicode characters [UNICODE]. Note that this citation references the latest version of Unicode rather than a specific release. It is not expected that future changes in the UNICODE specification will impact the syntax of JSON.
字符串是零个或多个Unicode字符[Unicode]的序列。请注意，此引用引用了最新版本的Unicode，而不是特定版本。UNICODE规范的未来变化不会影响JSON的语法。
An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.
对象是零个或多个名称/值对的无序集合，其中名称是字符串，值是字符串、数字、布尔值、null、对象或数组。
An array is an ordered sequence of zero or more values.
数组是零个或多个值的有序序列。
The terms "object" and "array" come from the conventions of JavaScript.
术语“对象”和“数组”来自JavaScript的约定。
JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
JSON的设计目标是使其最小化、可移植、文本化，并且是JavaScript的一个子集。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The grammatical rules in this document are to be interpreted as described in [RFC5234].
本文件中的语法规则应按照[RFC5234]中所述进行解释。
This document updates [RFC4627], which describes JSON and registers the media type "application/json".
本文档更新了[RFC4627]，其中描述了JSON并注册了媒体类型“application/JSON”。
A description of JSON in ECMAScript terms appears in Version 5.1 of the ECMAScript specification [ECMA-262], Section 15.12. JSON is also described in [ECMA-404].
ECMAScript规范[ECMA-262]的5.1版第15.12节介绍了ECMAScript术语中的JSON。[ECMA-404]中也描述了JSON。
All of the specifications of JSON syntax agree on the syntactic elements of the language.
JSON语法的所有规范都同意该语言的语法元素。
In the years since the publication of RFC 4627, JSON has found very wide use. This experience has revealed certain patterns, which, while allowed by its specifications, have caused interoperability problems.
自RFC4627发布以来，JSON得到了非常广泛的使用。这一经验揭示了某些模式，尽管其规范允许这些模式，但它们导致了互操作性问题。
Also, a small number of errata have been reported (see RFC Errata IDs 607 [Err607] and 3607 [Err3607]).
此外，报告了少量勘误表（参见RFC勘误表IDs 607[Err607]和3607[Err3607]）。
This document's goal is to apply the errata, remove inconsistencies with other specifications of JSON, and highlight practices that can lead to interoperability problems.
本文档的目标是应用勘误表，消除与JSON其他规范的不一致，并强调可能导致互操作性问题的实践。
A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names.
JSON文本是一系列标记。标记集包括六个结构字符、字符串、数字和三个文字名称。
A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an
JSON文本是一个序列化的值。请注意，以前的某些JSON规范将JSON文本约束为对象或对象
array. Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.
大堆只生成调用JSON文本的对象或数组的实现将具有互操作性，因为所有实现都将接受这些对象或数组作为一致的JSON文本。
JSON-text = ws value ws
JSON-text = ws value ws
These are the six structural characters:
以下是六个结构特征：
begin-array = ws %x5B ws ; [ left square bracket
开始数组=ws%x5B ws；[左方括号
begin-object = ws %x7B ws ; { left curly bracket
begin-object = ws %x7B ws ; { left curly bracket
end-array = ws %x5D ws ; ] right square bracket
结束数组=ws%x5D ws；]右方括号
end-object = ws %x7D ws ; } right curly bracket
end-object = ws %x7D ws ; } right curly bracket
name-separator = ws %x3A ws ; : colon
name-separator = ws %x3A ws ; : colon
value-separator = ws %x2C ws ; , comma
值分隔符=ws%x2C ws，逗号
Insignificant whitespace is allowed before or after any of the six structural characters.
允许在六个结构字符中的任何一个之前或之后使用不重要的空格。
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ) ; Carriage return
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ) ; Carriage return
A JSON value MUST be an object, array, number, or string, or one of the following three literal names:
JSON值必须是对象、数组、数字或字符串，或以下三个文字名称之一：
false null true
假空真
The literal names MUST be lowercase. No other literal names are allowed.
文字名称必须为小写。不允许使用其他文字名称。
value = false / null / true / object / array / number / string
value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
null = %x6e.75.6c.6c ; null
true = %x74.72.75.65 ; true
true = %x74.72.75.65 ; true
An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.
对象结构表示为围绕零个或多个名称/值对（或成员）的一对花括号。名称是一个字符串。每个名称后面都有一个冒号，将名称与值分开。一个逗号将值与以下名称分隔开。对象中的名称应该是唯一的。
object = begin-object [ member *( value-separator member ) ] end-object
对象=开始对象[成员*（值分隔符成员）]结束对象
member = string name-separator value
member = string name-separator value
An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.
名称都是唯一的对象是可互操作的，因为接收该对象的所有软件实现都将在名称-值映射上达成一致。当对象中的名称不唯一时，接收此类对象的软件的行为是不可预测的。许多实现只报告姓氏/值对。其他实现报告错误或无法解析对象，一些实现报告所有名称/值对，包括重复项。
JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.
JSON解析库在是否使调用软件可以看到对象成员的顺序方面存在差异。行为不依赖于成员顺序的实现将具有互操作性，因为它们不会受到这些差异的影响。
An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas.
数组结构表示为围绕零个或多个值（或元素）的方括号。元素之间用逗号分隔。
array = begin-array [ value *( value-separator value ) ] end-array
数组=开始数组[值*（值分隔符值）]结束数组
There is no requirement that the values in an array be of the same type.
数组中的值不一定是同一类型的。
The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed.
数字的表示法与大多数编程语言中使用的表示法相似。数字以十进制数字表示，以10为基数。它包含一个整数组件，该组件的前缀可能是可选的减号，后面可能是分数部分和/或指数部分。不允许使用前导零。
A fraction part is a decimal point followed by one or more digits.
小数部分是一个小数点，后跟一个或多个数字。
An exponent part begins with the letter E in upper or lower case, which may be followed by a plus or minus sign. The E and optional sign are followed by one or more digits.
指数部分以大写或小写字母E开头，后面可以跟加号或减号。E和可选符号后跟一个或多个数字。
Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.
不允许在下面的语法中表示数值（如无穷大和NaN）。
number = [ minus ] int [ frac ] [ exp ]
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
分数=小数点1*位
int = zero / ( digit1-9 *DIGIT )
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
minus = %x2D ; -
plus = %x2B ; +
plus = %x2B ; +
zero = %x30 ; 0
zero = %x30 ; 0
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
此规范允许实现对接受的数字的范围和精度设置限制。由于实现IEEE 754-2008二进制64（双精度）数字[IEEE754]的软件普遍可用并被广泛使用，因此，通过实现不期望比这些数字更高的精度或范围，可以实现良好的互操作性，因为实现将在预期精度内近似JSON数字。JSON编号（如1E400或3.141592653589793238462643383279）可能表示潜在的互操作性问题，因为它表明创建它的软件期望接收软件具有比广泛可用的更大的数值大小和精度能力。
Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.
请注意，当使用此类软件时，在[-（2**53）+1，（2**53）-1]范围内的整数数字是可互操作的，因为实现将完全一致于它们的数值。
The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).
字符串的表示类似于C语言家族中使用的约定。字符串以引号开头和结尾。除必须转义的字符外，所有Unicode字符都可以放在引号内：引号、反索利多卡因和控制字符（U+0000到U+001F）。
Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A though F can be upper or lower case. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C".
任何字符都可以转义。如果字符位于基本多语言平面（U+0000到U+FFFF），则可以将其表示为六个字符的序列：一个反向索利多卡因，后跟小写字母U，后跟四个十六进制数字，用于编码字符的代码点。十六进制字母A到F可以是大写或小写。因此，例如，仅包含单个反向索利多士字符的字符串可以表示为“\u005C”。
Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single reverse solidus character may be represented more compactly as "\\".
或者，有些流行字符有两个字符序列转义表示。因此，例如，仅包含单个反向索利多士字符的字符串可以更简洁地表示为“\\”。
To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a 12-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E".
要转义不在基本多语言平面中的扩展字符，该字符将表示为12个字符的序列，对UTF-16代理项对进行编码。因此，例如，仅包含G谱号字符（U+1D11E）的字符串可以表示为“\uD834\uDD1E”。
string = quotation-mark *char quotation-mark
字符串=引号*字符引号
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
escape = %x5C ; \
quotation-mark = %x22 ; "
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32).
JSON文本应采用UTF-8、UTF-16或UTF-32编码。默认编码是UTF-8，UTF-8中编码的JSON文本是可互操作的，因为它们将被最大数量的实现成功读取；有许多实现无法成功读取其他编码（如UTF-16和UTF-32）中的文本。
Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.
实现不能在JSON文本的开头添加字节顺序标记。为了实现互操作性，解析JSON文本的实现可能会忽略字节顺序标记的存在，而不是将其视为错误。
When all the strings represented in a JSON text are composed entirely of Unicode characters [UNICODE] (however escaped), then that JSON text is interoperable in the sense that all software implementations that parse it will agree on the contents of names and of string values in objects and arrays.
当JSON文本中表示的所有字符串都完全由Unicode字符[Unicode]组成时（无论如何转义），那么JSON文本是可互操作的，因为所有解析它的软件实现都将在对象和数组中的名称和字符串值的内容上达成一致。
However, the ABNF in this specification allows member names and string values to contain bit sequences that cannot encode Unicode characters; for example, "\uDEAD" (a single unpaired UTF-16 surrogate). Instances of this have been observed, for example, when a library truncates a UTF-16 string without checking whether the truncation split a surrogate pair. The behavior of software that receives JSON texts containing such values is unpredictable; for example, implementations might return different values for the length of a string value or even suffer fatal runtime exceptions.
但是，本规范中的ABNF允许成员名称和字符串值包含不能编码Unicode字符的位序列；例如，“\uDEAD”（单个未配对的UTF-16代理项）。例如，当库截断UTF-16字符串而不检查截断是否拆分了代理项对时，就观察到了这种情况。接收包含这些值的JSON文本的软件的行为是不可预测的；例如，实现可能会为字符串值的长度返回不同的值，甚至出现致命的运行时异常。
Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit, are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example, implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal.
软件实现通常需要测试对象成员的名称是否相等。将文本表示转换为Unicode代码单元序列，然后逐个代码单元执行数字比较的实现是可互操作的，因为实现在所有情况下都会同意两个字符串的相等或不相等。例如，将字符串与未转换的转义字符进行比较的实现可能会错误地发现“a\\b”和“a\u005Cb”不相等。
A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions.
JSON解析器将JSON文本转换为另一种表示形式。JSON解析器必须接受符合JSON语法的所有文本。JSON解析器可以接受非JSON形式或扩展。
An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.
一个实现可以对它接受的文本的大小设置限制。实现可能会对嵌套的最大深度设置限制。实现可能会对数字的范围和精度设置限制。实现可以对字符串的长度和字符内容设置限制。
A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar.
JSON生成器生成JSON文本。生成的文本必须严格符合JSON语法。
The MIME media type for JSON text is application/json.
JSON文本的MIME媒体类型为application/JSON。
Type name: application
类型名称：应用程序
Subtype name: json
子类型名称：json
Required parameters: n/a
所需参数：不适用
Optional parameters: n/a
可选参数：不适用
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See [RFC7159], Section 12.
安全注意事项：见[RFC7159]，第12节。
Interoperability considerations: Described in [RFC7159]
互操作性注意事项：如[RFC7159]所述
Published specification: [RFC7159]
已发布规范：[RFC7159]
Applications that use this media type: JSON has been used to exchange data between applications written in all of these programming languages: ActionScript, C, C#, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and Scheme.
使用这种媒体类型的应用程序：JSON被用来在所有这些编程语言编写的应用程序之间交换数据：ActionScript、C、C#、Clojure、ColdFusion、Common Lisp、E、Erlang、Go、Java、JavaScript、Lua、Objective CAML、Perl、PHP、Python、Rebol、Ruby、Scala和Scheme。
Additional information:
Magic number(s): n/a
File extension(s): .json
Macintosh file type code(s): TEXT
Additional information:
Magic number(s): n/a
File extension(s): .json
Macintosh file type code(s): TEXT
Person & email address to contact for further information: IESG <iesg@ietf.org>
联系人和电子邮件地址，以获取更多信息：IESG<iesg@ietf.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: none
使用限制：无
Author: Douglas Crockford <douglas@crockford.com>
作者：道格拉斯·克罗克福德<douglas@crockford.com>
Change controller: IESG <iesg@ietf.org>
更改控制器：IESG<iesg@ietf.org>
Note: No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.
注意：没有为此注册定义“字符集”参数。添加一个确实对符合要求的收件人没有影响。
Generally, there are security issues with scripting languages. JSON is a subset of JavaScript but excludes assignment and invocation.
通常，脚本语言存在安全问题。JSON是JavaScript的一个子集，但不包括赋值和调用。
Since JSON's syntax is borrowed from JavaScript, it is possible to use that language's "eval()" function to parse JSON texts. This generally constitutes an unacceptable security risk, since the text could contain executable code along with data declarations. The same consideration applies to the use of eval()-like functions in any other programming language in which JSON texts conform to that language's syntax.
由于JSON的语法借用了JavaScript，因此可以使用该语言的“eval（）”函数来解析JSON文本。这通常构成不可接受的安全风险，因为文本可能包含可执行代码和数据声明。同样的考虑也适用于在JSON文本符合该语言语法的任何其他编程语言中使用类似eval（）的函数。
This is a JSON object:
这是一个JSON对象：
{
"Image": {
"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": 100
},
"Animated" : false,
"IDs": [116, 943, 234, 38793]
}
}
{
"Image": {
"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": 100
},
"Animated" : false,
"IDs": [116, 943, 234, 38793]
}
}
Its Image member is an object whose Thumbnail member is an object and whose IDs member is an array of numbers.
它的图像成员是一个对象，其缩略图成员是一个对象，其IDs成员是一个数字数组。
This is a JSON array containing two objects:
这是一个包含两个对象的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"
}
]
[
{
"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"
}
]
Here are three small JSON texts containing only values:
以下是三个仅包含值的小JSON文本：
"Hello world!"
“你好，世界！”
42
42
true
符合事实的
RFC 4627 was written by Douglas Crockford. This document was constructed by making a relatively small number of changes to that document; thus, the vast majority of the text here is his.
RFC4627由道格拉斯·克罗克福德撰写。本文件是通过对该文件进行相对少量的更改而构建的；因此，这里的绝大多数文本都是他的。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008, <http://grouper.ieee.org/groups/754/>.
[IEEE754]IEEE，“IEEE浮点运算标准”，IEEE标准754，2008年8月<http://grouper.ieee.org/groups/754/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[ECMA-262] Ecma International, "ECMAScript Language Specification Edition 5.1", Standard ECMA-262, June 2011, <http://www.ecma-international.org/publications/standards/ Ecma-262.htm>.
[ECMA-262]ECMA国际，“ECMAScript语言规范第5.1版”，标准ECMA-262，2011年6月<http://www.ecma-international.org/publications/standards/ Ecma-262.htm>。
[ECMA-404] Ecma International, "The JSON Data Interchange Format", Standard ECMA-404, October 2013, <http://www.ecma-international.org/publications/standards/ Ecma-404.htm>.
[ECMA-404]ECMA国际，“JSON数据交换格式”，标准ECMA-404，2013年10月<http://www.ecma-international.org/publications/standards/ Ecma-404.htm>。
[Err3607] RFC Errata, Errata ID 3607, RFC 3607, <http://www.rfc-editor.org>.
[Err3607]RFC勘误表，勘误表ID 3607，RFC 3607<http://www.rfc-editor.org>.
[Err607] RFC Errata, Errata ID 607, RFC 607, <http://www.rfc-editor.org>.
[Err607]RFC勘误表，勘误表ID 607，RFC 607<http://www.rfc-editor.org>.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC4627，2006年7月。
This section lists changes between this document and the text in RFC 4627.
本节列出了本文件与RFC 4627中文本之间的更改。
o Changed the title and abstract of the document.
o 更改了文档的标题和摘要。
o Changed the reference to [UNICODE] to be not version specific.
o 将对[UNICODE]的引用更改为不特定于版本。
o Added a "Specifications of JSON" section.
o 添加了“JSON规范”部分。
o Added an "Introduction to This Revision" section.
o 增加了“本修订简介”一节。
o Changed the definition of "JSON text" so that it can be any JSON value, removing the constraint that it be an object or array.
o 更改了“JSON文本”的定义，使其可以是任何JSON值，从而消除了它是对象或数组的约束。
o Added language about duplicate object member names, member ordering, and interoperability.
o 添加了有关重复对象成员名称、成员顺序和互操作性的语言。
o Clarified the absence of a requirement that values in an array be of the same JSON type.
o 澄清了数组中的值必须是相同JSON类型的要求的缺失。
o Applied erratum #607 from RFC 4627 to correctly align the artwork for the definition of "object".
o 应用RFC 4627中的勘误表#607，以正确对齐“对象”定义的艺术品。
o Changed "as sequences of digits" to "in the grammar below" in the "Numbers" section, and made base-10-ness explicit.
o 将“数字”部分中的“作为数字序列”更改为“在下面的语法中”，并明确了base-10-ness。
o Added language about number interoperability as a function of IEEE754, and added an IEEE754 reference.
o 作为IEEE754的一个功能，添加了关于数字互操作性的语言，并添加了IEEE754参考。
o Added language about interoperability and Unicode characters and about string comparisons. To do this, turned the old "Encoding" section into a "String and Character Issues" section, with three subsections: "Character Encoding", "Unicode Characters", and "String Comparison".
o 添加了关于互操作性和Unicode字符以及关于字符串比较的语言。为此，将旧的“编码”部分改为“字符串和字符问题”部分，包含三个子部分：“字符编码”、“Unicode字符”和“字符串比较”。
o Changed guidance in the "Parsers" section to point out that implementations may set limits on the range "and precision" of numbers.
o 更改了“解析器”部分中的指南，指出实现可能会对数字的“范围”和“精度”设置限制。
o Updated and tidied the "IANA Considerations" section.
o 更新并整理了“IANA注意事项”部分。
o Made a real "Security Considerations" section and lifted the text out of the previous "IANA Considerations" section.
o 制作了一个真正的“安全注意事项”部分，并将文本从先前的“IANA注意事项”部分中删除。
o Applied erratum #3607 from RFC 4627 by removing the security consideration that begins "A JSON text can be safely passed" and the JavaScript code that went with that consideration.
o 应用RFC4627中的勘误表3607，删除了“可以安全地传递JSON文本”开头的安全注意事项以及与之相关的JavaScript代码。
o Added a note to the "Security Considerations" section pointing out the risks of using the "eval()" function in JavaScript or any other language in which JSON texts conform to that language's syntax.
o 在“安全注意事项”部分添加了一条注释，指出在JavaScript或任何其他JSON文本符合该语言语法的语言中使用“eval（）”函数的风险。
o Added a note to the "IANA Considerations" clarifying the absence of a "charset" parameter for the application/json media type.
o 在“IANA注意事项”中添加了一条注释，澄清了application/json媒体类型缺少“charset”参数的问题。
o Changed "100" to 100 and added a boolean field, both in the first example.
o 在第一个示例中，将“100”更改为100并添加了一个布尔字段。
o Added examples of JSON texts with simple values, neither objects nor arrays.
o 添加了带有简单值的JSON文本示例，既没有对象也没有数组。
o Added a "Contributors" section crediting Douglas Crockford.
o 增加了一个“贡献者”部分，赞扬道格拉斯·克罗克福德。
o Added a reference to RFC 4627.
o 增加了对RFC 4627的参考。
o Moved the ECMAScript reference from Normative to Informative and updated it to reference ECMAScript 5.1, and added a reference to ECMA 404.
o 将ECMAScript参考文献从规范性移至信息性，并将其更新为参考ECMAScript 5.1，并添加了对ECMA 404的参考。
Author's Address
作者地址
Tim Bray (editor) Google, Inc.
蒂姆·布雷（编辑）谷歌公司。
EMail: tbray@textuality.com
EMail: tbray@textuality.com