JSON-парсер с нуля

До разбора структуры нужно классифицировать символы. Токенизатор (лексер) обходит исходную строку посимвольно, пропускает пробельные символы и генерирует плоский поток типизированных токенов: LEFT_BRACE, RIGHT_BRACE, LEFT_BRACKET, RIGHT_BRACKET, COLON, COMMA, STRING, NUMBER, TRUE, FALSE, NULL и EOF. Ключевое решение — какую информацию несёт каждый токен: структурные токены несут только тип и позицию; STRING-токены несут сырую лексему, чтобы декодер escape-последовательностей в следующем этапе мог её переобработать; NUMBER-токены несут сырую лексему, чтобы числовой декодер мог проверить формат до конвертации. Запись символьного смещения каждого токена здесь — вот что делает `position` в твоём `ParseError` честным позже; не откладывай отслеживание позиции. Токенизатор, возвращающий богатый поток токенов, делает рекурсивно-нисходящий парсер следующего этапа тривиальным в написании; токенизатор, возвращающий сырые индексы, превращает парсер в беспорядок.

Сердце рекурсивно-нисходящего парсера — функция `parseValue`, которая смотрит на текущий токен и передаёт управление нужному подправилу: если видит LEFT_BRACE — вызывает `parseObject`, если LEFT_BRACKET — `parseArray`, если NULL/TRUE/FALSE — немедленно возвращает литерал, если STRING/NUMBER — делегирует специализированным обработчикам (следующие этапы). `parseObject` потребляет токены по шаблону `{ key : value (, key : value)* }` и рекурсивно вызывает `parseValue` для каждого значения; `parseArray` делает то же для `[ value (, value)* ]`. Рекурсия — это и есть спецификация: JSON-значение определяется как одна из шести форм, а объекты и массивы содержат значения — поэтому они естественным образом возвращаются в `parseValue`. Отсутствующая запятая, ключ не-строка или токен, не являющийся допустимым началом значения, — всё это должно давать `ParseError` с позицией проблемного токена.

JSON-строки не являются JavaScript-строками: сырая лексема из токенизатора — это последовательность байт в кавычках, и её надо декодировать. RFC 8259 определяет восемь двухсимвольных escape-последовательностей (\", \\, \/, \b, \f, \n, \r, \t), отображаемых в одиночные символы, и шестисимвольную форму \uXXXX, декодирующую кодовую точку Unicode. Форма `\uXXXX` — место, где большинство реализаций ошибается: значение в диапазоне суррогатов (U+D800–U+DFFF) не является самостоятельным символом; высокий суррогат (D800–DBFF) должен немедленно следовать за `\uXXXX` низким суррогатом (DC00–DFFF), образуя суррогатную пару, декодирующуюся в символ дополнительной плоскости через `String.fromCodePoint`. Передача одиночного суррогата в `String.fromCharCode` даёт искажённую строку, не прошедшую round-trip через JSON.stringify. Любая нераспознанная `\x`-последовательность — это ошибка по спецификации, а не сквозная передача. Декодер строк чист: он принимает сырую лексему и возвращает декодированную строку, что делает его независимо тестируемым.

У JSON-чисел есть определённая грамматика — `[-](0|[1-9][0-9]*)([.][0-9]+)?([eE][+-]?[0-9]+)?` — и не все строки, которые `parseFloat` в JavaScript радостно съедает, являются допустимыми JSON-числами. `Infinity`, `NaN` и голое `.5` (ведущая точка) не являются JSON. `01` (ведущий ноль перед цифрой) не является JSON. Твой декодер чисел должен валидировать сырую лексему по грамматике JSON перед передачей в `Number()` или `parseFloat`, потому что эти функции мягче спецификации. Крайние случаи для обработки: отрицательный ноль (`-0`), который является допустимым JSON и должен корректно проходить round-trip; очень большие экспоненты (например, `1e308`), которые допустимы в JSON, но могут потерять значимость или переполниться до `Infinity` на стороне JavaScript — твой парсер корректно возвращает `Infinity`, так как это ближайшее представление IEEE 754; и числа, чья десятичная точность превышает точность 64-битного float, где ты принимаешь ближайшее представимое значение и не пытаешься сохранить точную десятичную семантику (для этого потребовался бы BigDecimal).

Рекурсивно-нисходящая структура обрабатывает вложенность бесплатно — `parseValue` вызывает `parseObject`, который вызывает `parseValue`, который вызывает `parseArray` и так далее, — но надо убедиться, что рекурсия ограничена, иначе глубоко вложенный ввод обрушит процесс с переполнением стека. Жёсткое ограничение глубины (например, 500 уровней, соответствующее типичному лимиту V8 с запасом) превращает переполнение стека в `ParseError` на правильной позиции. Ошибки EOF — второй класс ошибок позиции: когда парсер ожидает больше токенов и видит EOF, сообщаемая позиция должна быть концом ввода, а не индексом 0. Завершающее содержимое — ошибка: `parse('{}garbage')` должен бросить исключение, потому что корректный JSON-текст — это ровно одно значение без завершающего не-пробельного содержимого. Контракт сообщения об ошибках — то, на что полагаются твои вызывающие для пользовательской диагностики: `ParseError` с `position` равным 0 для каждой ошибки бесполезен.

Парсер, проходящий твои собственные happy-path тесты, — это не то же самое, что проходящий RFC 8259. Прогони реализацию через набор тестов на соответствие JSON (например, JSONTestSuite Николя Серио или тестовые векторы статьи «Parsing JSON is a Minefield») и зафиксируй, какие из его случаев 'must-fail' и 'must-pass' ты проходишь. Интересные неудачи — неоднозначные случаи: метки порядка байт в начале ввода, дублирующиеся ключи в объекте (спецификация говорит «должны» быть уникальными, но не «обязаны»), числа с очень длинной целой частью и допустимые одиночные документы, являющиеся просто числом или строкой (не объектом или массивом). Проверь round-trip своей реализации: для каждого разобранного JSON-значения `parse(JSON.stringify(value))` должен возвращать значение, которое `JSON.stringify` отображает обратно в ту же строку. Состязательные вводы — глубоко вложенные вводы, строки со всеми формами escape, объекты с 10k ключами — не должны вызывать квадратичное конкатенирование строк или неограниченное выделение памяти.