Quel est le JSON minimum valide?

J'ai lu attentivement la description JSON http://json.org/ mais je ne suis pas sûr de connaître la réponse à la question simple. Quelles chaînes sont le minimum JSON valide possible?

• "string" la chaîne est-elle valide JSON?
• 42 le nombre simple est-il JSON valide?
• true la valeur booléenne est-elle un JSON valide?
• {} l'objet vide est-il un JSON valide?
• [] le tableau vide est-il un JSON valide?

Au moment de la rédaction de cet article, JSON était uniquement décrit dans la RFC4627 . Il décrit (au début de «2») un texte JSON comme étant un objet ou un tableau sérialisé.

Cela signifie que seules {} et []sont valides, des chaînes JSON complètes dans des analyseurs et des stringifiers qui adhèrent à cette norme.

Cependant , l'introduction de l'ECMA-404 change cela, et les conseils mis à jour peuvent être lus ici . J'ai également écrit un article de blog sur la question.

Cependant, pour compliquer davantage les choses, l' JSONobjet (par exemple JSON.parse()et JSON.stringify()) disponible dans les navigateurs Web est normalisé dans ES5 , et cela définit clairement les textes JSON acceptables comme suit:

Le format d'échange JSON utilisé dans cette spécification est exactement celui décrit par RFC 4627 à deux exceptions près:

• La production JSONText de niveau supérieur de la grammaire JSON ECMAScript peut consister en n'importe quelle valeur JSONValue plutôt que d'être limitée à un JSONObject ou un JSONArray comme spécifié par la RFC 4627.

• coupé

Cela signifierait que toutes les valeurs JSON (y compris les chaînes, les valeurs nulles et les nombres) sont acceptées par l'objet JSON, même si l'objet JSON adhère techniquement à la RFC 4627.

Notez que vous pouvez donc stringifier un nombre dans un navigateur conforme via JSON.stringify(5), qui serait rejeté par un autre analyseur qui adhère à RFC4627, mais qui n'a pas l'exception spécifique répertoriée ci-dessus. Ruby, par exemple, semble être un exemple qui n'accepte des objets et des tableaux comme la racine . PHP, d'autre part, ajoute spécifiquement l'exception selon laquelle "il codera et décodera également les types scalaires et NULL".

Il existe au moins quatre documents qui peuvent être considérés comme des normes JSON sur Internet. Les RFC référencées décrivent toutes le type mime application/json. Voici ce que chacun a à dire sur les valeurs de niveau supérieur et si autre chose qu'un objet ou un tableau est autorisé en haut:

RFC-4627 : Non.

Un texte JSON est une séquence de jetons. L'ensemble de jetons comprend six caractères structurels, des chaînes, des nombres et trois noms littéraux.

Un texte JSON est un objet ou un tableau sérialisé.

JSON-text = objet / tableau

Notez que la RFC-4627 a été marquée «informationnelle» par opposition à «norme proposée», et qu'elle est obsolète par la RFC-7159 , qui à son tour est obsolète par la RFC-8259.

RFC-8259 : Oui.

Un texte JSON est une séquence de jetons. L'ensemble de jetons comprend six caractères structurels, des chaînes, des nombres et trois noms littéraux.

Un texte JSON est une valeur sérialisée. Notez que certaines spécifications précédentes de JSON contraignaient un texte JSON à être un objet ou un tableau. Les implémentations qui génèrent uniquement des objets ou des tableaux pour lesquels un texte JSON est demandé seront interopérables dans le sens où toutes les implémentations les accepteront comme des textes JSON conformes.

JSON-text = valeur ws ws

La RFC-8259 date de décembre 2017 et porte la mention "INTERNET STANDARD".

ECMA-262 : Oui.

La grammaire syntaxique JSON définit un texte JSON valide en termes de jetons définis par la grammaire lexicale JSON. Le symbole de but de la grammaire est JSONText.

Syntaxe JSONText:

JSONValue

JSONValue:

JSONNullLiteral

JSONBooleanLiteral

JSONObject

JSONArray

JSONString

JSONNumber

ECMA-404 : Oui.

