Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 8259 Textuality
Obsoletes: 7159 December 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 8259 Textuality
Obsoletes: 7159 December 2017
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8259.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8259.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://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 . . . . . . . . . . . . . . 5
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. String and Character Issues . . . . . . . . . . . . . . . . . 9
8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 9
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 10
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 10
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Specifications of JSON . . . . . . . . . . . . . . . . . 4
1.3. Introduction to This Revision . . . . . . . . . . . . . . 5
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. String and Character Issues . . . . . . . . . . . . . . . . . 9
8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 9
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 10
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 10
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The grammatical rules in this document are to be interpreted as described in [RFC5234].
本文件中的语法规则应按照[RFC5234]中所述进行解释。
This document replaces [RFC7159]. [RFC7159] obsoleted [RFC4627], which originally described JSON and registered the media type "application/json".
本文件取代[RFC7159]。[RFC7159]淘汰了[RFC4627]，它最初描述JSON并注册了媒体类型“application/JSON”。
JSON is also described in [ECMA-404].
[ECMA-404]中也描述了JSON。
The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term "JSON text" in any of its specifications. Note, however, that ECMA-404 allows several practices that this specification recommends avoiding in the interests of maximal interoperability.
前一句中对ECMA-404的引用是规范性的，并非通常意义上的实现者需要参考ECMA-404以理解本文档，而是强调任何规范中术语“JSON文本”的定义都不存在不一致之处。然而，请注意，ECMA-404允许本规范建议避免的几种实践，以实现最大的互操作性。
The intent is that the grammar is the same between the two documents, although different descriptions are used. If there is a difference found between them, ECMA and the IETF will work together to update both documents.
其目的是两个文档之间的语法相同，尽管使用了不同的描述。如果发现两者之间存在差异，ECMA和IETF将共同更新这两个文件。
If an error is found with either document, the other should be examined to see if it has a similar error; if it does, it should be fixed, if possible.
如果发现任何一份文件存在错误，则应检查另一份文件是否存在类似错误；如果有，如果可能的话，它应该被修复。
If either document is changed in the future, ECMA and the IETF will work together to ensure that the two documents stay aligned through the change.
如果未来任何一份文件发生变更，ECMA和IETF将共同努力，确保两份文件在变更过程中保持一致。
In the years since the publication of RFC 4627, JSON has found very wide use. This experience has revealed certain patterns that, while allowed by its specifications, have caused interoperability problems.
自RFC4627发布以来，JSON得到了非常广泛的使用。这一经验揭示了某些模式，尽管其规范允许这些模式，但它们导致了互操作性问题。
Also, a small number of errata have been reported regarding RFC 4627 (see RFC Errata IDs 607 [Err607] and 3607 [Err3607]) and regarding RFC 7159 (see RFC Errata IDs 3915 [Err3915], 4264 [Err4264], 4336 [Err4336], and 4388 [Err4388]).
此外，报告了少量关于RFC 4627的勘误表（参见RFC勘误表IDs 607[Err607]和3607[Err3607]）以及关于RFC 7159的勘误表（参见RFC勘误表IDs 3915[Err3915]、4264[Err4264]、4336[Err4336]和4388[Err4388]）。
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 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文本约束为对象或数组。只生成调用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 uppercase or lowercase, 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 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 binary64（双精度）数字[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 through F can be uppercase or lowercase. 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 exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].
不属于封闭生态系统的系统之间交换的JSON文本必须使用UTF-8[RFC3629]编码。
Previous specifications of JSON have not required the use of UTF-8 when transmitting JSON text. However, the vast majority of JSON-based software implementations have chosen to use the UTF-8 encoding, to the extent that it is the only encoding that achieves interoperability.
以前的JSON规范在传输JSON文本时没有要求使用UTF-8。然而，绝大多数基于JSON的软件实现都选择使用UTF-8编码，因为它是实现互操作性的唯一编码。
Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of a networked-transmitted 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文本的开头添加字节顺序标记（U+FEFF）。为了实现互操作性，解析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 media type for JSON text is application/json.
JSON文本的媒体类型为application/JSON。
Type name: application
类型名称：应用程序
Subtype name: json
子类型名称：json
Required parameters: n/a
所需参数：不适用
Optional parameters: n/a
可选参数：不适用
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See RFC 8259, Section 12
安全注意事项：见RFC 8259第12节
Interoperability considerations: Described in RFC 8259
互操作性注意事项：在RFC 8259中描述
Published specification: RFC 8259
已发布规范：RFC 8259
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 most JSON texts (but not all; certain characters such as U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript). 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文本（但不是全部；某些字符，如U+2028行分隔符和U+2029段分隔符，在JSON中是合法的，但在JavaScript中不合法）。这通常构成不可接受的安全风险，因为文本可能包含可执行代码和数据声明。同样的考虑也适用于在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
符合事实的
[ECMA-404] Ecma International, "The JSON Data Interchange Format", Standard ECMA-404, <http://www.ecma-international.org/publications/ standards/Ecma-404.htm>.
[ECMA-404]ECMA国际，“JSON数据交换格式”，标准ECMA-404<http://www.ecma-international.org/publications/ 标准/Ecma-404.htm>。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754.
[IEEE754]IEEE，“IEEE浮点运算标准”，IEEE 754。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[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, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[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., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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", Standard ECMA-262, Third Edition, December 1999, <http://www.ecma-international.org/publications/files/ ECMA-ST-ARCH/ ECMA-262,%203rd%20edition,%20December%201999.pdf>.
[ECMA-262]ECMA国际，“ECMAScript语言规范”，标准ECMA-262，第三版，1999年12月<http://www.ecma-international.org/publications/files/ ECMA-ST-ARCH/ECMA-262，%203rd%20edition，%20December%201999.pdf>。
[Err3607] RFC Errata, Erratum ID 3607, RFC 4627, <https://www.rfc-editor.org/errata/eid3607>.
[Err3607]RFC勘误表，勘误表ID 3607，RFC 4627<https://www.rfc-editor.org/errata/eid3607>.
[Err3915] RFC Errata, Erratum ID 3915, RFC 7159, <https://www.rfc-editor.org/errata/eid3915>.
[Err3915]RFC勘误表，勘误表ID 3915，RFC 7159<https://www.rfc-editor.org/errata/eid3915>.
[Err4264] RFC Errata, Erratum ID 4264, RFC 7159, <https://www.rfc-editor.org/errata/eid4264>.
[Err4264]RFC勘误表，勘误表ID 4264，RFC 7159<https://www.rfc-editor.org/errata/eid4264>.
[Err4336] RFC Errata, Erratum ID 4336, RFC 7159, <https://www.rfc-editor.org/errata/eid4336>.
[Err4336]RFC勘误表，勘误表ID 4336，RFC 7159<https://www.rfc-editor.org/errata/eid4336>.
[Err4388] RFC Errata, Erratum ID 4388, RFC 7159, <https://www.rfc-editor.org/errata/eid4388>.
[Err4388]RFC勘误表，勘误表ID 4388，RFC 7159<https://www.rfc-editor.org/errata/eid4388>.
[Err607] RFC Errata, Erratum ID 607, RFC 4627, <https://www.rfc-editor.org/errata/eid607>.
[Err607]RFC勘误表，勘误表ID 607，RFC 4627<https://www.rfc-editor.org/errata/eid607>.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, July 2006, <https://www.rfc-editor.org/info/rfc4627>.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC 4627，DOI 10.17487/RFC4627，2006年7月<https://www.rfc-editor.org/info/rfc4627>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<https://www.rfc-editor.org/info/rfc7159>.
This section lists changes between this document and the text in RFC 7159.
本节列出了本文件与RFC 7159中文本之间的更改。
o Section 1.2 has been updated to reflect the removal of a JSON specification from ECMA-262, to make ECMA-404 a normative reference, and to explain the particular meaning of "normative".
o 第1.2节已经更新，以反映从ECMA-262中删除JSON规范，使ECMA-404成为规范性参考，并解释“规范性”的特殊含义。
o Section 1.3 has been updated to reflect errata filed against RFC 7159, not RFC 4627.
o 第1.3节已更新，以反映根据RFC 7159而非RFC 4627提交的勘误表。
o Section 8.1 was changed to require the use of UTF-8 when transmitted over a network.
o 第8.1节被修改为要求在通过网络传输时使用UTF-8。
o Section 12 has been updated to increase the precision of the description of the security risk that follows from using the ECMAScript "eval()" function.
o 第12节已经更新，以提高使用ECMAScript“eval（）”函数后安全风险描述的准确性。
o Section 14.1 has been updated to include ECMA-404 as a normative reference.
o 第14.1节已更新，将ECMA-404作为规范性参考。
o Section 14.2 has been updated to remove ECMA-404, update the version of ECMA-262, and refresh the errata list.
o 第14.2节已更新，以删除ECMA-404，更新ECMA-262版本，并刷新勘误表。
Contributors
贡献者
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由道格拉斯·克罗克福德撰写。本文件是通过对该文件进行相对少量的更改而构建的；因此，这里的绝大多数文本都是他的。
Author's Address
作者地址
Tim Bray (editor) Textuality
蒂姆·布雷（编辑）文本性
Email: tbray@textuality.com
Email: tbray@textuality.com