Formatuj JSON

JSON—JavaScript Object Notation—to wszechobecny, tekstowy format do wymiany danych strukturalnych. Jest on standaryzowany zarówno przez IETF jako RFC 8259 , jak i przez Ecma International jako ECMA-404, które razem definiują zwartą, niezależną od języka składnię, która napędza nowoczesne interfejsy API, logi, konfiguracje i bazy danych.

Składnia i kodowanie: precyzyjne bity, które utrzymują systemy w komunikacji

Wartość JSON to obiekt, tablica, ciąg znaków, liczba lub jeden z literałów true, false lub null; obiekty mapują ciągi znaków na wartości, a tablice przechowują uporządkowane wartości—z nieznaczącym białym znakiem dozwolonym wokół znaków strukturalnych (RFC 8259, ECMA-404). Chociaż JSON wywodzi się z JavaScriptu, jest niezależny od języka i obsługiwany praktycznie wszędzie (MDN: JSON). W transmisji danych de facto i zalecanym kodowaniem jest UTF-8 (RFC 8259 §8.1). Dla dodatkowego bezpieczeństwa interoperacyjności, profil I-JSON (RFC 7493) zaostrza zasady dotyczące kodowań i zakresów numerycznych.

W JavaScript globalny obiekt JSON udostępnia dwa podstawowe narzędzia:JSON.parse (z opcjonalnym reviver) oraz JSON.stringify (z replacerem/odstępami do ładnego drukowania), jak udokumentowano na MDN (parse, stringify).

Liczby: zwodniczo proste, zaskakująco ostre

Gramatyka liczb w JSON jest dziesiętna, ale specyfikacja nie narzuca precyzji ani rozróżnienia między liczbami całkowitymi a zmiennoprzecinkowymi. Implementacje wybierają, jak je reprezentować (RFC 8259 §6). W JavaScript i Node.js Number to podwójna precyzja IEEE-754, co oznacza, że tylko liczby całkowite w zakresie [−(2^53−1), 2^53−1] są w pełni bezpieczne—zobacz Number.MAX_SAFE_INTEGER i typ BigInt. Dlatego publiczne interfejsy API często przesyłają identyfikatory jako ciągi znaków i jawnie walidują „bezpieczne liczby całkowite”.

Poza standardowym JSON: wskaźniki, łatki i łatki scalające

W miarę dojrzewania użycia pojawiły się standardy do adresowania i modyfikowania JSON w miejscu. JSON Pointer (RFC 6901) to niewielka składnia z ukośnikami do lokalizowania wartości (np. /a/b/0) z regułami ucieczki dla ~ i /. JSON Patch (RFC 6902) modeluje częściowe aktualizacje jako uporządkowane operacje (add, remove, replace, move, copy, test) i jest przesyłany jako application/json-patch+json. Dla prostszych różnic, JSON Merge Patch (RFC 7386) używa scalania w kształcie dokumentu: obecne pola są dodawane/zastępowane; ustawienie pola na null usuwa je. Wiele frameworków obsługuje jedną lub obie formy od razu po wyjęciu z pudełka.

Schematy i typy: walidacja i generowanie

Sam JSON jest bezschematowy, ale ekosystemy opierają się na schematach do walidacji, dokumentacji i generowania kodu. Rodzina JSON Schema 2020-12 określa ograniczenia takie jak type, properties, items i słowa kluczowe kompozycji, i jest zgodna z OpenAPI 3.1. Dla przepływów pracy skoncentrowanych na generowaniu kodu, JSON Type Definition (RFC 8927) oferuje celowo mniej wyrazisty język, który przewidywalnie mapuje się na główne systemy typów.

Strumieniowanie i duże zbiory danych: linie i sekwencje JSON

Klasyczny JSON oczekuje jednego kompletnego tekstu na ładunek, co komplikuje strumieniowanie logów i długotrwałe odpowiedzi. Pomagają dwa wzorce:

• Sekwencje tekstowe JSON (RFC 7464): strumień tekstów JSON w formacie UTF-8, z których każdy jest poprzedzony separatorem rekordów (U+001E) i zakończony LF; zarejestrowany jako application/json-seq.
• NDJSON / JSON Lines: każda linia to samodzielna wartość JSON—łatwa do śledzenia, kompresji gzip i przetwarzania map-reduce (ndjson.org, jsonlines.org). Jest popularny w masowych interfejsach API, np. w Bulk APIElasticsearch.

