2010-09-30 9 views

risposta

74

Sì, un array è legale come testo JSON di primo livello.

Esistono tre documenti standard che definiscono JSON: RFC 4627, RFC 7159 (che obsoletes RFC 4627) e ECMA-404. Si differenziano per gli elementi di livello superiore che consentono, ma consentono tutti un oggetto o un array come elemento di livello superiore.

  • RFC 4627: Oggetto o matrice.
    "Un testo JSON è un oggetto o un array serializzato."
  • RFC 7159: Qualsiasi valore JSON.
    "Un testo JSON è un valore serializzato."
  • ECMA-404: Qualsiasi valore JSON.
    "Un testo JSON è una sequenza di token formata da punti di codice Unicode conformi alla grammatica del valore JSON ".
+1

A partire da [questo nuovo RFC] (http://www.ietf.org/rfc/rfc7159.txt), "Un testo JSON è una sequenza di token. Il set di token comprende sei caratteri strutturali, stringhe, numeri e tre nomi letterali. " – antak

2

sì, provalo qui.

http://www.jsonlint.com/

e mettere in [{}]

+2

È ancora più facile di così. Metti in '[]' e verrà convalidato. – Sorpigal

+2

@sorpigal true dat – hvgotcodes

+0

Il collegamento è guasto, si prega di aggiornare o rimuovere, questa-quasi-solo-risposta di collegamento. – Anthon

4

Questo è dalle specifiche ECMAScript.

 
JSONText : 
    JSONValue 

JSONValue : 
    JSONNullLiteral 
    JSONBooleanLiteral 
    JSONObject 
    JSONArray 
    JSONString 
    JSONNumber 
+1

Questo è un po 'fuorviante, però, perché ECMAScript consente di analizzare stringhe JSON che non sono testi di livello superiore. Secondo la RFC, "Un testo JSON è un oggetto o array serializzato". –

+0

@ Matthew - Strano, mi chiedo come si sente Crockford a riguardo. Come potranno riconciliare le differenze tra RFC e ECMA? – ChaosPandion

+3

Ho appena guardato, e ho scoperto che sono consapevoli della differenza. Da ECMAScript 5, paragrafo 15.12, "La produzione JSONText di livello superiore della grammatica JSON ECMAScript può essere costituita da qualsiasi JSONValue anziché essere limitata ad essere un JSONObject o JSONArray come specificato da RFC 4627." Non so se IETF cambierà la RFC. –

39

, ma si dovrebbe considerare la radice di un oggetto invece in alcuni scenari, a causa di JSON hijacking. Si tratta di una vulnerabilità legata all'intercettazione delle informazioni basata sull'override del costruttore di array in JavaScript.

+0

impressionante articolo –

+4

Sì, questo è il marchio di garanzia di una grande risposta - non solo dire all'OP ciò che volevano sapere, ma anche ciò che dovevano sapere (ma non si rendevano conto). In realtà, c'è una serie di vulnerabilità associate a JSON che analizza come Javascript, il dirottamento JSON è solo un esempio. – sleske

+5

FWIW, dirottamento JSON [non è un problema per i browser moderni] (http://stackoverflow.com/questions/16289894/is-json-hijacking-still-an-issue-in-modern-browsers). –

0

C'è un po 'di confusione, visto negli altri commenti. Il tipo di supporto "application/json" consente solo oggetti o array al livello principale per il testo JSON, per JSON RFC. Tuttavia, per un parser qualsiasi valore JSON è accettabile, come mostrato nelle specifiche ECMAScript.

+0

Qualsiasi valore JSON come elemento di livello superiore è accettabile per un parser _ECMAScript_, ma non per un parser _JSON (conforme) _ - importante distinzione. – sleske

+0

Questa è una distinzione interessante, ma non capisco cosa stai dicendo. Qual è la definizione di un "parser JSON" (compatibile) "? – cdunn2001

+1

Bene, un parser JSON è un parser per la grammatica JSON. Mentre JSON sembra simile a Javascript, è una grammatica diversa (molto più semplice). Vedi https://tools.ietf.org/html/rfc7159, che descrive la grammatica JSON. "compliant" significa solo che il parser segue effettivamente la grammatica (che dovrebbe essere qualsiasi parser decente). – sleske

Problemi correlati