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

105

согласно дискуссии в этом сообщении: json-conversion-in-javascript

arrays json rfc4627

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