Что такое парсинг json

JSON.parse()

Обычно JSON используется для обмена данными с сервером.

При получении с сервера данные всегда передаются в виде строки.

Если обработать эти данные при помощи функции JSON.parse(), то они станут объектом JavaScript.

Парсинг данных JSON

Представьте, что с сервера мы получили такой текст:

Используем JavaScript функцию JSON.parse(), чтобы преобразовать этот текст в объект JavaScript:

Внимание! Убедитесь, что преобразуемый текст записан в формате JSON, иначе вы получите ошибку синтаксиса.

Используем полученный объект JavaScript на странице:

Получение данных JSON с сервера

Получить данные JSON с сервера можно, например, используя запрос AJAX.

Так как ответ сервера записан в формате JSON, вы можете преобразовать строку в объект JavaScript.

В следующем примере используется XMLHttpRequest, чтобы получить данные с сервера:

Массивы как данные JSON

Если функция JSON.parse() используется для парсинга данных JSON, полученных из массива, то будет возвращен массив JavaScript, а не объект.

В следующем примере возвращенные с сервера данные JSON являются массивом:

Парсинг дат

Объекты даты и времени (тип Date) нельзя использовать в JSON.

Если вам необходимо включить в данные дату, записывайте ее как строку.

Когда это потребуется, вы сможете преобразовать ее обратно в объект:

Либо можно воспользоваться вторым параметром функции JSON.parse().

В качестве второго параметра передается функция, которая проверяет каждое свойство перед тем, как вернуть его значение.

В следующем примере строка преобразуется в объект даты, при помощи второго параметра JSON.parse():

Парсинг функций

Функции нельзя использовать в JSON.

Если вам необходимо включить в данные функцию, записывайте ее как строку.

Когда это потребуется, вы сможете преобразовать ее обратно в функцию:

Внимание! Следует избегать использования функций в JSON, так как в этом случае теряется их область видимости, а для обратного преобразования приходится использовать функцию eval(), что нежелательно.

Источник

JavaScript JSON Парсинг

Обычно JSON используется для обмена данными с веб сервером.

При получении данных с веб сервера они всегда представляют собой строку.

Представьте, что мы получили этот текст с веб сервера:

Используйте функцию JavaScript JSON.parse() для преобразования текста в объект JavaScript:

Убедитесь, что текст написан в формате JSON, иначе вы получите синтаксическую ошибку.

Используйте объект JavaScript на своей странице:

Пример

JSON с сервера

Вы можете запросить JSON с сервера, используя AJAX запрос

Пока ответ от сервера записан в формате JSON, вы можете проанализировать строку в объект JavaScript.

Пример

Используйте XMLHttpRequest для получения данных с сервера:

JSON массив

При использовании JSON.parse() на JSON, производном от массива, метод вернет массив JavaScript, а не объект JavaScript.

Пример

JSON, возвращенный с сервера, представляет собой массив:

Исключения

Разбор дат

Объекты дат не допускаются в JSON.

Если вам нужно включить дату, запишите ее в виде строки.

Вы можете преобразовать его обратно в объект даты позже:

Пример

Преобразование строки в дату:

document.getElementById(«demo»).innerHTML = obj.name + «, » + obj.birth;

Пример

Преобразовать строку в дату, используя функцию восстановления:

document.getElementById(«demo»).innerHTML = obj.name + «, » + obj.birth;

Парсинг функции

Функции не разрешены в JSON.

Если вам нужно включить функцию, запишите ее в виде строки.

Вы можете преобразовать его обратно в функцию позже:

Пример

Преобразование строки в функцию::

document.getElementById(«demo»).innerHTML = obj.name + «, » + obj.age();

Поддержка браузеров

Функция JSON.parse() включена во все основные браузеры и в новейший стандарт ECMAScript (JavaScript).

Числа в таблице ниже указывают первую версию браузера, которая полностью поддерживает функция JSON.parse() :

Для старых браузеров библиотека JavaScript доступна по адресу https://github.com/douglascrockford/JSON-js.

Упражнения

Тесты

КАК СДЕЛАТЬ

ПОДЕЛИТЬСЯ

СЕРТИФИКАТЫ

Сообщить об ошибке

Если вы хотите сообщить об ошибке или сделать предложение, не стесняйтесь, присылайте нам электронное письмо:

Ваше предложение:

Спасибо, за вашу помощь!

Ваше сообщение было отправлено в SchoolsW3.

Топ Учебники

Топ Справочники

Топ Примеры

