嫌字多麻烦的话，可以直接看【13.实例】
RFC 8259：JSON文本格式
摘要
——JavaScript对象表示法(JavaScript Object Notation，JSON)是一种轻量级的、基于文本的、与语言无关的数据交换格式。它来自ECMAScript编程语言标准。JSON为可移植的结构化数据表示定义了一组小的格式化规则。
——本文档消除了与JSON的其他规范不一致的地方，修复了规范错误，并提供了基于经验的互操作性指导。
本备忘录的状况
——这是一个互联网标准跟踪文件。
——本文档是Internet工程任务组(IETF)的产品。它代表了IETF社区的共识。该报告已得到公众审查，并已获互联网工程指导小组批准出版。关于因特网标准的更多信息见RFC 7841第2节。
1.导言
——JavaScript对象表示法(JSON)是一种用于结构化数据序列化的文本格式。它来自JavaScript的对象文字，如ECMAScript编程语言标准第三版[ECMA-262]中定义的那样。
——JSON可以表示四种基本类型(字符串、数字、布尔和NULL)和两种结构化类型(对象Object和数组Array)。
————字符串是由零个或多个Unicode字符组成的序列[Unicode]。请注意，此引用引用的是Unicode的最新版本，而不是特定版本。预计未来对Unicode规范的更改不会影响JSON的语法。
————对象是零个或多个名称/值对的无序集合，其中名称是字符串，值是字符串、数字、布尔值、NULL、对象或数组。
————数组是一个零个或多个值的有序序列。
————术语“Object”和“Array”来自JavaScript的约定。JSON的设计目标是：它是最小的、可移植的、文本的和JavaScript的子集。
2.JSON语法
——JSON文本是一系列标记。这组标记包括六个结构字符、字符串、数字和三个文字名称。
——JSON文本是一个序列化的值。注意，以前的某些JSON规范将JSON文本限制为对象或数组。只生成调用JSON文本的对象或数组的实现将是可互操作的，因为所有实现都将接受这些作为符合JSON文本的实现。
以下是六个结构字符：
在这六个结构字符中的任何一个之前或之后都允许使用不重要的空白字符ws。
3.值
——JSON值必须是数字、字符串、对象、数组，或以下三个文字名称之一：
文字名称必须是小写。不允许使用其他文字名称。
4.对象
——对象结构表示为围绕零或多个名称/值对(或多个成员)的一对花括号。名称是字符串。在每个名称之后加上一个冒号，将名称与值分隔开来。一个逗号将值与接下来的名称分隔开来。对象中的名称应该是唯一的。
——所有名称都唯一的对象是可互操作的，因为接收该对象的所有软件实现都会在【名称-值】映射上达成一致。当对象中的名称不是唯一的时，接收此类对象的软件的实现行为是不可预测的。许多实现只报告名称/值对。其他实现会报告错误或无法解析对象，而一些实现则会报告所有名称/值对，包括重复的名称/值对。
——JSON解析库对于它们是否使对象成员的排序对调用软件是可见的，已经观察到了不同的情况。其行为不依赖于成员排序的实现将是可互操作的，因为它们不会受到这些差异的影响。
5.数组
——数组结构表示为围绕零个或多个值(或多个元素)的方括号。元素用逗号分隔。
——不要求数组中的值具有相同的类型。
6.数字
——数字的表示与大多数编程语言中使用的表示类似。一个数字用十进制数字以基数10表示。它包含一个整数分量，其前缀可以是可选减号，后面可以是分数部分和/或指数部分。不允许前导零。
——分数部分是小数点，后面跟着一个或多个数字。
——指数部分以大写或小写字母E开头，后面可以是正负号。E和可选符号后面跟着一个或多个数字。
——不允许使用【不能用下面的语法表示的】数值(如Infinity和NaN)。
——该规范允许【implementations】对所接受的数字的范围和精度设置限制。由于实现IEEE 754二进制64(双精度)数字[IEEE 754]的软件是普遍可用和广泛使用的，因此只要【implementations】的精度或范围不超过广泛使用的标准，就可以实现良好的互操作性，因为【implementations】将在预期的精度范围内近似于JSON数字。
——诸如1E400或3.14159265357932384626383279这样的JSON数字可能有潜在的互操作性问题，因为如果创建的软件使用这样的数字，该创建的软件会希望接收方软件在数值范围和精度方面比广泛可用的软件更大。
——请注意，当使用这种软件时，属于整数且在[-(253)+1，(253)-1]范围内的数字是可互操作的，因为实现将精确地商定它们的数值。
7.字符串
——字符串的表示类似于C系列编程语言中使用的约定。字符串以单引号开头和结尾。所有Unicode字符都可以放在引号中，但必须转义的字符除外：引号、反斜线分隔符\和控制字符(U+0000到U+001 F)。
——任何字符都可以转义。如果字符位于基本的多语言平面(从U+0000到U+FFFF)，那么它可以表示为六个字符序列：反斜线分隔符\，后面跟着小写字母u，后面跟着四个十六进制数字，编码字符的代码点。十六进制字母A到F可以是大写字母，也可以是小写字母。因此，例如，只包含一个反向Solidus字符的字符串可以表示为“\u005C”。
——另外，也有一些流行字符的双字符序列转义表示形式。因此，例如，只包含一个反向Solidus字符的字符串可以更紧凑地表示为“\”。
——为了转义不属于基本多语言平面的扩展字符，该字符被表示为12个字符序列，编码UTF-16代理项对。因此，例如，只包含G clef字符(U+1D11E)的字符串可以表示为“\uD 834\uDD1E”。
8.字符串和字符问题
8.1.字符编码
——在不属于封闭生态系统的系统之间交换的JSON文本必须使用UTF-8[RFC 3629]编码。
——以前的JSON规范在传输JSON文本时不需要使用UTF-8。然而，绝大多数基于JSON的软件实现都选择使用UTF-8编码，因为它是实现互操作性的唯一编码。
——【implementations】不能在网络传输的JSON文本的开头添加字节顺序标记(U+FEFF)。为了实现互操作性，解析JSON文本的实现可能忽略字节顺序标记的存在，而不是将其视为错误。
8.2.Unicode字符
——当在JSON文本中表示的所有字符串都由Unicode字符( 无论如何转义 )组成时，那么JSON文本是可互操作的，因为解析它的所有软件实现都将在对象和数组中的名称和字符串值的内容上达成一致。
——但是，该规范中的ABNF允许成员名称和字符串值包含不能编码Unicode字符的位序列；例如“\uDEAD”(一个未配对的UTF-16代理项)。例如，当库在不检查截断是否拆分代理项对的情况下截断UTF-16字符串时，就会观察到这种情况。接收包含这些值的JSON文本的软件的行为是不可预测的；例如，实现可能返回字符串值长度的不同值，甚至会遇到致命的运行时异常。
8.3.字符串比较
——通常需要软件实现来测试对象成员的名称是否相等。将文本表示转换为Unicode代码单元的序列，然后按代码单元进行数字比较的实现是可互操作的，因为在所有情况下，【implementations】都将同意两个字符串的相等或不平等。例如，将字符串与未转换的转义字符进行比较的实现可能会错误地发现“a\ \b”和“a\u005Cb”不相等。
9.解析器
——JSON解析器将JSON文本转换为另一种表示形式。JSON解析器必须接受符合JSON语法的所有文本。JSON解析器可以接受非JSON形式或扩展。
——【implementations】可以限制其接受的文本的大小，限制嵌套的最大深度，限制数字的范围和精度，对字符串的长度和字符内容设置限制。
10.生成器
——JSON生成器生成JSON文本。得到的结果文本必须严格符合JSON语法。
12.安全考虑
——一般来说，脚本语言存在安全问题。JSON是JavaScript的一个子集，但不包括赋值和调用。
——由于JSON的语法是从JavaScript借用的，所以可以使用JavaScript的“eval()”函数来解析大多数JSON文本，但不是全部字符都能用它来解析。某些字符，例如U+2028行分隔符（"\u2028"）和U+2029段分隔符（"\u2029"）在JSON中是合法的，而在JavaScript中不合法。这通常构成不可接受的安全风险，因为文本可以包含可执行代码和数据声明。如果其他编程语言中同样含有类似于eval()函数语法的函数，在使用这些类似的函数处理JSON文本时，同样也要考虑这一点。
解决方法是：用\u2028和\u2029（转义序列）替换每个U+2028和U+2029字符
13.实例
JSON对象：
该对象的成员Image是一个对象。而对象Image的成员Thumbnail（缩略图）是一个对象，成员ID是一个数字数组。
JSON数组：
仅包含值的JSON文本：
