PDFResim
Rehberler
Metin5 dk okuma

JSON Formatlama ve Doğrulama: Bozuk JSON'u Bulmak

Bir API'den dönen yanıtı kopyalıyorsunuz ve karşınıza tek satırlık, binlerce karakterlik bir JSON yığını çıkıyor. İçinde aradığınız alanı bulmak neredeyse imkânsız. Ya da daha kötüsü: yazdığınız JSON'u sistem kabul etmiyor ve "geçersiz" diyor ama hatanın nerede olduğunu söylemiyor. Bu rehberde JSON'u okunabilir hâle getirmeyi, en sık yapılan sözdizimi hatalarını ve bozuk bir JSON'da hatayı hızlıca bulmayı anlatıyoruz.

Formatlama Neden İşe Yarar?

JSON, makinelerin okuması için tasarlanmış bir veri biçimidir; boşluk ve satır sonu onun için anlam taşımaz. Bu yüzden sistemler veriyi mümkün olduğunca sıkıştırıp tek satırda gönderir — ağ üzerinden daha az veri taşımak için mantıklı bir tercihtir.

İnsan gözü içinse bu okunamaz bir duvardır. Formatlama, veriyi anlamını hiç değiştirmeden girintili ve satırlara bölünmüş hâle getirir. İç içe geçmiş yapılar görünür olur; hangi alanın hangi nesnenin içinde olduğunu bir bakışta anlarsınız.

Ters yönde de işe yarar: okunabilir hâlde yazdığınız bir yapılandırma dosyasını tek satıra küçültmek, bazı ortamlarda (ortam değişkenleri, komut satırı argümanları) gereklidir. pdfresim.com'daki JSON Formatla aracı her iki yönü de yapar.

En Sık Yapılan Dört Hata

JSON'un kuralları katıdır ve JavaScript'e benzemesi yanıltıcıdır; JavaScript'te geçerli olan birçok şey JSON'da geçersizdir. Geçersiz JSON'ların büyük çoğunluğu şu dört hatadan birini içerir.

  • Sondaki fazla virgül: son elemandan sonra virgül bırakmak. JavaScript buna izin verir, JSON vermez.
  • Tek tırnak: JSON yalnızca çift tırnak kabul eder; 'ad' geçersizdir, "ad" geçerlidir.
  • Tırnaksız anahtar: {ad: "Ali"} geçersizdir, {"ad": "Ali"} geçerlidir.
  • Yorum satırı: JSON yorum desteklemez; // veya /* */ eklerseniz dosya geçersiz olur.

Hatayı Hızlı Bulmanın Yolu

Doğrulayıcılar genellikle "satır 47, karakter 12'de beklenmeyen simge" gibi bir mesaj verir. Bu mesaj yardımcıdır ama yanıltıcı da olabilir: bildirilen konum çoğu zaman hatanın kendisi değil, hatanın fark edildiği yerdir.

Örneğin 20. satırda kapatılmayan bir parantez, hata olarak 47. satırda görünebilir; çünkü ayrıştırıcı oraya kadar sorun yaşamaz. Bu yüzden bildirilen satırın biraz öncesine bakmak gerekir.

Pratik bir yöntem: JSON'u formatlayın. Formatlama sırasında girintiler bozuksa, yapının nerede beklenmedik şekilde kapandığını gözle görürsünüz. Çok büyük dosyalarda ise ikiye bölerek ilerlemek işe yarar: yarısını doğrulayın, hata hangi yarıdaysa onu tekrar bölün.

Hassas Veriyle Çalışırken

API yanıtları çoğu zaman kişisel veri, kimlik bilgisi ya da erişim anahtarı içerir. Bu tür içerikleri rastgele çevrimiçi araçlara yapıştırmak, farkında olmadan veri sızdırmanın yaygın bir yoludur.

