Bir sistemden CSV indiriyorsunuz. Not Defteri'nde açınca Türkçe harfler yerli yerinde; Excel'de açınca ç ve ı dolu. Aynı dosya, iki farklı sonuç. Dosya bozulmadı, iki program onu farklı alfabeyle okudu.
Düzeltmek için CSV Türkçe onarma aracını kullanabilirsiniz; aşağıdakiler neden olduğunu anlatıyor.
Dosyada harf yok, bayt var
Bir metin dosyası harf saklamaz, sayı saklar. Hangi sayının hangi harf olduğunu söyleyen şey kodlamadır. UTF-8'de "ç" iki bayttır: C3 A7. Windows-1254'te ise tek bayt: E7.
Excel bir CSV açarken bu bilgiyi dosyadan okuyamaz. CSV'nin kodlamayı yazacak bir başlığı yoktur. Tahmin eder ve Türkçe bir Windows'ta tahmini genellikle Windows-1254 olur. UTF-8 yazılmış dosyadaki C3 A7 ikilisini o alfabeyle okuyunca iki ayrı harf çıkar: Ã ve §. Gördüğünüz şey tam olarak budur.
BOM: dosyanın kendini tanıtması
Çözüm dosyanın başına BOM koymak: EF BB BF baytları. Görünmez, içeriği değiştirmez, tek işi "bu dosya UTF-8" demektir. Excel bunu görünce tahmin etmeyi bırakır ve doğru okur.
Bu yüzden "Excel'de bozuk açılıyor" sorununun kalıcı çözümü metni değiştirmek değil, BOM eklemek. Dosyayı Excel'de tek tek düzeltmek ya da "Veri → Metinden" sihirbazından her seferinde 65001 seçmek de işe yarar, ama dosyayı her paylaştığınızda karşı tarafın aynı şeyi bilmesini gerektirir.
İkinci tuzak: ayraç
CSV "virgülle ayrılmış" demek ama Excel dosyayı Windows'un liste ayracıyla okur ve Türkçe sistemlerde bu noktalı virgüldür. Sonuç: virgülle yazılmış dosya Excel'de tek sütuna düşer.
Sebep basit ama sonucu can sıkıcı: ondalık ayracı virgül olan bir ülkede, virgül aynı anda hem sayının içinde hem hücreler arasında olamaz. Bu yüzden Türkçe Excel'in tercihi noktalı virgüldür.
Doğru ayracı sezmek göründüğünden ince bir iş. Tırnak içindeki virgül ayraç değildir ("Ankara, Çankaya" tek hücredir) ve yalnızca sayarak karar veren bir araç, adres sütunu olan her dosyada yanılır. Ölçüt sayı değil tutarlılıktır: doğru ayraç her satırda aynı sayıda geçer.
Üçüncü tuzak: sayılar
1.234,56 Türkçede bir buçuk binden biraz fazla; aynı dizi İngilizce bir sistemde ya hata verir ya da 1.234 olarak okunur. Veriyi başka bir sisteme taşırken ondalık ayracını noktaya çevirmek gerekir.
Ama körlemesine çevirmek tehlikeli: 1.5000 bir ürün kodu olabilir, 12,5 kg bir ölçüdür. Dönüştürme, hücrenin tamamı sayı olduğunda yapılmalı. Aracımız bu kuralı katı uyguluyor ve kaç hücrenin etkileneceğini önceden söylüyor.
Sütun sayısı tutmayan satırlar
Bir satırda diğerlerinden fazla ayraç varsa sebebi genellikle tırnaklanmamış bir metindir: Ali Veli, Ankara, Çankaya iki hücre olacakken üç hücre olur. Aracımız bu satırları sayıyor ve numaralarını veriyor ama düzeltmiyor, hangi iki hücrenin aslında tek hücre olduğunu ancak veriyi bilen kişi söyleyebilir. Tahmin etmek tabloyu sessizce bozardı.
Kaydederken ne yapmalı
- Excel'den dışa aktarıyorsanız "CSV UTF-8 (virgülle ayrılmış)" seçeneğini kullanın, bu seçenek BOM yazar. Düz "CSV" seçeneği Windows-1254 yazar ve dosyayı Excel dışında açan herkes bozuk görür.
- Bir sisteme yükleyecekseniz genellikle virgül + UTF-8 istenir; BOM istenmiyorsa kapatın.
- Karşı tarafın ne beklediğini bilmiyorsanız UTF-8 + BOM + noktalı virgül Türkiye'de en az sürprizi çıkaran birleşim.
Zaten bozulmuş dosyalar
Bazen bozulma çoktan gerçekleşmiş ve o hâliyle kaydedilmiştir, yani dosyanın içinde gerçekten ç yazar. Bu artık bir okuma sorunu değil, veri onarımı işidir ve geri alınabilir: bozuk Türkçe karakterler neden oluşur yazısı mekanizmayı, düzeltme aracı ise onarımı anlatıyor. CSV aracımız bu onarımı dosyanın tamamına kendiliğinden uyguluyor.