Excel'e aktarılan bir rapor çoğu zaman başka bir hesabın girdisidir. Ekranda “1.234,50 TL” olarak güzel duran metni hücreye aynı şekilde yazarsam kullanıcı toplam almaya çalıştığında sorun çıkabilir. Raporu tasarlarken sayıyı, görünen biçimi ve dosyanın gerçek formatını ayrı kararlar olarak ele alırım.
Önce tipli rapor verisi
Arşivdeki WebForms ve veri erişim yapılarından çıkardığım küçük örnekte Id int, Amount decimal. Bu tipler DataTable içinde de korunur. Çıktı katmanı devreye girene kadar tutara para simgesi, binlik ayırıcı veya yerel ondalık işareti eklemiyorum. .NET 10 konsolunda çalışan kod önce bu veri ve sunum ayrımını gösteriyor.
using System.Data;
using System.Globalization;
var table = new DataTable();
table.Columns.Add("Id", typeof(int)); table.Columns.Add("Amount", typeof(decimal));
table.Rows.Add(1, 12.50m);
Console.WriteLine("Id;Amount");
foreach (DataRow row in table.Rows)
Console.WriteLine($"{row.Field<int>("Id")};{row.Field<decimal>("Amount").ToString("0.00", CultureInfo.InvariantCulture)}");Beklenen iki satır Id;Amount ve 1;12.50. Buradaki InvariantCulture, makineye göre değişmeyen bir metin çıktısı seçiyor. Bu çıktı CSV benzeri ayrılmış metindir; dosya adına .xlsx uzantısı eklemek onu Excel çalışma kitabı yapmaz. Gerçek XLSX dosyası, çalışma sayfaları ve ilişkileri olan bir paket biçimidir.
Gerçek XLSX'te sayısal hücre nasıl düşünülür?
Sayısal hücreye 12.50 değeri, hücre biçimine ise iki ondalık veya para gösterimi yazılır. Kullanıcı formatı değiştirdiğinde alttaki sayı aynı kalır. Open XML düzeyinde bir hücrenin küçük örneği aşağıdaki gibi görünür. Bu XML parçası tek başına açılabilir bir çalışma kitabı değildir; workbook, worksheet ve ilişki parçalarının içinde bulunur.
<c r="B2" t="n">
<v>12.50</v>
</c>Bir XLSX kütüphanesi kullanırken de aynı ayrım geçerlidir: “değer ata” ile “number format ata” işlemleri ayrı olmalı. Üreticinin bütün nesneleri string'e çeviren bir kısa yolunu kullanmak, dışa aktarımı çalışıyor gösterirken sayı ve tarih semantiğini kaybettirebilir. Başlıklar, kolon sırası ve null gösterimi de rapor sözleşmesinin parçalarıdır.
CSV'yi genel amaçlı yazmak bu örnekten fazlasını ister
İki sayısal alan için Console.WriteLine yeterli bir gösterim. Serbest metin eklendiğinde ayraç, çift tırnak ve satır sonu kaçışları gerekir. “Ankara; merkez” değeri tırnaklanmadan yazılırsa yeni kolon gibi okunur. Tırnaklanmış metnin içindeki tırnaklar da seçilen CSV kurallarına göre kaçırılmalıdır. Okuyucuyla anlaşılmış encoding ve ayraç seçimi, dosyanın hedef ortamda doğru açılması için önemlidir.
Elektronik tabloya açılacak kullanıcı metni formül başlangıcı olarak yorumlanabilir. Gerçek XLSX'te alanı açıkça metin hücresi olarak yazmak, CSV'de ise hedef okuyucuya uygun bir koruma politikası seçmek gerekir. Sadece tırnak koymanın her tablolu okuyucuda formül değerlendirmesini kapattığını varsaymam; üretilen dosyayı hedef uygulamada test ederim.
Dışa aktarım ekranı aşan veriye dönüşmesin
Raporun sorgusu kullanıcının yetkili olduğu veriyle sınırlandırılmalı. Ekranda yalnız ilk sayfa görünürken “tümünü aktar” seçeneği varsa toplam kapsam açık olmalı; yalnız bellekteki görünür satırları dışa aktarmak farklı bir davranıştır. Kullanıcıya ikisini aynı düğme metniyle sunmam.
Büyük veri için bütün kayıtları DataTable ve sonra ikinci bir workbook nesnesinde tutmak bellek kullanımını artırır. Akış tabanlı yazıcı, geçici dosya veya arka plan üretimi seçimi kayıt sayısına ve hedef kütüphaneye bağlıdır. Çıktıyı yalnız dosya üretim süresiyle değil, veriyi okuma ve indirme maliyetiyle birlikte ölçerim.
Raporu açıp hesap yaptırmak
Kontrol listeme sıfır, negatif tutar, null, Türkçe karakter, ayraç içeren metin ve formül benzeri metin eklerim. Gerçek XLSX üretiliyorsa sayısal hücreler üzerinde SUM işlemi yapılabilmeli. CSV testinde doğru parser ile geri okuyup alanları karşılaştırırım. Dosyanın uzantısı ve açılıyor olması ilk kontroldür; rapor verisinin hesaplanabilir kalması asıl beklentidir.