blocks|key|2999974|text|在写这篇文章的时候，JSON只是用RFC4627描述的。它(在“2”的开头)将JSON文本描述为序列化的对象或数组。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2999975|这意味着在符合该标准的解析器和字符串器中，只有{}和[]是有效的、完整的JSON字符串。|style|CODE|2999976|然而，ECMA-404的引入改变了这一点，并更新了advice+can+be+read+here。我也在这个问题上使用了written+a+blog+post。|2999977|2999978|然而，更令人困惑的是，web浏览器中可用的JSON对象(例如JSON.parse()和JSON.stringify())是standardised+in+ES5，它清楚地定义了可接受的JSON文本，如下所示：|2999979|2999980|本规范中使用的JSON交换格式与RFC4627描述的格式完全相同，但有两个例外：|blockquote|2999981|2999982|2999983|2999984|+ECMAScript+JSON语法的顶级JSONText产品可以由任何JSONValue组成，而不是像RFC4627所指定的那样被限制为JSONObject或JSONArray。|unordered-list-item|2999985|2999986|2999987|snipped|2999988|2999989|这意味着所有JSON值(包括字符串、空值和数字)都被JSON对象接受，即使JSON对象在技术上遵守RFC4627。|2999990|请注意，因此您可以通过JSON.stringify(5)在符合规范的浏览器中对数字进行字符串化，这将被另一个符合RFC4627的解析器拒绝，但该解析器没有上面列出的特定异常。例如，would+seem+to+be+one+such+example+which++accepts+objects+and+arrays+as+the+root。另一方面，PHP+specifically+adds+the+exception说“它还将编码和解码标量类型和NULL”。|2999991|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ietf.org/rfc/rfc4627.txt|1|https://stackoverflow.com/questions/19569221/in-light-of-ecma-404-is-2-or-hello-considered-a-valid-json-text|2|http://www.mattlunn.me.uk/blog/2014/01/what-is-the-minimum-valid-json/|3|http://es5.github.io/#x15.12|4|http://www.ruby-doc.org/stdlib-2.0.0/libdoc/json/rdoc/JSON.html|5|http://us2.php.net/manual/en/function.json-decode.php#refsect1-function.json-decode-parameters^0|H|7|0|0|N|2|Q|2|0|W|G|1|1O|J|2|0|0|L|4|U|C|17|G|1P|J|3|0|0|0|0|0|0|0|0|0|0|0|0|B|H|2I|27|4|4Z|V|5|0^^$0|@$1|2|3|4|5|6|7|1N|8|@]|9|@$A|1O|B|1P|1|1Q]]|C|$]]|$1|D|3|E|5|6|7|1R|8|@$A|1S|B|1T|F|G]|$A|1U|B|1V|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|1W|8|@]|9|@$A|1X|B|1Y|1|1Z]|$A|20|B|21|1|22]]|C|$]]|$1|J|3|-4|5|6|7|23|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|24|8|@$A|25|B|26|F|G]|$A|27|B|28|F|G]|$A|29|B|2A|F|G]]|9|@$A|2B|B|2C|1|2D]]|C|$]]|$1|M|3|-4|5|6|7|2E|8|@]|9|@]|C|$]]|$1|N|3|O|5|P|7|2F|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|2H|8|@]|9|@]|C|$]]|$1|S|3|-4|5|6|7|2I|8|@]|9|@]|C|$]]|$1|T|3|U|5|V|7|2J|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|2K|8|@]|9|@]|C|$]]|$1|X|3|-4|5|6|7|2L|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|V|7|2M|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|2N|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|2O|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|2P|8|@$A|2Q|B|2R|F|G]]|9|@$A|2S|B|2T|1|2U]|$A|2V|B|2W|1|2X]]|C|$]]|$1|15|3|-4|5|6|7|2Y|8|@]|9|@]|C|$]]]|16|$17|$5|18|19|1A|C|$1B|1C]]|1D|$5|18|19|1A|C|$1B|1E]]|1F|$5|18|19|1A|C|$1B|1G]]|1H|$5|18|19|1A|C|$1B|1I]]|1J|$5|18|19|1A|C|$1B|1K]]|1L|$5|18|19|1A|C|$1B|1M]]]]