Kullandığınız aracın işlemi nerede yaptığını bilmek önemlidir. pdfresim.com'daki JSON Formatla aracı tarayıcınızda çalışır; yapıştırdığınız içerik sunucuya gönderilmez. Yine de üretim ortamına ait erişim anahtarları söz konusuysa, önce bu alanları temizlemek en sağlıklı alışkanlıktır.

  • Erişim anahtarı ve parola içeren alanları yapıştırmadan önce temizleyin.
  • Kullandığınız aracın verinizi nereye gönderdiğini kontrol edin.
  • Müşteri verisi içeren yanıtlarda örnek kayıt sayısını azaltın.
  • İşiniz bitince panoyu temizleyin; kopyaladığınız veri orada kalır.

Geçerli JSON Her Zaman Doğru JSON Değildir

Bir JSON'un sözdizimsel olarak geçerli olması, içeriğinin doğru olduğu anlamına gelmez. Doğrulayıcı yalnızca biçimi kontrol eder: parantezler kapanmış mı, tırnaklar doğru mu, virgüller yerinde mi.

Beklenen alanın eksik olması, bir sayının metin olarak gönderilmesi ya da tarihin yanlış biçimde yazılması sözdizimi hatası değildir; JSON geçerli görünür ama sistem yine de kabul etmez. Bu tür sorunlarda hata mesajı genellikle ayrıştırma değil, doğrulama katmanından gelir.

Bu ayrımı bilmek zaman kazandırır: "JSON geçerli ama sistem kabul etmiyor" durumunda sözdizimini aramayı bırakıp alan adlarını ve veri türlerini karşılaştırmaya geçin.

Sık Karşılaşılan Tür Sorunları

Sözdizimi doğruyken sistemin veriyi reddetmesinin arkasında genellikle veri türü uyuşmazlığı vardır. JSON'da tırnak içindeki her şey metindir ve bu ayrım gözden kaçar.

En sık görüleni sayıların metin olarak gönderilmesidir: "fiyat": "100" ile "fiyat": 100 farklı şeylerdir. Alıcı sistem sayı bekliyorsa ilkini reddeder. Aynı şekilde "aktif": "true" bir metindir, mantıksal değer değildir.

Tarihler ayrı bir tuzaktır; JSON'da tarih türü yoktur ve her sistem kendi biçimini bekler. Gün-ay-yıl sıralaması ve saat dilimi bilgisi çoğu uyuşmazlığın kaynağıdır; ISO 8601 biçimini kullanmak en güvenli yoldur.

Son olarak boş değer meselesi var: null, boş metin ve alanın hiç bulunmaması üç ayrı durumdur. Bazı sistemler bunları aynı sayar, bazıları saymaz; entegrasyon hatalarının kayda değer bir kısmı buradan çıkar.

Sık sorulan sorular

Formatlama verimi değiştirir mi?

Hayır. Formatlama yalnızca boşluk ve satır sonlarını düzenler; alanlar, değerler ve yapı aynen kalır. Formatlanmış ve küçültülmüş iki JSON, makine açısından birebir aynı veridir.

JSON'da yorum satırı kullanabilir miyim?

Hayır, JSON standardı yorum desteklemez. Yapılandırma dosyalarında açıklama gerekiyorsa yaygın çözüm, "_comment" gibi bir alan eklemek ya da yorum destekleyen JSON5/YAML gibi biçimlere geçmektir.

Çok büyük bir JSON'u nasıl inceleyebilirim?

Önce formatlayıp yapıyı görün, ardından ihtiyacınız olan bölüme odaklanın. Onlarca megabaytlık dosyalarda tarayıcı yavaşlayabilir; bu durumda dosyayı bölmek ya da komut satırı araçları kullanmak daha pratiktir.

Hata satırı doğru mu gösteriliyor?

Gösterilen konum, hatanın fark edildiği yerdir; gerçek hata çoğu zaman biraz yukarıdadır. Kapatılmayan bir parantez, çok daha aşağıda hata olarak raporlanabilir. Bildirilen satırın öncesine bakmak alışkanlık hâline gelmeli.

İlgili ücretsiz araçlar