Formatowanie JSONL

O GeekFormat

Wklej tutaj JSONL lub NDJSON. Puste wiersze są automatycznie ignorowane, a każdy wiersz z danymi musi być pełnym obiektem JSON.

Sformatowany wynik pojawi się tutaj.

Każdy niepusty wiersz powinien być pełnym obiektem JSON.

Wszystkie wiersze: 1Niepuste wiersze: 0Poprawne wiersze: 0Niepoprawne wiersze: 0

Wklej JSONL, aby natychmiast rozpocząć formatowanie.

Lekka strona formatowania JSONL dla logów, archiwów sesji i eksportów strumieniowych. Wklej po lewej obiekty JSON rozdzielone znakami nowej linii, a po prawej natychmiast podejrzyj sformatowany wynik każdego rekordu i od razu zobacz, który wiersz jest uszkodzony.

Powiązane Rekomendacje

JSON Formatter

Naprawa JSON

JSON Compress

JSON Stringify

Walidator JSON Schema

Czym jest formatowanie JSONL?

JSONL (JSON Lines) to format tekstowy organizujący rekordy JSON wierszami. Jego kluczową cechą nie jest to, że „wygląda jak JSON”, lecz to, że „każdy rekord zajmuje osobny wiersz”. W realnej inżynierii niemal zawsze oznacza to, że każdy niepusty wiersz to kompletny obiekt JSON, a obiekty rozdziela znak nowej linii, zamiast dodatkowo owijać je w wielką tablicę `[{...},{...}]`.

Taka organizacja szczególnie pasuje do logów, strumieni zdarzeń, archiwów sesji, eksportów masowych i przetwarzania strumieniowego: program nie musi wczytywać całego pliku do pamięci, tylko konsumuje rekordy wiersz po wierszu. Gdy wiersz jest uszkodzony, da się wskazać dokładny jego numer, zamiast po omacku liczyć nawiasy i szukać przecinków w bardzo długiej tablicy JSON.

Formatowanie JSONL to nie to samo co zwykłe formatowanie JSON. Zwykły formater zakłada, że wejście to jeden kompletny dokument JSON; formater JSONL musi natomiast parsować wiersz po wierszu, walidować i zgłaszać błędy wiersz po wierszu, zachowując jednocześnie semantykę rekordów rozdzielonych nową linią. Dla logów i plików eksportu ta różnica jest kluczowa.

Ta strona jest zaprojektowana właśnie wokół tej realnej semantyki: po lewej wprowadzasz rozdzielone wierszami rekordy obiektów, po prawej widzisz sformatowany wynik per rekord, a błędne, ucięte i nieobiektowe wiersze są od razu wskazywane. Dzięki temu, badając plik `.jsonl`, widzisz „który rekord ma problem”, zamiast dostawać ogólny `SyntaxError`.

Przypadki użycia

Upiększać rekord po rekordzie JSONL wyeksportowany z logów aplikacji, zanim sprawdzisz pole po polu, zamiast wpatrywać się w długi ciąg obiektów ściśniętych w jednym wierszu
Sprawdzać pliki archiwów sesji, w których każdy wiersz to obiekt zdarzenia, i potwierdzać, że każdy rekord jest kompletny i czytelny
Gdy eksport zbiorczy potoku danych, platformy śledzącej lub Elasticsearch kończy się błędem, szybko ustalać, który wiersz obiektu JSON jest źle zapisany
Podczas debugowania interfejsów strumieniowych sprawdzać, czy serwer naprawdę zwraca ciągle „jeden obiekt w wierszu”, zamiast przedwcześnie wypychać niedokończony obiekt
Wklejać NDJSON skopiowany z terminala, paneli monitorowania lub chmurowych platform logów: najpierw uporządkować strukturę, a potem kontynuować analizę
Sprawdzać, czy w generowanych przez AI wynikach obiektów wiersz po wierszu któryś wiersz nie zawiera przypadkiem tablicy, ciągu znaków albo niekompletnego JSON
Przed importem do procesów zależnych od rekordów wierszowych, takich jak ClickHouse, BigQuery czy Kafka Connect, najpierw ręcznie przejrzeć zawartość JSONL
Podczas badania dzienników audytu, zdarzeń ryzyka czy strumieni zdarzeń śledzących sprawdzać rekord po rekordzie, czy struktura obiektów pozostaje stabilna i spójna
Gdy plik JSONL zostanie ucięty albo pobrany niekompletnie, natychmiast zobaczyć, który ostatni obiekt nie został domknięty
Najpierw sformatować rozdzielany wierszami JSON z wewnętrznych narzędzi, a potem wysłać go koledze do przeglądu kodu lub weryfikacji danych
Zanim napiszesz skrypt parsujący JSONL, ręcznie potwierdzić poziomy pól, obiekty zagnieżdżone i położenie tablic, aby skrócić czas debugowania skryptu
Przy historycznych eksportach z wymieszanymi pustymi i błędnymi wierszami najpierw odfiltrować problemy strukturalne, zanim zdecydujesz o konwersji do CSV lub imporcie do bazy