Веб Сертификаты

Источник

Руководство по парсингу JSON в JavaScript

JSON означает JavaScript Object Notation. JSON — это чрезвычайно легкий формат обмена данными между сервером и клиентом, который можно быстро и легко анализировать и генерировать.

Как и XML, JSON также является текстовым форматом, который легко написать и легко понять как для людей, так и для компьютеров, но в отличие от XML структуры данных JSON занимают меньшую пропускную способность, чем их версии XML. JSON основан на двух основных структурах:

Пример массива JSON будет выглядеть примерно так:

JSON — это самый популярный и легкий текстовый формат обмена данными между различными платформами и операционными системами.

Разбор данных JSON в JavaScript

Предположим, мы получили следующую JSON-кодированную строку с веб-сервера:

Пожалуйста, ознакомьтесь с руководством по синтаксическому анализу PHP JSON, чтобы узнать, как в ответ возвращать данные JSON с веб-сервера, а также как кодировать / декодировать данные JSON на стороне сервера с использованием PHP.

Разбор вложенных данных JSON в JavaScript

Объекты и массивы JSON также могут быть вложенными. Объект JSON может произвольно содержать другие объекты JSON, массивы, вложенные массивы, массивы объектов JSON и т. д. В следующем примере показано, как проанализировать вложенный объект JSON и извлечь все значения в JavaScript.

Кодирование данных как JSON в JavaScript

Stringify-объект JavaScript

В следующем примере показано, как преобразовать объект JavaScript в строку JSON:

Хотя объекты JavaScript и JSON выглядят очень похоже, но они не совсем одинаковы. Например, в JavaScript имена свойств объекта могут быть заключены в одинарные кавычки ( ‘. ‘ ), двойные кавычки ( «. » ) или же вы можете вообще опустить кавычки. Но в JSON все имена свойств должны быть заключены в двойные кавычки.

Stringify-массив JavaScript

Точно так же вы можете конвертировать массивы JavaScript в строки JSON, например:

Не используйте функцию eval() для оценки данных JSON (включая определения функций в строке JSON и преобразование их обратно в исполняемые функции с помощью метода eval() ), поскольку это позволит злоумышленнику внедрить вредоносный код JavaScript в ваше приложение.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 5 / 5. Количество оценок: 1

Оценок пока нет. Поставьте оценку первым.

Похожие посты

Руководство по сортировке массивов в JavaScript

Руководство по массивам в JavaScript

Руководство по работе с атрибутами DOM в JavaScript

Разработка сайтов для бизнеса

Если у вас есть вопрос, на который вы не знаете ответ — напишите нам, мы поможем разобраться. Мы всегда рады интересным знакомствам и новым проектам.

Источник

Работа с JSON

Нет, действительно, что такое JSON?

JSON существует как строка,что необходимо при передаче данных по сети. Он должен быть преобразован в собственный объект JavaScript, если вы хотите получить доступ к данным. Это не большая проблема. JavaScript предоставляет глобальный объект JSON, который имеет методы для преобразования между ними.

Структура JSON

Чтобы получить доступ к последующим данным по иерархии, вам просто нужно объединить требуемые имена свойств и индексы массивов. Например, чтобы получить доступ к третьей сверхспособности второго героя, указанного в списке участников, вы должны сделать следующее:

Примечание. Мы сделали JSON, видимый выше, доступным внутри переменной в нашем примере JSONTest.html (см. исходный код). Попробуйте загрузить это, а затем получить доступ к данным внутри переменной через консоль JavaScript вашего браузера.

Массивы как JSON

Другие примечания

Активное обучение: Работа с примером JSON

Итак, давайте рассмотрим пример, чтобы показать то, как мы можем использовать некоторые данные JSON на веб-сайте.

Источник

Парсинг JSON — это минное поле

JSON — это стандарт де-факто, когда заходит речь о (де)сериализации, обмене данными в сети и мобильной разработке. Но насколько хорошо вы знакомы с JSON? Все мы читаем спецификации и пишем тесты, испытываем популярные JSON-библиотеки для своих нужд. Я покажу вам, что JSON — это идеализированный формат, а не идеальный, каким его многие считают. Я не нашёл и двух библиотек, ведущих себя одинаково. Более того, я обнаружил, что крайние случаи и зловредная полезная нагрузка могут привести к багам, падениями и DoS, в основном потому, что JSON-библиотеки основаны на спецификациях, которые со временем развиваются, что оставляет многие вещи плохо или вообще не задокументированными.

