Может ли массив быть JSON-текстом верхнего уровня?

Ответы:

126

Да, массив разрешен как JSON-текст верхнего уровня.

Существует три стандартных документа, определяющих JSON: RFC 4627 , RFC 7159 (который устарел RFC 4627) и ECMA-404 . Они различаются тем, какие элементы верхнего уровня они разрешают, но все допускают объект или массив в качестве элемента верхнего уровня.

  • RFC 4627: объект или массив.
    «Текст JSON - это сериализованный объект или массив».
  • RFC 7159: любое значение JSON.
    «Текст JSON - это сериализованное значение».
  • ECMA-404: любое значение JSON.
    «Текст JSON - это последовательность токенов, сформированная из кодовых точек Unicode, которая соответствует грамматике значений JSON».
слеске
источник
2
Что касается этого более нового RFC , «Текст JSON представляет собой последовательность токенов. Набор токенов включает шесть структурных символов, строки, числа и три буквальных имени».
antak
64

Да , но вам следует подумать о том, чтобы сделать корень объектом вместо этого в некоторых сценариях из-за перехвата JSON . Это уязвимость раскрытия информации, основанная на переопределении конструктора массива в JavaScript.

Мэтью Флашен
источник
11
Да, это отличительный признак отличного ответа - сообщить ОП не только то, что они хотели знать, но и то, что они должны были знать (но не осознавали). На самом деле, существует множество уязвимостей, связанных с JSON, который анализируется как Javascript, захват JSON - лишь один из примеров.
sleske 01
9
FWIW, захват JSON не является проблемой для современных браузеров .
Франклин Ю,
4

Это из спецификации ECMAScript.

JSONText:
    JSONValue

JSONValue:
    JSONNullLiteral 
    JSONBooleanLiteral 
    JSONObject 
    JSONArray 
    JSONString 
    JSONNumber
ХаосПандион
источник
1
Это немного вводит в заблуждение, поскольку ECMAScript позволяет анализировать строки JSON, которые не являются текстами верхнего уровня. Согласно RFC, «Текст JSON - это сериализованный объект или массив».
Мэтью Флашен,
@ Мэтью - Странно, мне интересно, как Крокфорд думает об этом. Как они будут согласовывать различия между RFC и ECMA?
ChaosPandion
3
Я просто посмотрел и обнаружил, что они понимают разницу. Из ECMAScript 5 §15.12: «Производство JSONText верхнего уровня грамматики ECMAScript JSON может состоять из любого JSONValue, а не ограничиваться JSONObject или JSONArray, как указано в RFC 4627». Я не знаю, изменит ли IETF RFC.
Мэтью Флашен,
@Matthew - Спасибо, я ужасно запутался. Описание json.org не говоря уже о более ограничительное понятие «JSON-текст» на всех , и вид RFC , по расплывчатым о его значении.
mrec
Этот ответ касается ECMAScript, но вопрос касается JSON. Хотя они (намеренно) выглядят похожими, это разные характеристики .
sleske 01
2

да, попробуйте здесь.

http://www.jsonlint.com/

и вставьте [{}]

hvgotcodes
источник
3
Это даже проще, чем это. Вставьте, []и он подтвердит.
sorpigal
Ссылка мертва, обновите или удалите этот ответ - почти только по ссылке.
Anthon
1

Есть некоторая путаница, замеченная в других комментариях. Тип мультимедиа «application / json» позволяет использовать только объект или массив на верхнем уровне для текста JSON в соответствии с JSON RFC . Однако для парсера приемлемо любое значение JSON, как показано в спецификации ECMAScript.

cdunn2001
источник
Любое значение JSON в качестве элемента верхнего уровня приемлемо для парсера ECMAScript , но не для (совместимого) парсера JSON - важное различие.
sleske 01
Это интересное различие, но я не понимаю, о чем вы говорите. Каково определение «(совместимого) парсера JSON»?
cdunn2001
1
Что ж, парсер JSON - это парсер грамматики JSON. Хотя JSON похож на Javascript, это другая (гораздо более простая) грамматика. См. Tools.ietf.org/html/rfc7159 , в котором описывается грамматика JSON. "совместимый" просто означает, что синтаксический анализатор действительно следует грамматике (что должно быть любым приличным синтаксическим анализатором).
sleske
3
RFC 4627 устарел, пожалуйста, не следуйте ему больше. Новый RFC допускает также простые значения на верхнем уровне.
Matthias Dieter Wallnöfer