Форматирование JSONL

О GeekFormat

Вставьте сюда JSONL или NDJSON. Пустые строки игнорируются автоматически, а каждая строка с данными должна быть полным JSON-объектом.

Здесь появится отформатированный результат.

Каждая непустая строка должна быть полным JSON-объектом.

Всего строк: 1Непустые строки: 0Корректные строки: 0Некорректные строки: 0

Вставьте JSONL, и форматирование начнётся сразу.

Лёгкая страница форматирования JSONL для логов, архивов сессий и потокового экспорта. Вставьте слева объекты JSON, разделённые переносами строк, а справа сразу увидите отформатированный результат каждой записи и то, какая именно строка повреждена.

Что такое форматирование JSONL?

JSONL (JSON Lines) — это текстовый формат, который организует записи JSON по строкам. Его ключевая особенность не в том, что он «похож на JSON», а в том, что «каждая запись занимает отдельную строку». На реальной практике это почти всегда означает, что каждая непустая строка — это целый объект JSON, причём объекты разделяются переносом строки, а не заворачиваются дополнительно в большой массив `[{...},{...}]`.

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

Форматирование JSONL — это не то же самое, что обычное форматирование JSON. Обычный форматтер предполагает, что на входе один целый документ JSON; форматтер JSONL обязан разбирать, проверять и сообщать об ошибках построчно, сохраняя при этом семантику записей, разделённых переносами. Для логов и файлов выгрузки эта разница очень важна.

Эта страница спроектирована именно вокруг такой реальной семантики: слева вводятся разделённые строками записи объектов, справа по записям показывается отформатированный результат, а битые, обрезанные и не-объектные строки сразу указываются. Так при разборе файла `.jsonl` вы видите «какая запись проблемная», а не получаете общий `SyntaxError`.

Варианты использования

Сделать экспортированные из логов приложения JSONL читаемыми запись за записью, прежде чем разбирать поля по очереди, вместо того чтобы смотреть на длинную цепочку объектов, сжатых в одну строку
Проверять файлы архивов сессий, где каждая строка — объект события, и убеждаться, что каждая запись целая и читаемая
Когда падает массовый экспорт из конвейера данных, платформы трекинга или Elasticsearch, быстро находить, в какой именно строке объект JSON записан с ошибкой
При отладке потоковых интерфейсов проверять, действительно ли сервер непрерывно выдаёт «один объект в строке», а не выбрасывает раньше времени половину объекта
Вставлять NDJSON, скопированный из терминала, панелей мониторинга или облачных платформ логов: сначала привести структуру в порядок, потом продолжать разбор
Проверять, не затесался ли в построчные результаты, сгенерированные ИИ, где-то массив, строка или незавершённый JSON
Перед импортом в процессы, завязанные на построчные записи (ClickHouse, BigQuery, Kafka Connect и т. п.), вручную перепроверять содержимое JSONL
При разборе аудитных логов, событий риск-контроля или потоков событий трекинга по-записно проверять, стабильна ли и единообразна ли структура объектов
Когда JSONL-файл обрезан или скачан не полностью, сразу видеть, какой последний объект не закрыт
Сначала отформатировать построчный JSON, выгруженный внутренними инструментами, а потом отправить коллеге на ревью кода или сверку данных
Прежде чем писать скрипт разбора JSONL, вручную подтвердить уровни полей, вложенные объекты и расположение массивов, чтобы меньше отлаживать скрипт
При работе с историческими выгрузками, где вперемешку пустые и битые строки, сначала отфильтровать структурные проблемы и лишь потом решать, конвертировать ли в CSV или импортировать в базу

Как использовать

Вставьте содержимое JSONL или NDJSON в область ввода так, чтобы каждая непустая строка была самостоятельным объектом JSON
Справа сразу выполняется построчное форматирование, а у битых строк показываются номер строки, текст ошибки и исходная запись
Исправляйте соответствующие строки по подсказкам, пока число невалидных строк не станет нулевым
Убедившись, что всё корректно, скопируйте полный отформатированный результат или передайте данные дальше — в скрипты, импортёры и аналитические процессы