Un texte JSON est une séquence de jetons formée à partir de points de code Unicode conforme à la grammaire des valeurs JSON. L'ensemble de jetons comprend six jetons structurels, des chaînes, des nombres et trois jetons de nom littéraux.

Selon l'ancienne définition de la RFC 4627 (qui était obsolète en mars 2014 par la RFC 7159), il s'agissait toutes de «valeurs JSON» valides, mais seules les deux dernières constitueraient un «texte JSON» complet:

Un texte JSON est un objet ou un tableau sérialisé.

Selon l'analyseur utilisé, les seules "valeurs JSON" peuvent être acceptées de toute façon. Par exemple (en respectant la terminologie "valeur JSON" et "texte JSON"):

• la JSON.parse()fonction désormais standardisée dans les navigateurs modernes accepte toute "valeur JSON"
• la fonction PHP a json_decodeété introduite dans la version 5.2.0 n'acceptant qu'un "texte JSON" entier, mais a été modifiée pour accepter toute "valeur JSON" dans la version 5.2.1
• Python json.loadsaccepte toute "valeur JSON" selon les exemples de cette page de manuel
• le validateur sur http://jsonlint.com attend un "texte JSON" complet
• le module Ruby JSON n'acceptera qu'un "texte JSON" complet (du moins selon les commentaires sur cette page de manuel )

La distinction est un peu comme la distinction entre un "document XML" et un "fragment XML", bien que techniquement <foo />soit un document XML bien formé (il serait préférable de l'écrire comme <?xml version="1.0" ?><foo />, mais comme indiqué dans les commentaires, la <?xmldéclaration est techniquement facultative ).

La spécification ecma peut être utile pour référence:

http://www.ecma-international.org/ecma-262/5.1/

La fonction d'analyse analyse un texte JSON (une chaîne au format JSON) et produit une valeur ECMAScript. Le format JSON est une forme restreinte de littéral ECMAScript. Les objets JSON sont réalisés en tant qu'objets ECMAScript. Les tableaux JSON sont réalisés comme des tableaux ECMAScript. Les chaînes JSON, les nombres, les booléens et les valeurs nulles sont réalisés sous forme de chaînes ECMAScript, de nombres, de booléens et de null. JSON utilise un ensemble plus limité de caractères d'espace blanc que WhiteSpace et permet aux points de code Unicode U + 2028 et U + 2029 d'apparaître directement dans les littéraux JSONString sans utiliser de séquence d'échappement. Le processus d'analyse est similaire à 11.1.4 et 11.1.5 car contraint par la grammaire JSON.

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("[]"); // []

JSON signifie JavaScript Object Notation. Seulement {}et []définissez un objet Javascript. Les autres exemples sont des valeurs littérales. Il existe des types d'objet en Javascript pour travailler avec ces valeurs, mais l'expression "string"est une représentation en code source d'une valeur littérale et non d'un objet.

Gardez à l'esprit que JSON n'est pas Javascript. C'est une notation qui représente des données. Il a une structure très simple et limitée. Les données JSON sont structurées à l'aide de {},:[]caractères. Vous ne pouvez utiliser que des valeurs littérales à l'intérieur de cette structure.

Il est parfaitement valide pour un serveur de répondre avec une description d'objet ou une valeur littérale. Tous les analyseurs JSON doivent être gérés pour ne gérer qu'une valeur littérale, mais une seule valeur. JSON ne peut représenter qu'un seul objet à la fois. Donc, pour qu'un serveur renvoie plus d'une valeur, il devrait la structurer comme un objet ou un tableau.

Oui, oui, oui, oui et oui. Tous sont des littéraux de valeur JSON valides.

Cependant, la RFC 4627 officielle déclare:

Un texte JSON est un objet ou un tableau sérialisé.

Ainsi, un "fichier" entier doit être constitué d'un objet ou d'un tableau en tant que structure la plus externe, qui bien sûr peut être vide. Pourtant, de nombreux analyseurs JSON acceptent également les valeurs primitives en entrée.

var x;
JSON.stringify(x); // will output "{}"

Donc, votre réponse est "{}"qui désigne un objet vide.

Suivez simplement les schémas de chemin de fer donnés sur la page json.org . [] et {} sont les objets JSON valides minimum possibles. La réponse est donc [] et {}.