At the time of writing, JSON was solely described in <a href="http://www.ietf.org/rfc/rfc4627.txt" rel="noreferrer">RFC4627</a>. It describes (at the start of &quot;2&quot;) a JSON text as being a serialized object or array.
This means that only <code>{}</code> and <code>[]</code> are valid, complete JSON strings in parsers and stringifiers which adhere to that standard.
However, the introduction of ECMA-404 changes that, and the updated advice <a href="https://stackoverflow.com/questions/19569221/in-light-of-ecma-404-is-2-or-hello-considered-a-valid-json-text">can be read here</a>. I've also <a href="http://www.mattlunn.me.uk/blog/2014/01/what-is-the-minimum-valid-json/" rel="noreferrer">written a blog post</a> on the issue.
<hr />
To confuse the matter further however, the <code>JSON</code> object (e.g. <code>JSON.parse()</code> and <code>JSON.stringify()</code>) available in web browsers is <a href="http://es5.github.io/#x15.12" rel="noreferrer">standardised in ES5</a>, and that clearly defines the acceptable JSON texts like so:
<blockquote>
The JSON interchange format used in this specification is exactly that described by RFC 4627 with two exceptions:
<ul>
<li>The top level JSONText production of the ECMAScript JSON grammar may consist of any JSONValue rather than being restricted to being a JSONObject or a JSONArray as specified by RFC 4627.
</li>
<li>snipped
</li>
</ul>
</blockquote>
This would mean that all JSON values (including strings, nulls and numbers) are accepted by the JSON object, even though the JSON object technically adheres to RFC 4627.
Note that you could therefore stringify a number in a conformant browser via <code>JSON.stringify(5)</code>, which would be rejected by another parser that adheres to RFC4627, but which doesn't have the specific exception listed above. Ruby, for example, <a href="http://www.ruby-doc.org/stdlib-2.0.0/libdoc/json/rdoc/JSON.html" rel="noreferrer">would seem to be one such example which only accepts objects and arrays as the root</a>. PHP, on the other hand, <a href="http://us2.php.net/manual/en/function.json-decode.php#refsect1-function.json-decode-parameters" rel="noreferrer">specifically adds the exception</a> that &quot;it will also encode and decode scalar types and NULL&quot;.

blocks|key|176639|text|根据RFC+4627中的旧定义(2014年3月被RFC7159废弃)，这些都是有效的“JSON值”，但只有最后两个才构成完整的"JSON文本“：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|176640|176641|文本是序列化的对象或数组。|blockquote|176642|176643|176644|根据所使用的解析器，可能会接受单独的"JSON值“。例如(坚持使用"JSON值“与"JSON文本”术语)：|176645|176646|现在在现代浏览器中标准化的JSON.parse()函数接受任何“JSON值”|unordered-list-item|style|CODE|176647|+PHP函数json_decode是在版本5.2.0中引入的，只接受整个"JSON+text"，但在版本5.2.1|176648|Python's中被修改为接受任何“JSON值”根据示例on+this+manual+page|176649|the验证器接受任何“JSON值”http://jsonlint.com的验证器期望一个完整的"JSON文本“|176650|176651|+Ruby+JSON模块将只接受一个完整的"JSON文本”(至少根据注释JSON|176652|176653|这种区别有点像"XML文档“和"XML片段”之间的区别，尽管从技术上讲，<foo+/>是一个格式良好的XML文档(最好写成<?xml+version="1.0"+?><foo+/>，但正如注释中所指出的，<?xml声明在技术上是可选的)。|176654|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc4627|1|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse|2|http://php.net/json_decode|3|http://docs.python.org/2/library/json.html|4|http://jsonlint.com/^0|2|8|0|0|0|0|0|0|0|0|D|C|D|C|1|0|6|B|6|B|2|0|S|J|3|0|H|J|4|0|0|0|0|10|7|1P|T|2U|5|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|D|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1O|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1R|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]|$1|M|3|N|5|O|7|1T|8|@$A|1U|B|1V|P|Q]]|9|@$A|1W|B|1X|1|1Y]]|C|$]]|$1|R|3|S|5|O|7|1Z|8|@$A|20|B|21|P|Q]]|9|@$A|22|B|23|1|24]]|C|$]]|$1|T|3|U|5|O|7|25|8|@]|9|@$A|26|B|27|1|28]]|C|$]]|$1|V|3|W|5|O|7|29|8|@]|9|@$A|2A|B|2B|1|2C]]|C|$]]|$1|X|3|-4|5|O|7|2D|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|O|7|2E|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|2F|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|2G|8|@$A|2H|B|2I|P|Q]|$A|2J|B|2K|P|Q]|$A|2L|B|2M|P|Q]]|9|@]|C|$]]|$1|13|3|-4|5|6|7|2N|8|@]|9|@]|C|$]]]|14|$15|$5|16|17|18|C|$19|1A]]|1B|$5|16|17|18|C|$19|1C]]|1D|$5|16|17|18|C|$19|1E]]|1F|$5|16|17|18|C|$19|1G]]|1H|$5|16|17|18|C|$19|1I]]]]