Функции

Разбирает JSONL / NDJSON построчно, без необходимости вручную упаковывать данные в полноценный массив JSON вида `[{...},{...}]`
Проверяет по реальной семантике файла «каждая непустая строка — это один объект JSON», что соответствует логам, потокам событий и архивам сессий
Двухколоночный макет: слева поле `textarea` для ввода, справа — мгновенный отформатированный результат, удобно править и сразу смотреть
Битые строки сразу показывают точный номер строки, ошибку разбора и исходное содержимое, что помогает быстро чинить оборванные записи, пропущенные скобки и ошибки склейки
Копирование открывается только тогда, когда все непустые строки корректны, чтобы частично валидные и частично битые данные не уходили в дальнейшие процессы
Встроенная статистика: всего строк, непустых, валидных и невалидных — чтобы быстро понять, сколько именно записей повреждено в большом файле
Есть пример данных, чтобы опробовать форматирование JSONL сразу при первом открытии
Вся обработка выполняется локально в браузере; логи, события сессий и экспорт интерфейсов никуда не загружаются

Форматирование JSONL vs форматирование JSON vs восстановление JSON

Эти инструменты часто используют друг за другом, но решают они разные задачи. Правильный выбор точки входа сильно экономит время.

Инструмент	Наиболее подходящий ввод	Ключевая возможность	Сценарий применения
Форматирование JSONL	Один объект JSON в строке	Проверка и красивая печать по записям	Логи, NDJSON, архивы сессий, потоковый экспорт
Форматирование JSON	Один целый объект или массив JSON	Сделать читаемым весь документ JSON	Ответы API, конфиги, разовые payload
Восстановление JSON	Текст JSON с синтаксическими ошибками или нестандартный	Сначала починить синтаксис, потом отдать дальше	Висячие запятые, комментарии, проблемы кавычек, обрезанный JSON

Best Practices

При отладке сохраняйте исходную форму JSONL, не пакуйте её вручную в массив только ради понимания

Если нижестоящая система принимает JSONL, разбирайтесь по возможности в исходной форме «одна запись в строке». Упаковка в массив позволяет скормить данные обычному форматтеру, но теряет семантику исходных номеров строк и хуже сопоставляется с реальным положением битой строки.

В больших файлах сначала смотрите последние строки

Во многих файлах JSONL структура ломается не в середине — именно последние строки оказываются обрезаны из-за прерванного потока, неудачной загрузки или незавершённой записи. Сначала посмотреть несколько последних записей обычно быстрее, чем листать весь файл с начала.

Если во вводе есть одинарные кавычки, комментарии или стиль JSON5, сначала сэкономит время восстановление JSON

Страница JSONL делает упор на проверку объектов построчно; если исходные данные изначально не стандартный JSON, сначала починить, а потом форматировать обычно эффективнее, чем вручную править каждую строку длинного файла.

Готовя повторный импорт, обязательно сохраняйте транспортную семантику «один объект в строке»

Многострочный красивый блок справа удобнее человеку, но если дальше вы пишете данные обратно в систему логов, очередь сообщений или импортёр, сохраните исходную структуру «один объект в строке», а не берите форму предпросмотра как итоговый формат передачи.

Используйте номера строк как главную зацепку, а не читайте весь файл глазами

В реальной отладке самый быстрый путь — обычно сначала зафиксировать номер битой строки, а потом сравнить эту запись с соседними валидными. Так быстрее видно, где не хватает скобки или кавычки, обрезано поле или в объект попал неверный тип.

Часто задаваемые вопросы

В чём разница между JSON и JSONL?

