JSON: formatowanie, walidacja i naprawa zepsutego
Wklej odpowiedź API, konfigurację albo fragment logu — otrzymasz czytelny widok, drzewo i listę wszystkiego, co nie odpowiada standardowi, z dokładnym wierszem i pozycją. Wszystko jest analizowane w Twojej przeglądarce: dane nigdzie nie są wysyłane ani zapisywane.
.json — jest czytany lokalnie. Można też wkleić coś, co nie jest jeszcze poprawnym JSON-em: log, odpowiedź API z komentarzami, fragment z przecinkami na końcu.
Klucze i ich kolejność zachowane, zapis liczb niezmieniony.
Wklej JSON powyżej i naciśnij «Przetwórz».
Wklej JSON powyżej i naciśnij «Przetwórz».
Dane nie opuszczają Twojej przeglądarki — analiza i formatowanie wykonują się lokalnie, bez wysyłania na serwer.
Cztery redakcje standardu i czym się różnią
JSON opisuje kilka dokumentów i nie są one tożsame. Wybór specyfikacji zmienia to, co narzędzie uznaje za błąd. RFC 4627 (2006) — pierwotna. Dokument najwyższego poziomu może być tylko obiektem albo tablicą; pojedyncza liczba czy łańcuch są niedopuszczalne. Właśnie na tej redakcji wciąż opierają się niektóre stare biblioteki. RFC 7159 (2014) — dopuściła dowolną wartość na najwyższym poziomie. Od tego czasu 42 i «tekst» to samodzielne dokumenty JSON. RFC 8259 (2017) — obowiązująca. Dodała wymóg UTF-8 dla wymiany między systemami i przesądziła, że nazwy w jednym obiekcie muszą być unikalne. ECMA-404 — opisuje wyłącznie składnię. Duplikatów kluczy nie zakazuje, niesparowanych surogatów nie wspomina, więc zestaw ostrzeżeń jest tu najkrótszy. Jeśli masz wątpliwości — zostaw RFC 8259: to najsurowszy z obowiązujących zestawów reguł, a to, co go przeszło, przyjmą wszędzie.
Dlaczego własna analiza, a nie JSON.parse przeglądarki
Wbudowany parser zrobiono dla szybkości, a nie dla diagnostyki. Na tych samych danych milczy tam, gdzie narzędzie powinno mówić: Komunikat bez współrzędnych. Przeglądarka mówi «Unexpected token» i przesunięcie w znakach; tutaj masz wiersz, pozycję i to, czego dokładnie oczekiwano. Jeden błąd na cały dokument. Po pierwszej awarii analiza wraca do gry i pokazuje resztę, zamiast zmuszać do poprawiania po jednym. Duplikaty kluczy przechodzą po cichu. JSON.parse zostawia ostatnią wartość, a stratę zauważa się już na produkcji. Ginie zapis liczb. 1.0 staje się 1, a liczba całkowita powyżej dziewięciu biliardów zmienia ostatnie cyfry — właśnie tak psują się identyfikatory z bazy. Kolejność kluczy w wyniku pozostaje taka jak w źródle, dopóki sam nie poprosisz o sortowanie. Liczby wychodzą tu domyślnie tak, jak zostały zapisane: narzędzie pokazuje dokument, a nie wynik jego interpretacji.
Co dokładnie naprawia tryb poprawiania
Prawdziwe dane rzadko bywają czystym JSON-em. Tryb naprawy sprowadza do standardu to, co przychodzi z konfiguracji, logów i cudzych API: komentarze // i /* */ — usuwane; przecinki przed nawiasem zamykającym — zdejmowane; cudzysłowy pojedyncze i drukarskie — sprowadzane do podwójnych; klucze bez cudzysłowów i klucze liczbowe — brane w cudzysłów; True, NULL, None, undefined — stają się true, false, null; NaN i Infinity — stają się null, bo w JSON-ie nie ma liczb bez skończonej wartości; zapis liczb — zbędny plus, kropka na brzegu, zera na początku; znaki sterujące wewnątrz łańcuchów — escapowane; BOM na początku pliku i otoczka JSONP — zdejmowane. Żadna poprawka nie dzieje się po cichu: każda trafia na listę z liczbą przypadków. Jeśli wynik Ci nie odpowiada — wyłącz pole wyboru, a dokument zostanie sprawdzony taki, jaki jest.