JSON Dosyası ile Çalışmak: Biçimlendirme, Doğrulama ve CSV'ye Taşıma

Tek satıra sıkışmış bir veri bloğunu okunur hâle getirmek, hatalı virgülü bulmak ve tabloya taşımak. Günlük geliştirme işinde en sık tekrarlanan üç adımı sırayla ele alıyoruz.

7 dakika ToolsBasic
JSON Dosyası ile Çalışmak: Biçimlendirme, Doğrulama ve CSV'ye Taşıma

Bir uygulamadan dışa aktarılan veri, çoğu zaman tek satırlık ve boşluksuz bir metin bloğu olarak gelir. Gözle okunmaz, hatayı bulmak imkânsızdır ve bir e-tabloya yapıştırmak hiç işe yaramaz. Bir JSON dosyası ile çalışmanın gündelik hâli tam olarak budur: önce okunur hâle getirmek, sonra geçerli olduğundan emin olmak, en sonunda da veriyi ihtiyacınız olan biçime taşımak. Bu üç adımı sırayla ele alalım.

İşin araçları basit: girintileme ve söz dizimi denetimi için JSON düzenleyici, veriyi tabloya almak için JSON'dan CSV'ye dönüştürücü, tersi yön için CSV'den JSON'a dönüştürücü. Gömülü ikili veriyi çözmek gerektiğinde Base64 kodlayıcı / çözücü, adres alanlarını okumak için URL kodlayıcı / çözücü devreye girer.

JSON dosyası biçimlendirme: tek satırı okunur hâle getirmek

Girintileme veriyi değiştirmez, yalnızca boşluk ekler. Yine de etkisi büyüktür: iç içe geçmiş yapıların derinliği görünür olur, eksik bir kapanış parantezi göze çarpar ve hangi alanın hangi nesneye ait olduğu netleşir. Üretim ortamına giden veri sıkıştırılmış hâlde kalmalıdır, ama incelerken okunur hâle getirmek zaman kazandırır.

Girintileme sırasında dikkat edilecek tek şey karakter kodlamasıdır. Türkçe karakter içeren bir metin yanlış kodlamayla açıldığında bozuk görünür; sorun verinin kendisinde değil, açıldığı yerdedir. Aynı içeriği doğru kodlamayla açtığınızda düzelir.

Anahtar sırası ve okunabilirlik

Bir nesnedeki alanların sırası teknik olarak anlamsızdır; yazılım hangi sırayla gelirse gelsin aynı sonucu üretir. Ama insan gözü için sıra çok şey ifade eder. Elle bakacağınız bir çıktıda kimlik alanlarını başa, uzun metinleri sona almak, aynı veriyi iki kat hızlı taramanızı sağlar.

Doğrulama: bir JSON dosyası neden bozulur

Bir dosyanın geçerli olup olmadığını anlamanın tek güvenilir yolu onu bir ayrıştırıcıdan geçirmektir; gözle bakarak karar vermek, özellikle iç içe yapılarda yanıltıcıdır. Söz dizimi hatalarının neredeyse tamamı birkaç kalıba iner. Hata mesajını okumayı öğrenmek, dosyada rastgele arama yapmaktan çok daha hızlıdır; mesaj size satır ve sütun verir, oradan geriye doğru bakmanız yeterlidir.

  • Fazladan virgül. Son elemandan sonra bırakılan virgül en yaygın hatadır. Elle düzenlenen dosyalarda neredeyse kural hâline gelmiştir.
  • Tek tırnak. Anahtarlar ve metin değerleri çift tırnak ister. Tek tırnak başka dillerde geçerlidir, burada değildir.
  • Kaçışsız tırnak. Metnin içindeki çift tırnak kaçış karakteri almadan yazıldığında değer erken kapanır.
  • Yorum satırı. Biçim yorum kabul etmez. Yapılandırma dosyalarına eklenen açıklama satırları dosyayı geçersiz kılar.
  • Görünmez karakterler. Bir web sayfasından kopyalanan metin, gözle görünmeyen boşluk karakterleri taşıyabilir.

