https://habr.com/ru/company/mailru/blog/314014/
Ключевое место в тексте
иПомимо специфических случаев, которые мы рассмотрели, практически невозможно установить, соответствует ли парсер требованиям RFC 7159, по причине сказанного в разделе 9:
JSON-парсер ДОЛЖЕН принимать все тексты, соответствующие грамматике JSON. JSON-парсер МОЖЕТ принимать не JSON формы или расширения.
Пока всё понятно. Все грамматически правильные входные данные ДОЛЖНЫ парситься, и парсеры могут сами решать, принимать ли другой контент.
Реализации могут ограничивать:
размер принимаемого текста;
максимальную глубину вложенности;
диапазон и точность чисел;
длину строковых значений и их набор символов.
Все эти ограничения звучат разумно (за исключением, возможно, символов), но противоречат слову «ДОЛЖЕН» из предыдущей цитаты. RFC 2119 предельно ясно объясняет его значение:
ДОЛЖЕН. Это слово, как и «ТРЕБУЕТСЯ» или «СЛЕДУЕТ», означает обязательное требование спецификации.
RFC 7159 допускает ограничения, но не задаёт минимальные требования. Поэтому технически парсер, который не может парсить строку длиннее трёх символов, всё ещё соответствует требованиям RFC 7159.
Кроме того, в разделе 9 RFC 7159 от парсеров требуется ясно документировать ограничения и/или позволить использовать пользовательские конфигурации. Но эти конфигурации могут приводить к проблемам с совместимостью, поэтому лучше останавливаться на минимальных требованиях.
Такой недостаток конкретики на фоне допускаемых ограничений практически не позволяет точно сказать, соответствует ли парсер RFC 7159. Ведь можно парсить контент, не соответствующий грамматике (это «расширения»), и отклонять контент, соответствующий грамматике (это «ограничения» парсера).
Заключение
JSON — это не тот формат данных, на который можно слепо полагаться. Я доказал это тем, что:
стандартное определение разбросано как минимум по шести разным документам (раздел 1);
последний и самый полный документ, RFC-7159, неточен и противоречив (раздел 2);
более чем среди 30 парсеров, обработавших созданные мною тестовые файлы, не нашлось даже двух, которые бы выдали одинаковые результаты (раздел 4).
Анализируя результаты тестирования, я обнаружил, что json_checker.c с сайта json.org отклоняет валидный JSON [0e1] (раздел 4.24), что никак не поможет пользователям понять, где правильно, а где неправильно. Многие авторы парсеров (включая и меня) любят хвастаться корректностью работы своих парсеров, толку от этого мало, потому что эталоны спорны, а существующие тестовые наборы откровенно слабы.
Я написал ещё один JSON-парсер (раздел 6), который парсит или отвергает JSON-документ согласно моему пониманию RFC 7159. Комментируйте, сообщайте о багах и делайте pull request’ы.