JSON Biçimlendir

JSON—JavaScript Object Notation—yapılandırılmış veri alışverişi için her yerde bulunan, metin tabanlı bir formattır. Hem IETF tarafından RFC 8259 olarak hem de Ecma International tarafından ECMA-404olarak standartlaştırılmıştır; bunlar birlikte modern API'leri, günlükleri, yapılandırmaları ve veritabanlarını güçlendiren kompakt, dilden bağımsız sözdizimini tanımlar.

Sözdizimi ve kodlama: sistemlerin konuşmasını sağlayan hassas bitler

Bir JSON değeri ya bir nesne, dizi, dize, sayı ya da true, false veya null değişmezlerinden biridir; nesneler dizeleri değerlere eşler ve diziler sıralı değerler tutar—yapısal karakterlerin etrafında önemsiz boşluklara izin verilir (RFC 8259, ECMA-404). JSON, JavaScript'ten kaynaklanmasına rağmen, dilden bağımsızdır ve neredeyse her yerde desteklenir (MDN: JSON). Kablo üzerinde, fiili ve önerilen kodlama UTF-8'dir (RFC 8259 §8.1). Ekstra birlikte çalışabilirlik güvenliği için, I-JSON profili (RFC 7493) kodlamalar ve sayısal aralıklar etrafındaki kuralları sıkılaştırır.

JavaScript'te, genel JSON nesnesi iki beygir gücü sunar:JSON.parse (isteğe bağlı bir reviver ile) ve JSON.stringify (güzel yazdırma için değiştirici/boşluk bırakma ile), MDN'de belgelendiği gibi (parse, stringify).

Sayılar: aldatıcı derecede basit, şaşırtıcı derecede keskin

JSON'un sayı dilbilgisi ondalıktır, ancak belirtim kesinlik veya tamsayı/kayan nokta ayrımlarını dikte etmez. Uygulamalar bunları nasıl temsil edeceklerini seçerler (RFC 8259 §6). JavaScript ve Node.js'de, Number IEEE-754 çift duyarlılıktır, yani yalnızca [−(2^53−1), 2^53−1] içindeki tamsayılar tam olarak güvenlidir—bkz. Number.MAX_SAFE_INTEGER ve BigInt türü. Bu nedenle genel API'ler genellikle kimlikleri dize olarak gönderir ve “güvenli tamsayıları” açıkça doğrular.

Vanilya JSON'un ötesinde: işaretçiler, yamalar ve birleştirme yamaları

Kullanım olgunlaştıkça, JSON'u yerinde adreslemek ve değiştirmek için standartlar ortaya çıktı. JSON İşaretçisi (RFC 6901) değerleri bulmak için küçük, eğik çizgiyle ayrılmış bir sözdizimidir (örneğin, /a/b/0) ve ~ ve / için kaçış kuralları vardır. JSON Yaması (RFC 6902) kısmi güncellemeleri sıralı işlemler (add, remove, replace, move, copy, test) olarak modeller ve application/json-patch+json olarak seyahat eder. Daha basit farklar için, JSON Birleştirme Yaması (RFC 7386) belge şeklinde bir birleştirme kullanır: mevcut alanlar eklenir/değiştirilir; bir alanı null olarak ayarlamak onu siler. Birçok çerçeve, kutudan çıktığı gibi bir veya her iki formu da destekler.

Şemalar ve türler: doğrulama ve oluşturma

JSON'un kendisi şemasızdır, ancak ekosistemler doğrulama, belgeleme ve kod oluşturma için şemalara dayanır. JSON Şeması 2020-12 ailesi, type, properties, items ve kompozisyon anahtar kelimeleri gibi kısıtlamaları belirtir ve OpenAPI 3.1ile uyumludur. Kod oluşturma merkezli iş akışları için, JSON Tür Tanımı (RFC 8927) ana akım tür sistemlerine tahmin edilebilir şekilde eşlenen, kasıtlı olarak daha az ifade gücüne sahip bir dil sunar.

Akış ve büyük veri: JSON satırları ve dizileri

Klasik JSON, yük başına bir tam metin bekler, bu da akış günlüklerini ve uzun ömürlü yanıtları karmaşıklaştırır. İki desen yardımcı olur:

• JSON Metin Dizileri (RFC 7464): her biri Kayıt Ayırıcı (U+001E) ile ön eklenmiş ve LF ile biten bir UTF-8 JSON metinleri akışı; application/json-seq olarak kaydedilmiştir.
• NDJSON / JSON Satırları: her satır bağımsız bir JSON değeridir—takip etmesi, gzip'lemesi ve map-reduce yapması kolaydır (ndjson.org, jsonlines.org). Elasticsearch'ün Toplu API'sigibi toplu API'lerde popülerdir.

