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。

{
     "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 的语法和处理，以尽可能避免这些互操作性问题

1. Apple捷徑 （页面存档备份，存于）

• JSONP
• AJAX
• JavaScript
• YAML
• HOCON

• （英文） JSON（页面存档备份，存于），關於JSON的規格、文件，以及在其他語言實做的資訊
• JSON中文说明 （页面存档备份，存于）
• （英文） RFC 4627，JSON在RFC裡的規格
• JSON格式化工具 (中文) （页面存档备份，存于）
• JSON编辑器 （页面存档备份，存于）
• JSON分析器（页面存档备份，存于）
• JSON到CSV转换器 （页面存档备份，存于）
• Minecraft指令─JSON文字格式 （页面存档备份，存于）
• JSON在线格式化工具