According to the old definition in <a href="https://www.rfc-editor.org/rfc/rfc4627" rel="nofollow noreferrer">RFC 4627</a> (which was obsoleted in March 2014 by RFC 7159), those were all valid &quot;JSON values&quot;, but only the last two would constitute a complete &quot;JSON text&quot;:
<blockquote>
A JSON text is a serialized object or array.
</blockquote>
Depending on the parser used, the lone &quot;JSON values&quot; might be accepted anyway. For example (sticking to the &quot;JSON value&quot; vs &quot;JSON text&quot; terminology):
<ul>
<li>the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse" rel="nofollow noreferrer"><code>JSON.parse()</code></a> function now standardised in modern browsers accepts any &quot;JSON value&quot;</li>
<li>the PHP function <a href="http://php.net/json_decode" rel="nofollow noreferrer"><code>json_decode</code></a> was introduced in version 5.2.0 only accepting a whole &quot;JSON text&quot;, but was amended to accept any &quot;JSON value&quot; in version 5.2.1</li>
<li>Python's <code>json.loads</code> accepts any &quot;JSON value&quot; according to examples <a href="http://docs.python.org/2/library/json.html" rel="nofollow noreferrer">on this manual page</a></li>
<li>the validator at <a href="http://jsonlint.com" rel="nofollow noreferrer">http://jsonlint.com</a> expects a full &quot;JSON text&quot;</li>
<li>the Ruby JSON module will only accept a full &quot;JSON text&quot; (at least according to the comments <a href="http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.html" rel="nofollow noreferrer">on this manual page</a>)</li>
</ul>
The distinction is a bit like the distinction between an &quot;XML document&quot; and an &quot;XML fragment&quot;, although technically <code>&lt;foo /&gt;</code> is a well-formed XML document (it would be better written as <code>&lt;?xml version=&quot;1.0&quot; ?&gt;&lt;foo /&gt;</code>, but as pointed out in comments, the <code>&lt;?xml</code> declaration is technically optional).

blocks|key|2787676|text|是的，是的，是的。它们都是有效的JSON值文字。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2787677|然而，官方的RFC+4627声明：|offset|length|2787678|2787679|文本是序列化的对象或数组。|blockquote|2787680|2787681|2787682|因此，一个完整的“文件”应该包含一个对象或数组作为最外层的结构，当然也可以是空的。然而，许多JSON解析器也接受原始值作为输入。|2787683|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ietf.org/rfc/rfc4627.txt^0|0|6|8|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|11|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

Yes, yes, yes, yes, and yes. All of them are valid JSON value literals.