1. Спецификации JSON

JSON — стандарт де-факто сериализации при передаче данных по HTTP, лингва франка для обмена данными между гетерогенными приложениями как в веб-, так и в мобильной разработке.

В 2001 году Дуглас Крокфорд разработал такую короткую и простую спецификацию JSON, что это породило возникновение визитных карточек, на обратной стороне которых печатали полную грамматику JSON.

JSON используют практически все пользователи интернета и программисты, но лишь немногие действительно пришли к согласию относительно того, как должен работать JSON. Краткость грамматики оставляет многие аспекты неопределёнными. К тому же существует несколько спецификаций и их мутных интерпретаций.

Крокфорд решил не версионировать JSON:

Вероятно, моим самым смелым дизайн-решением стал отказ от присвоения JSON номерных версий, поэтому отсутствует механизм внесения изменений. Мы застряли с JSON: что бы ни представляла собой его текущая форма, он только такой.

Кроме того, JSON определяется как минимум в шести разных документах:

Кто-то сказал рабочей группе ECMA, что IETF спятила и собралась переписать JSON без оглядки на совместимость и поломку всего интернета, и с этой ужасной ситуацией нужно срочно что-то делать. Это не имеет никакого отношения к жалобам, которые повлияли на ревизию со стороны IETF.

Также RFC 7159 не проясняет, как JSON-парсер должен обращаться с предельными числовыми значениями (extreme number values), искажёнными Unicode-строками, одинаковыми объектами или глубиной рекурсии. Одни тупиковые ситуации явно оставлены без реализаций, а другие страдают от противоречивых высказываний.

Чтобы проиллюстрировать неточность RFC 7159, я написал сборник тестовых JSON-файлов и задокументировал, как конкретные JSON-парсеры их обрабатывают. Ниже вы увидите, что не всегда легко решить, стоит ли парсить тот или иной тестовый файл. В своих изысканиях я обнаружил, что все парсеры ведут себя по-разному, и это может приводить к серьёзным проблемам с совместимостью.

2. Тестирование парсинга

Далее я объясню, как создать тестовые файлы для проверки поведения парсеров, расскажу о некоторых интересных тестах и обосную, должны ли парсеры, соответствующие критериям RFC 7159, принимать или отвергать файлы — либо же решать самостоятельно.

Имена файлов начинаются с буквы, которая говорит об ожидаемом результате:

Обратите внимание, что несколько парсеров не допускают скаляров на верхнем уровне ( «test» ), поэтому я встроил строки в массивы ( [«test»] ).

Больше 300 тестовых файлов вы можете найти в репозитории JSONTestSuite.

В большинстве своём файлы я делал вручную по мере чтения спецификаций, стараясь уделить внимание крайним ситуациям и неоднозначным моментам. Я также пытался использовать наработки из чужих тестовых наборов, найденных в интернете (в основном json-test-suite и JSON Checker), но обнаружил, что большинство из них покрывают только базовые ситуации.

Наконец, я генерировал JSON-файлы с помощью фаззингового ПО American Fuzzy Lop. Затем убрал избыточные тесты, приводящие к одному результату, а потом сократил количество оставшихся, чтобы получилось наименьшее количество символов, дающих результаты (см. раздел 3).

2.1. Структура

Скаляры — очевидно, что необходимо парсить скаляры наподобие 123 или «asd». На практике многие популярные парсеры всё ещё реализуют RFC 4627 и не станут парсить одиночные значения. Таким образом, есть основные тесты, например:

Замыкающие запятые (trailing commas), например [123,] или <"a":1,>, не являются частью грамматики, поэтому такие файлы не должны проходить тесты, верно? Но дело в том, что RFC 7159 позволяет парсерам поддерживать «расширения» (раздел 9), хотя пояснений насчёт них не даётся. На практике замыкающие запятые — распространённое расширение. Поскольку это не часть JSON-грамматики, парсеры не обязаны поддерживать их, так что имена файлов начинаются с n.

2.2. Числа

2.3. Массивы

2.4. Объекты

Повторяющиеся ключи. В разделе 4 RFC 7159 говорится: «В пределах объекта должны быть уникальные имена». Это не предотвращает парсинг объектов, в которых один ключ появляется несколько раз <"a":1,"a":2>, но позволяет парсерам самим решать, что делать в таких случаях. В разделе 4 даже упоминается, что «[некоторые] реализации сообщают об ошибке или сбое во время парсинга объекта», без уточнения, соответствует ли сбой парсинга положениям RFC, в особенности этому: «JSON-парсер ДОЛЖЕН принимать все виды текстов, соответствующих грамматике JSON».

