Инструменты разработчика · JSON форматировщик и валидатор
Почему файл строк JSON не проходит проверку в строке 2, столбец 1
· Как это работает
JSON рабочий процесс разработчика проверка
Файл .jsonl представляет собой множество JSON документов, а не один, поэтому строгий валидатор останавливается именно там, где начинается второй. В этом посте объясняются соглашения о строках JSON и NDJSON, а также о том, как проверять их по одной записи за раз.
Действителен для каждой строки, недействителен для файла.
Действителен для каждой строки, недействителен как файл — экспорт, который все последующие инструменты успешно читают, но валидатор отклоняет на второй строке. Отправитель журналов может использовать каждую новую строку как границу записи, однако строгий синтаксический анализатор JSON рассматривает весь файл как один вход. Первый объект завершен JSON; следующая открывающая скобка является недопустимым вторым корневым значением.
ToolAcre проверяет один текст JSON, а не JSON строк. Как только сканер завершает первое корневое значение, любой последующий символ без пробелов считается неожиданным после окончания значения JSON. Он не предлагает построчную проверку NDJSON или преобразование в качестве скрытого резервного варианта. Это различие не позволяет зелёному результату означать, что была проверена каждая запись в линейно-ориентированном потоке.
Один текст, одно значение — что RFC 8259 определяет как текст JSON и почему два значения верхнего уровня подряд являются грамматической ошибкой
Один текст, одно значение — что RFC 8259 определяет как текст JSON и почему два значения верхнего уровня подряд являются грамматической ошибкой. Текст JSON представляет собой сериализованное значение, поэтому в корне может находиться объект, массив, строка, число, логическое значение или значение NULL. Пробелы могут окружать это значение, но они не могут разделить несколько корней на более крупный действительный документ.
Например, `{"ок":true} {"ок":false}` contains two individually valid objects but is not one JSON text. Parsing the first object consumes a complete value; parsing the entire string must then reject the second `{`. Чтобы представить оба значения в обычном JSON, поместите их внутри массива и добавьте запятую между элементами массива.
JSON линии и NDJSON
JSON Строки и NDJSON — соглашения о разделении новой строки, почему они существуют для потоковой передачи и журналов и чем они отличаются от массива JSON. Каждая физическая строка содержит одно полное значение JSON, обычно объект, а новая строка действует как рамка вне грамматики JSON. Производители могут добавлять записи, а потребители могут обрабатывать их постепенно, не загружая полную коллекцию.
Вместо этого массив имеет одну открывающую скобку, элементы, разделенные запятыми, и одну закрывающую скобку, что делает весь файл одним значением JSON. Это удобно для API, которые возвращают ограниченную коллекцию, но неудобно для бесконечно растущего потока событий. Усеченный файл JSON Lines может сохранить все полные предыдущие записи; усеченный массив обычно оставляет заключающее значение незавершенным.
Почему ошибка всегда находится в строке 2, столбец 1
Почему ошибка всегда в строке 2, столбце 1 — парсер завершает первое значение, ожидает окончания ввода и встречает первый символ второй записи. Сама новая строка является допустимым конечным пробелом, поэтому она не вызывает сбой. Открывающая скобка следующей записи — это первый токен, который противоречит состоянию завершенного документа.
Это местоположение является диагностическим свидетельством, а не утверждением о том, что второй объект имеет деформацию. Если отчет постоянно указывает на первый символ без пробелов после действительного корня, проверьте форму файла, прежде чем редактировать знаки препинания. Удаление фигурной скобки приведет к повреждению записи; выбор устройства чтения с поддержкой строк или преобразование записей в массив позволяет устранить фактическое несоответствие кадров.
Рабочий пример: проверка трех записей журнала
Рабочий пример: проверка трех записей журнала — проверка каждой строки отдельно, а не заключение их в массив с запятыми. Предположим, что строки содержат `{"level":"info"}`, `{"level":"warn"}` и `{"level":"error"}`. Линейно-ориентированный валидатор анализирует три отдельных входных данных и может определить точную запись, если в одной из них отсутствует кавычка или конечная запятая.
Для строгой проверки всего документа преобразуйте образец в `[{"level":"info"},{"level":"warn"},{"level":"error"}]`. Скобки устанавливают один корень, а запятые разделяют его элементы. Не заменяйте просто символы новой строки запятыми: это приведет к появлению трех корней, разделенных знаками препинания, если только не будет добавлен окружающий массив, и это может привести к неправильной обработке пустых строк, которые соглашение об исходном коде может запретить или игнорировать.
Преобразование между двумя фигурами
Преобразование между двумя фигурами — когда уместен массив-обертка и когда он противоречит точке вывода, разделенной строками. Конечный экспорт, предназначенный для запроса API, редактора или строгого валидатора, часто может стать массивом. При преобразовании необходимо сначала проанализировать каждую запись, поскольку текстовая конкатенация не может безопасно учитывать внедренные экранированные символы или недопустимые строки.
Сохраняйте строки JSON, когда записи поступают непрерывно, файлы добавляются или потребителям требуется ограниченная память и восстановление на уровне записей. Преобразование потока событий размером в несколько гигабайт в один массив требует сохранения состояния контейнера и откладывает полный анализ до прибытия закрывающей скобки. В другом направлении компактно сериализуйте каждый элемент массива в одной строке и определите, разрешены ли пустые строки или последние символы новой строки.
Что это не распространяется
То, что это не охватывает — объединенные JSON без символов новой строки и рамки разделителя записей (RFC 7464), для которых требуются специальные синтаксические анализаторы. Значения, помещенные непосредственно вместе, не могут быть безопасно разделены с помощью простой операции со строкой, особенно если корнями могут быть числа или строки. RFC 7464 использует символ-разделитель записей ASCII для обрамления текстовых последовательностей JSON, а не полагается только на видимые символы новой строки.
Он также не проверяет правила применения, общие для записей. Анализ каждой строки не может доказать, что временные метки упорядочены, идентификаторы уникальны или все объекты используют одну и ту же схему. Эти проверки выполняются после формирования записи и синтаксического анализа. Аналогично, новая строка, встроенная в escape-последовательность ` ` внутри строки находятся данные, а не физическая граница, и соответствующий стандарт чтения строк должен сохранять это различие.
Вывод: знайте, какую фигуру вы держите в руках
Вывод: знайте, какую фигуру вы держите в руках, и как позиция валидатора мгновенно сообщает вам, что файл разделен строками. Сбой в первом токене второй строки после полного значения первой строки явно указывает на наличие нескольких записей в рамке, а не на нарушение синтаксиса в первой записи. Прежде чем изменять данные, проверьте расширение, документацию производителя и ожидаемого потребителя.
Используйте синтаксический анализатор JSON Lines или NDJSON для независимой проверки записей, когда новая строка является преднамеренной. Используйте массив, если пункту назначения требуется одна полная коллекция JSON. ToolAcre правильно отклоняет многокорневой файл, поскольку его контракт представляет собой строгую однотекстовую проверку; отказ защищает этот контракт, а не показывает, что JSON, разделенный символом новой строки, по своей сути дефектен. Сопоставьте валидатор с форматом кадра.