Jak Używać

Wklej treść JSONL lub NDJSON w obszar wejściowy, dbając o to, by każdy niepusty wiersz był samodzielnym obiektem JSON
Po prawej od razu następuje formatowanie wiersz po wierszu, a przy uszkodzonych wierszach wyświetlane są numer wiersza, komunikat błędu i oryginalny rekord
Poprawiaj wskazane wiersze zgodnie z podpowiedziami, aż liczba błędnych wierszy spadnie do zera
Gdy wszystko jest poprawne, skopiuj kompletny sformatowany wynik albo przekaż dane do dalszych skryptów, importerów i procesów analitycznych

Funkcje

Analizuje JSONL / NDJSON wiersz po wierszu, bez konieczności wcześniejszego ręcznego pakowania danych w kompletną tablicę JSON, taką jak `[{...},{...}]`
Waliduje zgodnie z rzeczywistą semantyką pliku „każdy niepusty wiersz to jeden obiekt JSON”, co odpowiada typowym postaciom danych: logom, strumieniom zdarzeń i archiwom sesji
Układ dwukolumnowy: pole `textarea` po lewej, sformatowany podgląd na żywo po prawej – wygodnie do poprawiania na bieżąco
Uszkodzone wiersze od razu pokazują dokładny numer wiersza, błąd parsowania i oryginalną treść, co ułatwia szybką naprawę uciętych rekordów, brakujących nawiasów i błędów scalania
Kopiowanie jest dostępne tylko wtedy, gdy wszystkie niepuste wiersze są poprawne, aby nie przekazywać do dalszych procesów danych częściowo poprawnych, a częściowo uszkodzonych
Wbudowane statystyki: liczba wierszy łącznie, niepustych, poprawnych i błędnych, aby szybko ocenić, ile rekordów w dużym pliku jest uszkodzonych
Dołączone dane przykładowe, dzięki czemu efekt formatowania JSONL można wypróbować od razu po pierwszym otwarciu
Całe przetwarzanie odbywa się lokalnie w przeglądarce; logi, zdarzenia sesji i eksporty interfejsów nie są wysyłane

Formatowanie JSONL vs formatowanie JSON vs naprawa JSON

Tych narzędzi często używa się po kolei, ale rozwiązują różne problemy. Dobry wybór wejścia mocno przyspiesza pracę.

Narzędzie	Najlepsze dane wejściowe	Główna umiejętność	Scenariusz użycia
Formatowanie JSONL	Jeden obiekt JSON w wierszu	Walidacja i upiększanie rekordu po rekordzie	Logi, NDJSON, archiwa sesji, eksporty strumieniowe
Formatowanie JSON	Jeden kompletny obiekt lub tablica JSON	Upiększanie całego dokumentu JSON	Odpowiedzi API, pliki konfiguracyjne, jednorazowe payloady
Naprawa JSON	Tekst JSON z błędami składni lub niestandardowy	Najpierw naprawa składni, potem dalsze narzędzia	Końcowe przecinki, komentarze, problemy z cudzysłowami, ucięty JSON

Best Practices