Варианты таких особых случаев включают в себя одинаковый ключ: одно и то же значение <"a":1,"a":1>, а также ключи или значения, чья одинаковость зависит от способа сравнения строк. Например, ключи могут быть разными в двоичном выражении, но эквивалентными в соответствии с нормализацией Inicode NFC: <"C3A9:"NFC","65CC81":"NFD">, здесь оба ключа обозначают «é». Также в тесты включена проверка <"a":0,"a":-0>.

2.5. Строки

Кодировка файла. «JSON-текст ДОЛЖЕН быть в кодировке UTF-8, UTF-16 или UTF-32. По умолчанию используется UTF-8» (раздел 8.1).
Так что для прохождения тестов необходима одна из трёх кодировок. Тексты в UTF-16 и UTF-32 также должны содержать старшие и младшие варианты.

Сбойные тесты включают в себя строки в кодировке ISO-Latin-1.

Маркер последовательности байтов (Byte Order Mark). Хотя в разделе 8.1 заявлено: «Реализации НЕ ДОЛЖНЫ добавлять маркер последовательности байтов в начало JSON-текста», потом мы видим: «Реализации… МОГУТ игнорировать наличие маркера, а не рассматривать его как ошибку».

Сбойные тесты включают в себя лишь отметки в кодировке UTF-8, без другого контента. Тесты, результаты которых зависят от реализации, включают в себя UTF-8 BOM с UTF-8 строкой, а также UTF-8 BOM с UTF-16 строкой и UTF-16 BOM с UTF-8 строкой.

Экранированные не Unicode-символы

В то же время дополненная форма Бэкуса — Наура (ABNF, Augmented Backus — Naur form) не допускает использования не соответствующих Unicode кодовых точек (раздел 7) и требует соответствия Unicode (раздел 1).

Обычные (raw) не Unicode-символы

В предыдущем разделе мы обсудили не Unicode — кодовые точки, возникающие в строках ( \uDEAD ). Эти точки являются валидным Unicode в u-экранированной форме, но не декодируются в Unicode-символы.

Парсеры также должны обрабатывать обычные байты, не кодирующие Unicode-символы. Например, в UTF-8 байт FF не является Unicode-символом. Следовательно, строковое значение, содержащее FF, — это не строка в кодировке UTF-8. В таком случае парсер должен просто отказаться её парсить, потому что «Строковое значение — это последовательность Unicode-символов в количестве от нуля и более» (RFC 7159, раздел 1) и «JSON-текст ДОЛЖЕН быть представлен в кодировке Unicode» (RFC 7159, раздел 8.1).

Двусмысленности RFC 7159

Помимо специфических случаев, которые мы рассмотрели, практически невозможно установить, соответствует ли парсер требованиям RFC 7159, по причине сказанного в разделе 9:

JSON-парсер ДОЛЖЕН принимать все тексты, соответствующие грамматике JSON. JSON-парсер МОЖЕТ принимать не JSON формы или расширения.

Пока всё понятно. Все грамматически правильные входные данные ДОЛЖНЫ парситься, и парсеры могут сами решать, принимать ли другой контент.

Все эти ограничения звучат разумно (за исключением, возможно, символов), но противоречат слову «ДОЛЖЕН» из предыдущей цитаты. RFC 2119 предельно ясно объясняет его значение:

ДОЛЖЕН. Это слово, как и «ТРЕБУЕТСЯ» или «СЛЕДУЕТ», означает обязательное требование спецификации.

RFC 7159 допускает ограничения, но не задаёт минимальные требования. Поэтому технически парсер, который не может парсить строку длиннее трёх символов, всё ещё соответствует требованиям RFC 7159.

Кроме того, в разделе 9 RFC 7159 от парсеров требуется ясно документировать ограничения и/или позволить использовать пользовательские конфигурации. Но эти конфигурации могут приводить к проблемам с совместимостью, поэтому лучше останавливаться на минимальных требованиях.

Такой недостаток конкретики на фоне допускаемых ограничений практически не позволяет точно сказать, соответствует ли парсер RFC 7159. Ведь можно парсить контент, не соответствующий грамматике (это «расширения»), и отклонять контент, соответствующий грамматике (это «ограничения» парсера).

3. Архитектура тестирования