Hata mesajı satır numarası veriyorsa doğrudan oraya gidin; vermiyorsa dosyayı ikiye bölüp hangi yarının geçerli olduğunu bulmak, yüz satırlık bir dosyada hatayı yedi denemede bulmanızı sağlar.

Geçerli olmak, doğru olmak değildir

Söz dizimi denetiminden geçen bir veri, beklediğiniz alanları içerdiği anlamına gelmez. Sayı olması gereken bir alan metin olarak gelmiş olabilir, zorunlu bir alan eksik olabilir, tarih biçimi farklı olabilir. Bu kontrolleri gözle yaparken küçük bir listeyle çalışmak işe yarar: zorunlu alanlar, tip beklentileri ve boş geçilemeyecek değerler.

Tabloya taşımak: düz veri ve iç içe veri

Dönüşümün en çok yanlış anlaşılan tarafı burasıdır. Tablo biçimi düzdür: satırlar ve sütunlar. Veri yapısı ise ağaç gibidir, bir alan başka bir nesne ya da liste içerebilir. Düz bir nesne listesi tabloya sorunsuz oturur; iç içe yapılar bir karar gerektirir.

Veri şekliTabloya çevrilebilir miNe yapmalı
Düz nesnelerden oluşan listeDoğrudanHer alan bir sütun olur
İç içe tek nesneKısmenAlt alanlar nokta ile birleştirilir
Alan içinde diziHayırAyrı bir tabloya çıkarılır
Farklı alanlara sahip nesnelerKısmenBirleşik sütun kümesi, boş hücreler
Tek bir değerAnlamsızTabloya taşımaya gerek yok

Tersi yönde, yani tablodan veri yapısına geçerken en sık karşılaşılan sorun tip kaybıdır. Tablo hücresinde her şey metindir; 007 gibi bir değer sayıya çevrildiğinde baştaki sıfırlar kaybolur, tarihler yerel biçime göre farklı yorumlanır. Kimlik numaralarını ve kodları metin olarak tutmak bu sorunu baştan bitirir.

Alan adları ve yapı disiplini

Veri alışverişinde en pahalı hatalar söz diziminde değil, adlandırmada yapılır. İki sistem aynı bilgiyi farklı adlarla ürettiğinde, aradaki dönüşüm katmanı zamanla özel durumlarla dolar ve kimse ona dokunmaya cesaret edemez. Bunu önlemenin yolu, en baştan küçük bir sözlük tutmaktır: her alanın adı, tipi, birimi ve boş geçilip geçilemeyeceği.

Adlandırmada üç kural yeterli. Bir: tek bir yazım biçimi seçin ve ona sadık kalın; aynı dosyada hem musteriAdi hem musteri_adi görmek, dosyanın iki farklı elden geçtiğinin işaretidir. İki: kısaltmalardan kaçının. ttl alanı bir hafta sonra kimsenin hatırlamadığı bir bilmeceye dönüşür. Üç: birim bilgisini adın içine koyun. sure yerine sure_saniye yazmak, ileride yaşanacak bir hesaplama hatasını baştan engeller.

Yapı tarafında en sık yapılan hata, gereksiz derinliktir. Beş katman iç içe geçmiş bir nesne, veriyi düzenli göstermez; yalnızca ona ulaşan her kodu uzatır. Genel kural olarak, bir alana ulaşmak için üçten fazla adım atıyorsanız yapı fazla derindir. Aynı şekilde, sayısı zamanla artacak şeyleri alan adı yapmak yerine liste hâlinde tutmak gerekir; her yeni değer için yeni alan açan bir yapı, birkaç ay içinde bakımsız kalır.

Son olarak boş değerler. Bir alanın yokluğu ile boş gelmesi farklı şeylerdir ve tüketen taraf bu ikisini karıştırdığında sessiz hatalar üretir. Hangisinin ne anlama geldiğini bir kez kararlaştırıp yazın; bu tek cümle, ileride saatlerce sürecek bir hata avını önler.

