CSV to JSON / JSON to CSV Converter - Veri Dönüştürücü

CSV ve JSON: iki serileştirme kültürü

JSON (JavaScript Object Notation) ve CSV (Comma-Separated Values) aynı işletme gerçekliğini farklı soyutluk düzeylerinde temsil eder. JSON; nesne, dizi, iç içe yapı ve tip bilgisine yakın bir ağaç modeli sunar. CSV ise satır ve sütunlardan oluşan düz bir tablodur. Bu ayrım, “otomatik dönüşümün” her zaman anlamsal olarak doğru olmayacağı anlamına gelir: API’den gelen zengin bir yanıtı tek tabloya indirirken hangi alanların birleştirileceği, dizilerin nasıl genişletileceği ve boş değerlerin nasıl kodlanacağı ayrı kararlar gerektirir.

Serileştirme ve deserialization

Serileştirme, bellekteki veri yapısının iletilebilir metne dönüştürülmesidir. Deserialization ise bu metnin tekrar yapıya çevrilmesidir. JSON tarafında sayı, dize, boolean, dizi ve nesne türleri doğrudan ifade edilir. CSV’de ise hücreler çoğu zaman düz metindir; tamsayı, ondalık veya tarih ayrımı tüketen uygulamanın yorumuna kalır. Bu yüzden üretim hatlarında JSON Schema, OpenAPI veya eşdeğer bir sözleşme olmadan CSV üretmek, sessiz veri bozulmasına yol açar: örneğin başta sıfırlarla gelen posta kodları, Excel’de sayıya dönüşerek baştaki sıfırı kaybedebilir.

RFC 4180 ve ayraç (delimiter) seçimi

RFC 4180, CSV alanlarının tırnaklanması, satır sonları ve özel karakterler için yaygın bir referanstır. Ayraç olarak çoğu ABD kaynaklı dosyada virgül; birçok Avrupa Excel dışa aktarımında ise noktalı virgül (;) görülür. Tab ve pipe (|) karakterleri de lojistik ve veri biliminde sık seçilir. Ayraç, ondalık ayırıcı ile çakıştığında (ör. 1.234,56) alanların tırnak içine alınması gerekir; aksi halde sütun kayması (column shift) oluşur. İki taraf da aynı satır sonu (LF vs CRLF) ve kaçış kurallarında anlaşmalıdır.

UTF-8, BOM ve Anadolu dilleri

UTF-8, Türkçe dahil çok baytlı karakterleri tek bir kodlama çatısında taşır. Ancak eski ofis dosyaları Windows-1254 veya ISO-8859-9 ile kaydedilmiş olabilir; yanlış kodlama okumasında “ç”, “ı” gibi bozulmalar görülür. UTF-8 BOM’lu dosyalarda ilk sütun adı görünmez karakterle başlayabilir; ETL boru hatlarında BOM’u ya strip edin ya da bilinçli biçimde koruyun. Tarayıcı tabanlı dönüştürücülerde panodan yapıştırılan metin, kaynak uygulamanın gizli biçimlendirmesini taşımayabilir; bu da “dosyada çalışan, sitede bozulan” senaryolarını üretir.

İç içe JSON ve düzleştirme (flattening)

İç içe nesneler genelde user.address.city gibi noktalı anahtarlarla düzleştirilir. Dizi alanları için üç strateji yaygındır: (1) JSON dizisini tek hücrede string olarak saklamak, (2) her eleman için satır çoğaltmak (explode), (3) ilişkisel modelde ayrı tablo üretmek. Hangisinin seçileceği raporlama ihtiyacına bağlıdır; yanlış strateji, benzersiz anahtar sayımını veya toplamları sessizce değiştirir.

Büyük veri ve tarayıcı sınırları

Tarayıcı tek iş parçacığı ve bellek modeli nedeniyle çok büyük tek parça metinlerde gecikme yaşanır. Üretimde akışlı (streaming) ayrıştırıcı, sunucu tarafı chunk işleme veya sütun projeksiyonu tercih edilir. İstemci tarafı işlemenin avantajı, verinin kendi sunucunuza gitmemesidir; dezavantajı ise cihazın kötü amaçlı yazılım, ekran kaydı veya paylaşımlı oturum riskidir. KVKK açısından işleme amacı, saklama süresi ve üçüncü taraf aktarımı ayrıca dokümante edilmelidir.

Özet tablo: hangi format ne zaman?

Excel ve “sessiz tip” dönüşümü

Elektronik tablolar, uzun numerik kimlikleri ve önünde sıfır bulunan kodları otomatik olarak sayıya çevirebilir; CSV’yi tekrar içe aktarırken veri sessizce bozulur. Bu riski azaltmak için sütunu metin formatında açmak, başına tek tırnak eklemek veya ayrı bir doğrulama katmanı çalıştırmak gerekir. JSON tarafında tırnaklı alanlar genelde metin olarak kalır; yine de büyük tamsayılar IEEE çift duyarlıkta kayba uğrayabilir.

NDJSON ve toplu API yanıtları

Bazı log ve veri akışları NDJSON (satır başına bir JSON nesnesi) kullanır; bunu klasik “tek kök dizisi” JSON’dan ayırt etmek gerekir. Dönüştürücü hangi kabulü yaptığını dokümante etmelidir; aksi halde satır sayısı ve bellek kullanımı beklenenden farklı çıkar.

Sürümleme ve geri alınabilirlik

Dönüşüm kuralları değiştiğinde eski CSV’ler yeniden üretildiğinde sütun sırası kayabilir. Bu yüzden üretim boru hatlarında şema sürümü, örnek fixture ve regresyon testi bulundurmak, veri bilimi ekiplerinin standart pratiğidir.

Null, boş dize ve “yok” değerleri

JSON’da null, CSV’de boş hücre veya N/A metni farklı anlamlar taşıyabilir. Analitikte null ile boş dizeyi birleştirmek, ortalama ve benzersiz sayım sonuçlarını çarpıtır. Boru hattında açık bir null politikası (ör. boş hücre = null, tire = bilinmiyor) tanımlayın ve dokümante edin.

Güvenlik: CSV enjeksiyonu

Hücrede =SUM, +0 veya @ ile başlayan formüller, Excel’de açıldığında formül enjeksiyonu tetikleyebilir. Dış kaynaklı CSV içe aktarırken “metin olarak” açma veya ön ek temizleme kuralları uygulanmalıdır.

Birleşik anahtar ve veri bütünlüğü

İki sütunun birleşimi benzersiz satır oluşturuyorsa, JSON’dan CSV’ye dönerken bu anahtarın korunup korunmadığını doğrulayın. Aksi halde “aynı kullanıcıya ait” satırlar içe aktarımda çoğalabilir veya kaybolabilir. Dağıtık sistemlerde idempotency key gibi alanlar ayrıca ele alınmalıdır.

Sütun adı normalizasyonu

API alanları camelCase, veri ambarı snake_case, rapor ise Türkçe başlık isteyebilir. Dönüşüm sırasında adları standartlaştırmak, sonradan yapılacak birleştirmeleri (join) kolaylaştırır; aksi halde aynı anlama gelen iki sütun farklı isimlerle yan yana gelir ve sessiz hata üretir.

Bu sayfa öğrenme ve hızlı doğrulama içindir; muhasebe, sağlık veya kimlik verisinde nihai doğrulama için şema, imza ve denetim izi şarttır.

Bu içerik genel bilgilendirme amaçlıdır; kesin fatura, harç, vergi ve süreler için resmî kurum duyuruları, sözleşmeler ve güncel mevzuat esastır.