Я хотел посмотреть, как на самом деле поведут себя парсеры, вне зависимости от того, как они должны себя вести. Поэтому выбрал несколько JSON-парсеров и настроил всё так, чтобы можно было скармливать им свои тестовые файлы.

Поскольку я Cocoa-разработчик, большинство парсеров написаны на Swift и Objective-C. Но есть и достаточно произвольно выбранные парсеры на C, Python, Ruby, R, Lua, Perl, Bash и Rust. В основном я старался охватить разнообразные по возрасту и популярности языки.

Некоторые парсеры позволяют усиливать или ослаблять строгость ограничений, настраивать поддержку Unicode или использовать специфические расширения. Я стремился всегда конфигурировать парсеры, чтобы они работали как можно ближе к наиболее строгой интерпретации RFC 7159.

Python-скрипт run_tests.py прогонял через каждый парсер каждый тестовый файл (или одиночный тест, если файл передаётся в виде аргумента). Обычно парсеры были в обёртках и возвращали 0 в случае успеха и 1 в случае неудачи парсинга. Был предусмотрен отдельный статус для падения парсера, а также таймаут — 5 секунд. По сути, я превратил JSON-парсеры в JSON-валидаторы.

run_tests.py сравнивал возвращаемое значение по каждому тесту с ожидаемым результатом, отражённым в префиксе имени файла. Если они не совпадали или когда префикс был i (зависит от реализации), run_tests.py записывал в журнал ( results/logs.txt ) строку определённого формата:

Затем run_tests.py считывал журнал и генерировал HTML-таблицы с результатами ( results/parsing.html ).

В каждой строке находятся результаты для одного из файлов. Парсеры представлены в колонках. Для разных результатов предусмотрены разные цвета заливки ячеек:

Тесты отсортированы по результатам. Это облегчает поиск схожих результатов и удаление избыточных.

4. Результаты и комментарии

4.1. Полные результаты

Полные результаты тестирования можно найти здесь: seriot.ch/json/parsing.html. Тесты отсортированы по схожести результатов. В run_tests.py есть опция, позволяющая выводить «сокращённые результаты» (pruned results): когда набор тестов даёт одинаковые результаты, то сохраняется только первый тест. Файл с сокращёнными данными доступен тут: www.seriot.ch/json/parsing_pruned.html.

Падения (красный цвет) — самая серьёзная проблема, поскольку парсинг неконтролируемых входных данных подвергает риску весь процесс. Тесты «ожидалось успешное выполнение» (коричневый цвет) также очень опасны: неконтролируемые входные данные могут не дать отпарсить весь документ. Менее опасны тесты «ожидался сбой выполнения» (жёлтый цвет). Они говорят о «расширениях», которые нельзя отпарсить. Так что всё станет работать до тех пор, пока парсер не будет заменён другим, который не умеет парсить эти «расширения».

Дальше я рассмотрю и прокомментирую самые примечательные результаты.

4.2. C-парсеры

Я выбрал пять C-парсеров:

Больше подробностей можно найти в таблице полных результатов.

4.3. Objective-C-парсеры

Я выбрал три Objective-C-парсера, очень популярных на заре iOS-разработки, особенно потому, что Apple до iOS 5 не выпускала NSJSONSerialization. Все три парсера было интересно протестировать, поскольку они использовались при разработке многих приложений.

SBJSON выжил после появления NSJSONSerialization, он до сих пор поддерживается, его можно скачать через CocoaPods. Поэтому в заявке #219 я зарепортил падение, когда парсил не UTF-8 строки наподобие [«FF»].

4.4. Apple (NS)JSONSerialization

NSJSONSerialization появился с iOS 5, и с тех пор это стандартный JSON-парсер на OS X и iOS. Он доступен на Objective-C и был переписан на Swift: NSJSONSerialization.swift. В Swift 3 префикс NS отбросили.

Ограничения и расширения

У JSONSerialization есть незадокументированные ограничения:

Падение при сериализации

4.5. Freddy (Swift)