However, the official <a href="http://www.ietf.org/rfc/rfc4627.txt" rel="nofollow">RFC 4627</a> states:

<blockquote>
 A JSON text is a serialized object or array.
</blockquote>

So a whole "file" should consist of an object or array as the outermost structure, which of course can be empty. Yet, many JSON parsers accept primitive values as well for input.

blocks|key|176684|text|ecma规范可能对参考很有用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|176685|http://www.ecma-international.org/ecma-262/5.1/|offset|length|176686|176687|解析函数解析JSON文本(一个JSON格式的字符串)并生成一个JSON值。JSON格式是ECMAScript文字的一种受限形式。JSON对象被实现为ECMAScript对象。JSON数组被实现为ECMAScript数组。ECMAScript字符串、数字、布尔值和null被实现为JSON字符串、数字、布尔值和null。JSON使用比WhiteSpace更有限的空白字符集，并允许Unicode代码点U%2B2028和U%2B2029直接出现在JSONString文字中，而不使用转义序列。解析过程类似于受JSON语法约束的11.1.4和11.1.5。|blockquote|176688|176689|176690|JSON.parse("string");+//+SyntaxError:+Unexpected+token+s
JSON.parse(43);+//+43
JSON.parse("43");+//+43
JSON.parse(true);+//+true
JSON.parse("true");+//+true
JSON.parse(false);
JSON.parse("false");
JSON.parse("trueee");+//+SyntaxError:+Unexpected+token+e
JSON.parse("{}");+//+{}
JSON.parse("[]");+//+[]|code-block|syntax|javascript|176691|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1B|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|13|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|16|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|C]]]]

The ecma specification might be useful for reference:

<a href="http://www.ecma-international.org/ecma-262/5.1/" rel="nofollow">http://www.ecma-international.org/ecma-262/5.1/</a>

<blockquote>
 The parse function parses a JSON text (a JSON-formatted String) and produces an ECMAScript value. The 
 JSON format is a restricted form of ECMAScript literal. JSON objects are realized as ECMAScript objects. 
 JSON arrays are realized as ECMAScript arrays. JSON strings, numbers, booleans, and null are realized as 
 ECMAScript Strings, Numbers, Booleans, and null. JSON uses a more limited set of white space characters 
 than WhiteSpace and allows Unicode code points U+2028 and U+2029 to directly appear in JSONString literals 
 without using an escape sequence. The process of parsing is similar to 11.1.4 and 11.1.5 as constrained by 
 the JSON grammar.
</blockquote>

<pre><code>JSON.parse("string"); // SyntaxError: Unexpected token s
JSON.parse(43); // 43
JSON.parse("43"); // 43
JSON.parse(true); // true
JSON.parse("true"); // true
JSON.parse(false);
JSON.parse("false");
JSON.parse("trueee"); // SyntaxError: Unexpected token e
JSON.parse("{}"); // {}
JSON.parse("[]"); // []
</code></pre>

blocks|key|2787753|text|JSON代表JavaScript+Object+Notation。只有{}和[]定义Javascript对象。其他的例子是值字面量。Javascript中有用于处理这些值的对象类型，但表达式"string"是文字值的源代码表示，而不是对象。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2787754|请记住，JSON不是Javascript。它是一种表示数据的符号。它有一个非常简单和有限的结构。JSON数据是使用{},:[]字符构成的。您只能在该结构中使用文字值。|2787755|对于服务器来说，使用对象描述或文字值进行响应是完全有效的。所有JSON解析器都应该被处理为只处理一个文字值，但只能处理一个值。JSON一次只能表示一个对象。因此，对于返回多个值的服务器，它必须将其结构化为对象或数组。|2787756|entityMap^0|Z|2|12|2|2N|8|0|1L|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|K|$]]

JSON stands for JavaScript Object Notation. Only <code>{}</code> and <code>[]</code> define a Javascript object. The other examples are value literals. There are object types in Javascript for working with those values, but the expression <code>"string"</code> is a source code representation of a literal value and not an object.

