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.
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.
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.
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.
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.
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.
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.
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.
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 şekli | Tabloya çevrilebilir mi | Ne yapmalı |
|---|---|---|
| Düz nesnelerden oluşan liste | Doğrudan | Her alan bir sütun olur |
| İç içe tek nesne | Kısmen | Alt alanlar nokta ile birleştirilir |
| Alan içinde dizi | Hayır | Ayrı bir tabloya çıkarılır |
| Farklı alanlara sahip nesneler | Kısmen | Birleşik sütun kümesi, boş hücreler |
| Tek bir değer | Anlamsız | Tabloya 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.
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.
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.
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.
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.
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.
İ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.
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.