Podczas debugowania zachowuj oryginalną postać JSONL, zamiast ręcznie pakować ją w tablicę tylko po to, by ją zrozumieć

Jeśli system dalszy pobiera JSONL, staraj się badać dane w oryginalnej postaci „jeden rekord w wierszu”. Spakowanie w tablicę pozwala co prawda użyć zwykłego formatera, ale gubi semantykę oryginalnych numerów wierszy i utrudnia powiązanie błędu z jego rzeczywistą pozycją.

W dużych plikach najpierw patrz na ostatnie wiersze

Wiele plików JSONL nie ma błędu struktury w środku – to ostatnie wiersze bywają ucięte przez przerwany strumień, nieudane pobranie albo niedokończony zapis. Sprawdzenie najpierw kilku ostatnich rekordów jest zwykle szybsze niż przewijanie całego pliku od początku.

Jeśli wejście ma pojedyncze cudzysłowy, komentarze albo styl JSON5, najpierw naprawa JSON zaoszczędzi czasu

Strona JSONL kładzie nacisk na walidację obiektów wiersz po wierszu; jeśli dane źródłowe od początku nie są standardowym JSON-em, naprawa przed formatowaniem jest zwykle skuteczniejsza niż ręczne poprawianie każdego wiersza w długim pliku.

Przygotowując ponowny import, bezwzględnie zachowaj semantykę transmisji „jeden obiekt w wierszu”

Wielowierszowy, upiększony blok po prawej lepiej czyta się człowiekowi, ale jeśli zamierzasz zapisać dane z powrotem do systemu logów, kolejki komunikatów albo importera, zachowaj źródłową strukturę jeden obiekt w wierszu, zamiast traktować podgląd jako ostateczny format transmisji.

Traktuj numery wierszy jako główny trop, zamiast naocznie czytać cały plik

Podczas prawdziwego debugowania najszybsza droga to zwykle najpierw ustalić numer błędnego wiersza, a potem porównać ten rekord z sąsiednimi poprawnymi. Szybciej zobaczysz wtedy, czy brakuje nawiasu albo cudzysłowu, czy pole jest ucięte, albo czy do obiektu trafił zły typ.

Często Zadawane Pytania

Jaka jest różnica między JSON a JSONL?

Zwykły JSON to najczęściej jeden cały obiekt lub tablica, które trzeba sparsować jako jeden kompletny dokument; JSONL (JSON Lines, często nazywany też NDJSON) to natomiast jeden niezależny rekord w wierszu, a w praktyce inżynierskiej najczęściej „jeden obiekt JSON w wierszu”. Lepiej pasuje do logów, strumieni zdarzeń, przetwarzania strumieniowego i importów masowych, bo można wiersz po wierszu odczytywać, zapisywać i lokalizować błędy.

Dlaczego ta strona kładzie nacisk na „jeden obiekt JSON w wierszu”?

Ponieważ większość prawdziwych plików JSONL jest właśnie tak zorganizowana, zwłaszcza logi, archiwa sesji, strumienie zdarzeń i eksporty. Twoje próbki archiwów też mają tę typową postać: każdy wiersz to obiekt rozdzielony znakiem nowej linii. Strona waliduje według tej semantyki, co dużo lepiej odpowiada realnemu debugowaniu niż swobodne przyjmowanie dowolnej wartości JSON.

Czym JSONL różni się od tablicy JSON, takiej jak `[{...},{...}]`?

Tablica JSON to kompletny dokument JSON, który trzeba najpierw wczytać w całości, a dopiero potem sparsować; JSONL dzieli każdy obiekt na niezależne rekordy wierszowe, może być odczytywany strumieniowo i łatwiej wskazać dokładny wiersz, gdy któryś rekord zawodzi. Dla dużych plików logów i strumieni zdarzeń JSONL sprawdza się lepiej niż jedna zbiorcza tablica.

Dlaczego puste wiersze są ignorowane?

Puste wiersze zwykle pochodzą z kopiowania i wklejania, rotacji logów albo ręcznej edycji i nie reprezentują prawdziwych rekordów danych. Ignorowanie ich zmniejsza szum, a jednocześnie nadal ściśle sprawdza wszystkie wiersze zawierające treść.