Sürüm değiştiğinde ne olur

Veri yapıları donmuş değildir; alan eklenir, ad değişir, tip güncellenir. Sorun değişikliğin kendisi değil, haber verilmeden yapılmasıdır. Tüketen tarafın beklemediği bir değişiklik, çoğu zaman hata bile vermez; yalnızca yanlış sonuç üretir ve bu haftalarca fark edilmez.

Güvenli yol şudur: yeni alan eklemek serbesttir, var olan bir alanı silmek ya da anlamını değiştirmek değildir. Bir alanı gerçekten kaldırmanız gerekiyorsa önce yeni alanı ekleyin, iki alanı bir süre birlikte yayınlayın, tüketen taraflar geçtikten sonra eskisini kaldırın. Bu üç adımlı geçiş yavaş görünür ama tek bir sessiz hatanın maliyetinden her zaman ucuzdur.

Günlük işte işe yarayan küçük alışkanlıklar

  • Küçük bir örnekle başlayın. Elli bin satırlık bir dosyayı doğrudan işlemek yerine ilk yüz satırla deneyin; hata varsa saniyeler içinde görürsünüz.
  • Alan adlarını sabitleyin. Aynı veriyi üreten iki sistemde alan adları farklıysa, dönüşüm tarafında sürekli özel durum yazarsınız.
  • Karşılaştırmayı gözle yapmayın. İki çıktı arasındaki farkı bulmak için metin fark kontrolü hem daha hızlı hem daha güvenilirdir.
  • Boyutu takip edin. Girintilenmiş bir dosya, sıkıştırılmış hâlinin iki katına çıkabilir; ağ üzerinden taşıyacaksanız girintiyi kaldırın.

Sık sorulan sorular

Veri neden tarayıcıda bozuk görünüyor?

Neredeyse her zaman karakter kodlaması yüzünden. İçerik doğru kaydedilmiş olsa bile, açan taraf farklı bir kodlama varsayarsa Türkçe karakterler bozulur. Dosyanın kendisini değiştirmeden önce açtığınız yerin kodlama ayarını kontrol edin.

Yapılandırma dosyalarına yorum ekleyebilir miyim?

Biçim buna izin vermez. Yaygın çözüm, açıklamayı normal bir alan olarak eklemektir: adı _note gibi bir şey olan, yazılımın görmezden geldiği bir alan. Çirkin ama işe yarar ve dosyayı geçersiz kılmaz.

Büyük dosyalarla nasıl çalışılır?

Yüzlerce megabaytlık veriyi tarayıcıda açmak makul değildir. Böyle durumlarda dosyayı satır bazlı bir yapıya bölmek, yani her satırda bağımsız bir kayıt tutmak, hem işlemeyi hem de hata ayıklamayı kolaylaştırır.

Gömülü ikili veriyle ne yapmalı?

İkili içerik metin biçiminde taşınırken kodlanır ve okunamaz görünür. Bu içeriği incelemek için önce çözmek gerekir; boyutunun yaklaşık üçte bir oranında şiştiğini de hesaba katın, büyük dosyaları bu şekilde taşımak verimli değildir.

Çıktıyı e-tabloda açarken nelere dikkat etmeli?

Tablo programları dosyayı açarken tahmin yürütür: ayırıcıyı, ondalık işaretini ve karakter kodlamasını kendi yerel ayarına göre seçer. Bu tahmin yanlış olduğunda bütün satırlar tek sütuna düşer ya da sayılar tarihe dönüşür. İçe aktarma sihirbazını kullanıp bu üç değeri elle belirtmek, sonradan veriyi temizlemeye çalışmaktan çok daha hızlıdır.

Yapılandırma dosyalarında saklanan anahtarlar ve kimlikler için güçlü parola ve güvenli kimlik üretimi yazısına, veriyi bir bağlantı ya da kart hâline getirip paylaşacaksanız QR kod kullanım rehberine bakabilirsiniz.

İlgili araçlar

Katalog

Blog Yazıları