Keep in mind that JSON is not Javascript. It is a notation that represents data. It has a very simple and limited structure. JSON data is structured using <code>{},:[]</code> characters. You can only use literal values inside that structure.

It is perfectly valid for a server to respond with either an object description or a literal value. All JSON parsers should be handle to handle just a literal value, but only one value. JSON can only represent a single object at a time. So for a server to return more than one value it would have to structure it as an object or an array.

blocks|key|178788|text|var+x;
JSON.stringify(x);+//+will+output+"{}"|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|178789|所以你的答案是"{}"，它表示一个空对象。|unstyled|offset|length|style|CODE|178790|entityMap^0|0|7|4|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|N|8|@$G|O|H|P|I|J]]|9|@]|A|$]]|$1|K|3|-4|5|F|7|Q|8|@]|9|@]|A|$]]]|L|$]]

<pre><code>var x;
JSON.stringify(x); // will output "{}"
</code></pre>

So your answer is <code>"{}"</code> which denotes an empty object.

blocks|key|178129|text|只需遵循json.org页面上给出的铁路示意图即可。[]和{}是最小可能的有效JSON对象。所以答案是[]和{}。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|178130|entityMap|0|LINK|mutability|MUTABLE|url|http://json.org/^0|4|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Just follow the railroad diagrams given on the <a href="http://json.org/" rel="nofollow">json.org</a> page. [] and {} are the minimum possible valid JSON objects. So the answer is [] and {}.

blocks|key|3000253|text|在互联网上至少有四个文档可以被认为是JSON标准。引用的RFC都描述了mime类型application/json。下面是每个人对顶层值的看法，以及是否允许在顶层使用除对象或数组之外的任何内容：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3000254|：No.|BOLD|3000255|JSON文本是一系列的|3000256|。这组令牌包括六个结构字符、字符串、数字和三个文字名称。|blockquote|3000257|3000258|JSON文本是序列化的对象或数组。|3000259|JSON-text+=对象/数组|3000260|请注意，RFC-4627被标记为“信息性的”，而不是“建议的标准”，并且它已被RFC-7159淘汰，而RFC-8259又被废弃。|3000261|：是的。|3000262|3000263|3000264|3000265|JSON文本是序列化的值。请注意，以前的某些JSON规范将JSON文本约束为对象或数组。只生成调用JSON文本的对象或数组的实现将是可互操作的，因为所有实现都会将它们接受为符合JSON文本。|3000266|JSON-text+=+ws值ws|3000267|RFC-8259的日期为2017年12月，并被标记为“互联网标准”。|3000268|3000269|JSON语法语法根据|3000270|词法语法定义的标记来定义有效的JSON文本。语法的目标符号是JSONText。|3000271|3000272|语法JSONText：|3000273|JSONValue+JSONValue：|3000274|JSONNullLiteral+JSONBooleanLiteral+JSONObject+JSONArray+JSONString+JSONNumber|3000275|3000276|3000277|+JSON文本是由符合JSON值语法的Unicode码点组成的标记序列。这组标记包括六个结构标记、字符串、数字和三个文字名称标记。|3000278|3000279|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7159^0|15|G|0|1|3|0|0|0|0|0|0|13|8|0|0|1|3|0|0|0|0|0|0|0|1|3|0|0|0|0|0|0|0|1|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1X|8|@$9|1Y|A|1Z|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|20|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|21|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|22|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|23|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|24|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|25|8|@]|D|@$9|26|A|27|1|28]]|E|$]]|$1|U|3|V|5|6|7|29|8|@$9|2A|A|2B|B|H]]|D|@]|E|$]]|$1|W|3|J|5|6|7|2C|8|@]|D|@]|E|$]]|$1|X|3|L|5|M|7|2D|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2F|8|@]|D|@]|E|$]]|$1|11|3|12|5|6|7|2G|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|2H|8|@]|D|@]|E|$]]|$1|15|3|V|5|6|7|2I|8|@$9|2J|A|2K|B|H]]|D|@]|E|$]]|$1|16|3|17|5|6|7|2L|8|@]|D|@]|E|$]]|$1|18|3|19|5|M|7|2M|8|@]|D|@]|E|$]]|$1|1A|3|-4|5|6|7|2N|8|@]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|2O|8|@]|D|@]|E|$]]|$1|1D|3|1E|5|6|7|2P|8|@]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|2Q|8|@]|D|@]|E|$]]|$1|1H|3|V|5|6|7|2R|8|@$9|2S|A|2T|B|H]]|D|@]|E|$]]|$1|1I|3|-4|5|6|7|2U|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|M|7|2V|8|@]|D|@]|E|$]]|$1|1L|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]|$1|1M|3|-4|5|6|7|2X|8|@]|D|@]|E|$]]]|1N|$1O|$5|1P|1Q|1R|E|$1S|1T]]]]