Обычный JSON — это, как правило, один целый объект или массив, который разбирается как единый документ целиком; а JSONL (JSON Lines, его часто называют NDJSON) — это одна независимая запись в строке, и на инженерной практике чаще всего «один объект JSON в строке». Он лучше подходит для логов, потоков событий, потоковой обработки и массового импорта, потому что читать, писать и находить ошибки можно построчно.

Почему эта страница подчёркивает «один объект JSON в строке»?

Потому что большинство реальных файлов JSONL устроено именно так, особенно логи, архивы сессий, потоки событий и выгрузки. Ваши примеры архивов тоже имеют типичный вид: каждая строка — объект, разделённый переносом строки. Страница проверяет именно по этой семантике, что гораздо ближе к реальной отладке, чем широкое принятие любых значений JSON.

Чем JSONL отличается от массива JSON вида `[{...},{...}]`?

Массив JSON — это целый документ JSON, который нужно сначала полностью прочитать, а потом разобрать; JSONL же разносит каждый объект по независимым строкам-записям, читается потоково и позволяет при ошибке сразу выйти на нужную строку. Для больших лог-файлов и потоков событий JSONL подходит больше, чем единый массив.

Почему пустые строки игнорируются?

Пустые строки обычно появляются из-за копирования и вставки, ротации логов или ручного редактирования и не являются настоящими записями данных. Их игнорирование снижает шум, но при этом все содержательные строки по-прежнему строго проверяются.

Что будет, если строка окажется массивом, строкой-значением или `null`?

Страница сочтёт её невалидной, ведь целевой формат здесь — «каждая непустая строка является объектом JSON». Если вашим данным действительно нужно хранить построчно массивы или сырые значения, это не тот типичный сценарий логов JSONL, под который оптимизирована страница.

Почему при одной битой строке нельзя сразу скопировать весь результат?

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

Поможет ли это найти обрезанные лог-файлы?

Да. Многие проблемы JSONL случаются в последних строках: например, у объекта не хватает `}`, у строки — закрывающей кавычки, либо сетевой поток оборвался на середине. Страница прямо обнажает соответствующую битую строку, что особенно удобно для неполных загрузок и прерванного потокового вывода.

JSONL и NDJSON — это одно и то же?

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

При форматировании JSONL мои данные загружаются на сервер?

Нет. Весь разбор, проверка и форматирование выполняются только локально в браузере; логи, ответы интерфейсов, архивы сессий и выгрузки данных не отправляются ни на какой сервер.

Когда стоит использовать обычное форматирование JSON, а не JSONL?

Если вход сам по себе — целый объект JSON или массив, например тело ответа API, конфигурационный файл или пакет данных вида `[{...},{...}]`, нужна обычная страница форматирования JSON; эта страница JSONL лучше подходит только тогда, когда вход — это разделённые переносами построчные записи объектов.

Глоссарий

JSONL: Текстовый формат с записями JSON, разделёнными по строкам. Самая частая инженерная запись: каждая непустая строка — это целый объект JSON.
JSON Lines: Полное название и другое распространённое имя JSONL, обычно считается синонимом.
NDJSON: Newline Delimited JSON, дословно «JSON, разделённый переносами строк». В большинстве сценариев логов и конвейеров данных практически эквивалентен JSONL.
Построчная запись: Раскладка данных, при которой каждая строка представляет собой целую запись; удобна для потоковой записи и чтения и построчной локализации ошибок.
Pretty Print / красивая печать: Перестройка сжатого однострочного JSON в читаемую структуру с отступами и переносами строк, чтобы вручную просматривать уровни полей.
Битая строка: Строка, которая не является корректным JSON или разбирается, но не соответствует ожидаемой структуре (например, это не объект), а потому не может быть валидной записью JSONL.
Оборванный поток: Лог или экспорт, прерванный посередине при передаче, сбросе буфера или сохранении, из-за чего последняя запись не закрыта полностью.
Массив JSON: В стандартном JSON целая коллекция, заключённая в `[` и `]`, например `[{...},{...}]`. В отличие от JSONL, его нужно разбирать как единый документ.