Walidator: JSON
Sprawdź, czy tekst jest zgodny ze standardową składnią JSON, i zrozum przyczynę zaakceptowania lub odrzucenia danych.
Sprawdź JSON przed użyciem danych
Brak jednego cudzysłowu, przecinka lub nawiasu może zatrzymać API, konfigurację albo build step. Ten validator próbuje parsować source text jako JSON, aby oddzielić błąd syntax od późniejszej application validation.
Validation oznacza tutaj tylko próbę sparsowania tekstu jako pojedynczego JSON value. Udany parse pokazuje, że struktura została zaakceptowana przez JSON; nie potwierdza required field, business rule ani JSON Schema.
Gdy payload przechodzi między services, wcześniejsza kontrola syntax ogranicza obszar debugging. Najpierw sprawdź quote, comma, escape i nesting, a potem reguły schema oraz domain projektu.
Strona przydaje się do request body, fixture, wyeksportowanych ustawień i configuration snippet. Usuń token, password oraz dane osobowe z test copy i stosuj swoją privacy policy.
Składnia i znaczenie danych to różne rzeczy
Standardowy JSON zawiera object, array, string, number, true, false i null. Property name oraz string używają double quote, member są rozdzielone comma, a bracket muszą zamykać się w poprawnej kolejności. Comment i trailing comma nie należą do standardowej JSON grammar.
Pytanie validatora jest ograniczone: czy source można sparsować jako pojedynczy JSON value? Tool nie naprawia source, nie wykonuje code, nie wywołuje API i nie ocenia, czy value jest użyteczne dla application. Schema i domain check wykonuj osobno.
Whitespace jest zwykle dozwolony dla czytelności, ale character wewnątrz string jest częścią danych. Sprawdź escape sequence, newline, Unicode i encoding przy użyciu parsera z production consumer.
Poprawny JSON document nie oznacza automatycznie poprawnego transport. HTTP header, content type, authentication, compression i size limit należą do innych warstw.
Jak sprawdzić JSON
- Wklej kompletny JSON value do source field. Usuń comment, code fence i wrapper programming language z test copy.
- Uruchom validator i przeczytaj status oraz diagnostic. Sprawdź tokeny przed i po marker, ponieważ prawdziwa przyczyna może znajdować się wcześniej.
- Po odrzuceniu sprawdź quote, comma, bracket, escape i nesting. Duży document podziel tymczasowo, znajdź failing section i wyślij poprawioną wersję ponownie.
- Po przejściu syntax uruchom kontrole schema, type, required property, range, permission i business rule projektu. Nie zapisuj ich jako syntax result.
- Przechowuj original payload i redacted copy osobno. Nie umieszczaj secret w public example, screenshot ani URL.
- Końcowy integration test wykonaj z tym samym parserem i encoding, którego używa prawdziwy consumer. Różne language i library mogą inaczej obsługiwać duplicate key oraz number precision.
Metoda validation
- Czytanie grammar
Validator używa reguł token, quote, delimiter i nesting, aby spróbować sparsować cały source jako jeden JSON value.
- Raportowanie wyniku
Valid oznacza zakończone parsing. Failure oznacza, że source nie pasuje do rozumianej przez tool syntax.
- Oddzielenie kolejnych kontroli
Schema, range, permission i domain to semantic check, które wymagają osobnych reguł i evidence.
Jeżeli tool nie dokumentuje exact line number albo error message, nie wymyślaj tych informacji. W razie potrzeby sprawdź je w rzeczywistym runtime.
Czytanie wyniku
Valid oznacza, że text został zaakceptowany jako JSON syntax. Następnie sprawdź values i uruchom schema lub application validation.
Invalid oznacza zatrzymanie parsing. Sprawdź character przed i po wskazanym miejscu, a nie tylko marker.
Jeżeli syntax jest valid, ale request kończy się błędem, sprawdź content type, endpoint, authentication, schema i business rule. Syntax success nie oznacza network success.
Przy ogólnym message zmniejsz input, aby znaleźć failing section. Zmiana wyniku po dodaniu lub usunięciu property jest wskazówką, a nie uniwersalną policy każdego parsera.
Typowe błędy
Wklejenie JavaScript z single quote, comment lub trailing comma jest częstym błędem. Przekształć go do standard JSON.
Traktowanie valid result jak schema validation jest błędne. Required field, range i permission sprawdzaj osobno.
Zmiana tylko character przy error marker może nie pomóc, bo brakujący quote lub comma może być wcześniejszy.
Nie utożsamiaj JSON z Python dictionary, YAML ani JavaScript object. Używaj documented JSON grammar.
Clipboard może dodać smart quote albo ukryty control character. Gdy wyniki się różnią, obejrzyj source w plain text editor.
Ograniczenia
Udokumentowany input to jedno JSON text field. Nie dowodzi to obsługi JSON Schema, business rule, file processing ani wszystkich parser edge case.
Duplicate key, bardzo duże numbers, document size i encoding testuj osobno, gdy jest to potrzebne. Policy zależy od library.
Checker nie zabezpiecza złośliwego payload. Server nadal potrzebuje size limit, nesting limit, resource limit i security review.
Osobno dokumentuj production runtime, library version oraz error policy. Ogólny wynik strony nie zastępuje tego evidence.
Examples
Prosty object zaakceptowany
Czy ten podstawowy object jest poprawnym JSON?
Wyślij cały object.
Name w double quote, string i boolean tworzą valid object structure.
Nazwa bez quote odrzucona
Dlaczego unquoted property name jest invalid?
Wyślij source i odczytaj failure.
W standardowym JSON member name musi być stringiem w double quote.
Dane zagnieżdżone zaakceptowane
Czy object może zawierać array z objects?
Wyślij nested value jako jeden document.
Array, object, number, comma i bracket tworzą poprawną JSON structure.
Trailing comma odrzucony
Co robi comma po ostatnim member?
Wyślij object z trailing comma.
Standard JSON nie dopuszcza trailing comma. Usuń ją i sprawdź ponownie.
Wartość null
Czy null jest valid JSON value?
Wyślij object i odczytaj status.
null jest standardową JSON value. Znaczenie w application określa project contract.
Brak bracket odrzucony
Dlaczego opening bracket trzeba zamknąć?
Wyślij niezrównoważoną structure.
Array otwiera się przez [ lecz nie zamyka przez ]. Popraw nesting przed użyciem data.
Frequently asked questions
Czy valid JSON oznacza poprawne dane application?
Nie. Oznacza tylko, że text można sparsować. Required field, type, range, status i business rule wymagają osobnych kontroli.
Czy validator automatycznie naprawia source?
Używaj go jako checker. Popraw source samodzielnie, zachowaj diff i wyślij ponownie sprawdzoną copy.
Czy comment jest dozwolony?
Standardowy JSON nie zawiera comment. Zachowaj je w innym source format, w build step wygeneruj strict JSON i sprawdź output.
Dlaczego single quote jest odrzucany?
Name i string w standardowym JSON używają double quote. JavaScript object konwertuj przez JSON serializer zamiast ręcznej zamiany quote.
Czy tool sprawdza JSON Schema?
Nie. Uruchom schema validator z właściwym schema i draft version, a wynik zapisz osobno od syntax result.
Czy top-level value może być array?
JSON dopuszcza array jako top-level value, ale endpoint może wymagać object. Testuj endpoint contract oddzielnie.
Czy duplicate key zawsze jest odrzucany?
Nie ma jednej policy. Parser może zachować pierwszą, ostatnią wartość albo zwrócić error. Unikaj duplicate name i testuj prawdziwy consumer.
Co zrobić po udanej validation?
Uruchom schema, permission, range i integration test. Sprawdź content type, encoding, size, timeout i logging, a redacted payload przetestuj w staging.