Binarni kuzyni: gdy tekst nie jest wystarczająco zwarty

Gdy przepustowość lub szybkość dominują, formaty „binarnego JSON” zachowują model danych JSON, zamieniając czytelność dla człowieka na wydajność:

• BSON (natywny format MongoDB) dodaje typy takie jak binarny, data/czas i typowane liczby całkowite (bsonspec.org).
• MessagePack jest zwarty i bezschematowy, szeroko implementowany w różnych językach (msgpack.org).
• CBOR standaryzuje rozszerzalny, zwarty format (z wskazówkami dotyczącymi transkodowania JSON) i jest powszechny w kontekstach IoT/ograniczonych (RFC 8949, cbor.io).
• Smile (z ekosystemu Jackson) koduje JSON z opcjonalnymi odwołaniami wstecznymi dla powtarzających się nazw/wartości (jackson-dataformat-smile).

Uwagi dotyczące bezpieczeństwa: stare sztuczki i nowoczesne poprawki

Ponieważ JSON to tylko tekst, większość zagrożeń wynika ze sposobu jego transportu i obsługi:

• JSONP (żądanie danych za pomocą <script> z wywołaniem zwrotnym) było obejściem przed-CORS dla żądań międzydomenowych, ale jest niebezpieczne—wykonuje dowolny skrypt. Preferuj CORS z prawdziwymi odpowiedziami application/json (OWASP: Nadużycie JSONP).
• Przechwytywanie JSON: naiwne punkty końcowe GET zwracające wrażliwe tablice mogły być kradzione za pomocą tagów skryptów międzydomenowych w starszych przeglądarkach; środki zaradcze obejmują POST z ochroną CSRF lub poprzedzanie nie-JSON-owym strażnikiem (OWASP: Przechwytywanie JSON).
• Wstrzykiwanie JSON: traktuj JSON jako dane, a nie kod; starannie unikaj i waliduj dane wejściowe (OWASP: Wstrzykiwanie JSON).

Typy mediów i dziedzictwo

JSON zadebiutował pod RFC 4627 (2006); zarejestrowany typ mediów to application/json, którego specyfikacja wskazuje teraz na RFC 8259. Parametry „charset” w odpowiedziach JSON są generalnie niepotrzebne, ponieważ UTF-8 jest domyślny w publicznym internecie.

Praktyczne wskazówki dotyczące solidnego JSON w produkcji

• Domyślnie używaj wszędzie UTF-8; zakładaj UTF-8 na wejściu i wyjściu (RFC 8259 §8.1).
• Bądź jawny w przypadku dużych liczb całkowitych: jeśli identyfikator może przekroczyć 2^53−1, prześlij go jako ciąg znaków i udokumentuj to (MDN: MAX_SAFE_INTEGER).
• Waliduj ładunki za pomocą JSON Schema 2020-12 (lub JTD dla stosów intensywnie generujących kod). Publikuj schematy obok dokumentacji API (OpenAPI 3.1).
• Mądrze stosuj łatki: używaj JSON Patch dla różnic na poziomie operacji i Merge Patch dla prostych aktualizacji w kształcie dokumentu.
• Strumieniuj na dużą skalę: wybierz Sekwencje tekstowe JSON lub NDJSON dla logów i długotrwałych odpowiedzi; jawnie określaj typ mediów.
• Sięgaj po formaty binarne ( BSON, MessagePack, CBOR , Smile), gdy tekst jest wąskim gardłem—ale upewnij się, że obie strony zgadzają się co do typów.

Szybkie słowo o „przyjaźniejszych JSON-ach”

Deweloperzy często chcą komentarzy, końcowych przecinków lub ciągów znaków w pojedynczych cudzysłowach w plikach konfiguracyjnych. To wykracza poza standardowy JSON, ale JSON5 zapewnia dobrze udokumentowany nadzbiór dla plików edytowanych przez człowieka. Unikaj wysyłania JSON5 przez publiczne interfejsy API, chyba że kontrolujesz obie strony.

Sukces JSON wynika z małej powierzchni, szerokiego wsparcia językowego i kręgu sąsiednich standardów—wskaźników, łatek, schematów, sekwencji—które obejmują nieuporządkowane realia systemów rozproszonych. Zrozumienie podstaw (składnia, kodowanie, liczby), oparcie się na odpowiednich sąsiednich standardach, a będzie on nadal przynosił dywidendy w różnych stosach i usługach (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).