Freddy (https://github.com/bignerdranch/Freddy) — это настоящий JSON-парсер, написанный на Swift 3. Я говорю «настоящий», потому что несколько GitHub-проектов заявляют себя как Swift JSON-парсеры, хотя на самом деле используют Apple JSONSerialization и просто мапят JSON-контент в объект-модели.

Freddy интересен тем, что написан знаменитой группой Cocoa-разработчиков и эксплуатирует безопасность типов Swift с помощью использования Swift-перечислений для представления разных JSON-узлов (Array, Dictionary, Double, Int, String, Bool и Null).

Также я обнаружил, что «0e1» ошибочно отклоняется парсером, о чём написал в заявке #198, и этот баг тоже пофиксили за один день.

В этой таблице отражена эволюция поведения Freddy:

4.6. Bash JSON.sh

Я тестировал github.com/dominictarr/JSON.sh, версию от 12 августа 2016 года.

В этом Bash-парсере регулярные выражения отвечают за поиск управляющих символов, которые, согласно RFC 7159, ДОЛЖНЫ быть экранированы с помощью обратных слешей. Но у Bash и JSON разные представления о том, что такое управляющие символы.

4.7. Другие парсеры

Помимо C / Objective-C и Swift, я тестировал парсеры и из других окружений. Вот краткий обзор их расширений и ограничений с выборкой из полных результатов тестирования. Таблица призвана показать, что не найдётся и двух парсеров, которые полностью совпадают во мнении, что хорошо и что плохо.

Ссылки на протестированные парсеры:

4.8. JSON Checker

JSON-парсер преобразует JSON-документ в другое представление. Если входные данные являются некорректным JSON, то парсер возвращает ошибку.

Некоторые программы не преобразуют входные данные, а просто сообщают о корректности или некорректности JSON. Такие программы — это JSON-валидаторы.

Одна из них написана на С и называется JSON_Checker. Её можно скачать с www.json.org/JSON_checker, и с ней даже идёт тестовый набор (маленький):

JSON_Checker — это pushdown automaton программа, которая очень быстро определяет синтаксическую корректность JSON-текста. Она может использоваться для фильтрования входных данных или для проверки выходных данных на синтаксическую корректность. JSON_Checker можно адаптировать для создания очень быстрого JSON-парсера.

Хотя JSON_Checker формально не является референсной реализацией, всё же можно ожидать, что он уточнит требования JSON-спецификации или хотя бы корректно их реализует.

Элегантность реализации JSON_Checker в качестве pushdown automaton не отменяет ошибочности кода, но хотя бы таблица перехода состояний облегчает обнаружение ошибок, особенно когда вы добавляете состояния в схему того, что является числом.

4.9. Регулярные выражения

Могут ли регулярные выражения проверять соответствие входных данных грамматике JSON? Посмотрите, например, на попытку найти самое короткое регулярное выражение. Проблема в том, что без серьёзного тестирования очень трудно узнать, увенчались ли успехом действия регулярных выражений.

Оно не может парсить валидный JSON, например:

5. Контент парсинга

JSON-парсер преобразует JSON-текст в другое представление.

Вся вышеперечисленная архитектура тестирования говорит лишь о том, будет ли парсер парсить JSON-документ, но ничего не сообщает о представлении получившегося контента.

Например, можно без ошибки отпарсить u-экранированный неправильный Unicode-символ ( «\uDEAD» ), но каким будет результат? Символ замены или что-то другое? В RFC 7159 об этом ни слова.

Или как быть с объектами, содержащими одинаковые ключи ( <"a":1,"a":2>)? Или одинаковые ключи и значения ( <"a":1,"a":1>)? А как парсер должен сравнивать ключи объекта? В двоичном представлении или в нормальной Unicode-форме, как NFC? В RFC нет ответа.

Во всех этих случаях парсеры могут делать с выходными данными что угодно. Отсюда — проблемы с совместимостью (подумайте, что может пойти не так, если вы решите поменять свой привычный JSON-парсер на другой).

Учитывая вышесказанное, давайте проведём тестирования на неопределённость представления после парсинга. Эти тесты нужны только для понимания, как могут различаться выходные данные парсеров. В отличие от проверки парсинга, эти тесты трудно автоматизировать. Так что результаты получены с помощью анализа журналов выражений (log statements) и/или отладчиков.

Ниже представлен список некоторых разительных отличий между финальными представлениями после парсинга. Полные результаты можно посмотреть в разделе «Контент парсинга».

6. STJSON

STJSON — это JSON-парсер, написанный на Swift 3 и состоящий из 600+ строк. Я написал его, чтобы выяснить, как можно избежать подводных камней и пройти все тесты.

STJSON API очень прост:

STJSON может инстанцироваться с дополнительными параметрами:

7. Заключение

JSON — это не тот формат данных, на который можно слепо полагаться. Я доказал это тем, что:

Я написал ещё один JSON-парсер (раздел 6), который парсит или отвергает JSON-документ согласно моему пониманию RFC 7159. Комментируйте, сообщайте о багах и делайте pull request’ы.

Источник