İkili kuzenler: metin yeterince kompakt olmadığında

Bant genişliği veya hız baskın olduğunda, "ikili JSON" biçimleri JSON'un veri modelini korurken verimlilik için insan okunabilirliğinden ödün verir:

• BSON (MongoDB'nin yerel formatı) ikili, tarih/saat ve tipli tamsayılar gibi türler ekler (bsonspec.org).
• MessagePack kompakt ve şemasızdır, diller arasında yaygın olarak uygulanır (msgpack.org).
• CBOR genişletilebilir, kompakt bir formatı ( JSON dönüştürme kılavuzu ile) standartlaştırır ve IoT/kısıtlı bağlamlarda yaygındır (RFC 8949, cbor.io).
• Smile (Jackson ekosisteminden) JSON'u tekrarlanan adlar/değerler için isteğe bağlı geri başvurularla kodlar (jackson-dataformat-smile).

Güvenlik notları: eski numaralar ve modern düzeltmeler

JSON yalnızca metin olduğu için, çoğu risk onu nasıl taşıdığınızdan ve işlediğinizden kaynaklanır:

• JSONP (<script> aracılığıyla veri isteme bir geri arama ile) çapraz kaynak istekleri için bir CORS öncesi geçici çözümdü ancak tehlikelidir—keyfi komut dosyası yürütür. Gerçek application/json yanıtlarıyla CORS'u tercih edin (OWASP: JSONP Kötüye Kullanımı).
• JSON kaçırma: hassas dizileri döndüren saf GET uç noktaları eski tarayıcılarda çapraz kaynak komut dosyası etiketleri aracılığıyla çalınabilir; azaltma önlemleri arasında CSRF korumalı POST veya JSON olmayan bir nöbetçi ile ön ekleme bulunur (OWASP: JSON Kaçırma).
• JSON enjeksiyonu: JSON'u kod olarak değil, veri olarak ele alın; özenle kaçış yapın ve girdileri doğrulayın (OWASP: JSON Enjeksiyonu).

Medya türleri ve miras

JSON, RFC 4627 (2006)altında piyasaya sürüldü; kayıtlı medya türü application/json'dur ve belirtimi şimdi RFC 8259'a işaret etmektedir. JSON yanıtlarındaki "charset" parametreleri genellikle gereksizdir çünkü UTF-8 genel internette varsayılandır.

Üretimde sağlam JSON için pratik ipuçları

• Her yerde varsayılan olarak UTF-8 kullanın; girdi ve çıktıda UTF-8 varsayın (RFC 8259 §8.1).
• Büyük tamsayılarla açık olun: bir kimlik 2^53−1'i aşabilirse, onu bir dize olarak gönderin ve belgeleyin (MDN: MAX_SAFE_INTEGER).
• Yükleri JSON Şeması 2020-12 (veya JTD kod oluşturma ağırlıklı yığınlar için) ile doğrulayın. API belgelerinizin yanında şemaları yayınlayın (OpenAPI 3.1).
• Akıllıca yama yapın: işlem düzeyindeki farklar için JSON Yaması ve basit belge şeklindeki güncellemeler için Birleştirme Yaması kullanın.
• Büyük ölçekte akış yapın: JSON Metin Dizileri veya NDJSON'u günlükler ve uzun ömürlü yanıtlar için seçin; medya türünü açıkça belirtin.
• İkiliye başvurun ( BSON, MessagePack, CBOR, Smile) metin darboğaz olduğunda—ancak her iki ucun da türler üzerinde anlaştığından emin olun.

“Daha dostane JSON'lar” üzerine kısa bir not

Geliştiriciler genellikle yapılandırmalarda yorumlar, sonda virgüller veya tek tırnaklı dizeler isterler. Bu, standart JSON'un dışındadır, ancak JSON5 insan tarafından düzenlenen dosyalar için iyi belgelenmiş bir üst küme sağlar. Her iki ucu da kontrol etmiyorsanız genel API'ler üzerinden JSON5 göndermekten kaçının.

JSON'un başarısı, küçük bir yüzey alanından, geniş dil desteğinden ve dağıtılmış sistemlerin dağınık gerçeklerini kapsayan bir dizi bitişik standarttan—işaretçiler, yamalar, şemalar, diziler—gelir. Temelleri (sözdizimi, kodlama, sayılar) anlayın, doğru bitişik standartlara dayanın ve yığınlar ve hizmetler arasında temettü ödemeye devam edecektir (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).