There are at least four documents which can be considered JSON standards on the Internet. The RFCs referenced all describe the mime type <code>application/json</code>. Here is what each has to say about the top-level values, and whether anything other than an object or array is allowed at the top:
<a href="https://www.rfc-editor.org/rfc/rfc4627" rel="nofollow noreferrer">RFC-4627</a>: No.
<blockquote>
A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
A JSON text is a serialized object or array.
<blockquote>
JSON-text = object / array
</blockquote>
</blockquote>
Note that RFC-4627 was marked &quot;informational&quot; as opposed to &quot;proposed standard&quot;, and that it is obsoleted by <a href="https://www.rfc-editor.org/rfc/rfc7159" rel="nofollow noreferrer">RFC-7159</a>, which in turn is obsoleted by RFC-8259.
<a href="https://www.rfc-editor.org/rfc/rfc8259" rel="nofollow noreferrer">RFC-8259</a>: Yes.
<blockquote>
A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
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.
<blockquote>
JSON-text = ws value ws
</blockquote>
</blockquote>
RFC-8259 is dated December 2017 and is marked &quot;INTERNET STANDARD&quot;.
<a href="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf" rel="nofollow noreferrer">ECMA-262</a>: Yes.
<blockquote>
The JSON Syntactic Grammar defines a valid JSON text in terms of tokens defined by the JSON lexical
grammar. The goal symbol of the grammar is JSONText.
Syntax
JSONText :
<blockquote>
JSONValue
</blockquote>
JSONValue :
<blockquote>
JSONNullLiteral
</blockquote>
<blockquote>
JSONBooleanLiteral
</blockquote>
<blockquote>
JSONObject
</blockquote>
<blockquote>
JSONArray
</blockquote>
<blockquote>
JSONString
</blockquote>
<blockquote>
JSONNumber
</blockquote>
</blockquote>
<a href="http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf" rel="nofollow noreferrer">ECMA-404</a>: Yes.
<blockquote>
A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value
grammar. The set of tokens includes six structural tokens, strings, numbers, and three literal name tokens.
</blockquote>

I've carefully read the JSON description <a href="http://json.org/">http://json.org/</a> but I'm not sure I know the answer to the simple question. What strings are the minimum possible valid JSON?

<ul>
<li><code>"string"</code> is the string valid JSON?</li>
<li><code>42</code> is the simple number valid JSON?</li>
<li><code>true</code> is the boolean value a valid JSON?</li>
<li><code>{}</code> is the empty object a valid JSON?</li>
<li><code>[]</code> is the empty array a valid JSON?</li>
</ul>

What is the minimum valid JSON?

服务器

JSON

我仔细阅读了的JSON描述，但我不确定我是否知道这个简单问题的答案。什么字符串是最低可能的有效JSON？"string"是字符串有效的JSON?42是简单数字有效的JSON?true是布尔值有效的JSON?{}是空对象有效的JSON?[]是空数组有效的JSON?

问最低有效JSON是多少？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问最低有效JSON是多少？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问最低有效JSON是多少？
EN