Co się stanie, jeśli wiersz będzie tablicą, ciągiem znaków albo `null`?

Strona uzna go za błędny wiersz, bo formatem docelowym jest „każdy niepusty wiersz to obiekt JSON”. Jeśli Twoje dane rzeczywiście muszą przechowywać wierszami tablice lub wartości pierwotne, nie jest to typowy scenariusz logów JSONL, pod który zoptymalizowana jest ta strona.

Dlaczego przy jednym błędnym wierszu nie można od razu skopiować całego wyniku?

To celowo zachowawcza interakcja. Kopiowanie jest dozwolone tylko wtedy, gdy wszystkie niepuste wiersze są poprawne, aby nie przekazywać importerom, skryptom lub kolegom wyniku częściowo poprawnego i częściowo uszkodzonego – oszczędza to drugiej tury debugowania.

Czy pomoże mi to wykryć ucięte pliki logów?

Tak. Wiele problemów z JSONL zdarza się w ostatnich wierszach: na przykład obiektowi brakuje `}`, ciągowi brakuje zamykającego cudzysłowu albo strumień sieciowy urwał się w połowie. Strona od razu obnaża odpowiedni błędny wiersz, co szczególnie przydaje się przy niekompletnych pobraniach i przerwanym wyjściu strumieniowym.

Czy JSONL i NDJSON to to samo?

W przytłaczającej większości kontekstów inżynierskich można je traktować jako synonimy. Oba oznaczają rekordy JSON rozdzielone znakami nowej linii; różni się tylko zwyczaj nazewnictwa.

Czy formatowanie JSONL wysyła moje dane?

Nie. Całe parsowanie, walidacja i formatowanie odbywają się wyłącznie lokalnie w przeglądarce; logi, odpowiedzi interfejsów, archiwa sesji i eksporty danych nie są wysyłane na żaden serwer.

Kiedy używać zwykłego formatowania JSON zamiast formatowania JSONL?

Jeśli dane wejściowe same w sobie są kompletnym obiektem JSON lub tablicą, np. treścią odpowiedzi API, plikiem konfiguracyjnym albo pakietem danych typu `[{...},{...}]`, należy użyć zwykłej strony formatowania JSON; ta strona JSONL lepiej pasuje tylko wtedy, gdy wejście to rekordy obiektów rozdzielone znakami nowej linii.

Słownik

JSONL: Format tekstowy z rekordami JSON rozdzielanymi wierszami. Najczęstsza inżynierska postać: każdy niepusty wiersz to kompletny obiekt JSON.
JSON Lines: Pełna nazwa i inne częste określenie JSONL, zwykle traktowane jako synonim.
NDJSON: Newline Delimited JSON, dosłownie „JSON rozdzielany znakami nowej linii”. W większości scenariuszy logów i potoków danych praktycznie równoważny z JSONL.
Rekord wierszowy: Układ danych, w którym każdy wiersz reprezentuje kompletny rekord; nadaje się do strumieniowego zapisu i odczytu oraz lokalizowania błędów po wierszach.
Pretty Print / czytelne formatowanie: Przekształcenie ściśniętego, jednowierszowego JSON w czytelną strukturę z wcięciami i znakami nowej linii, aby ręcznie sprawdzać poziomy pól.
Błędny wiersz: Wiersz, który nie jest poprawnym JSON albo który daje się sparsować, ale nie ma oczekiwanej struktury (np. nie jest obiektem), przez co nie stanowi poprawnego rekordu JSONL.
Ucięty strumień: Log lub eksport przerwany w trakcie transmisji, opróżniania bufora albo zapisu, wskutek czego ostatni rekord nie został kompletnie domknięty.
Tablica JSON: W standardowym JSON cała kolekcja objęta `[` i `]`, na przykład `[{...},{...}]`. W przeciwieństwie do JSONL musi być parsowana jako jeden cały dokument.

Authoritative References

jsonlines.orgOficjalny opis JSON Lines
IETFOficjalna specyfikacja JSON RFC 8259