O Tuhaf 'Ã§' Karakterleri Nereden Çıkıyor?

Bir dosyayı açtığınızda ç yerine Ã§ görmek can sıkıcı ama aslında oldukça mantıklı bir sebebi var.

Özet

Bu bozulmaya mojibake deniyor, bir bug değil, iki farklı karakter kodlamasının birbirine karışması.

Adım adım

Bir metin dosyası kaydedildiğinde, her karakter belirli bir kodlama standardına göre bayt dizisine çevrilir. Türkçe karakterler için en yaygın standart UTF-8.
Sorun şu anda başlıyor: dosya UTF-8 ile kaydedilmiş ama başka bir program onu farklı bir kodlamayla (genelde Windows-1254 ya da Latin-1) okumaya çalışıyor. UTF-8'de 'ç' harfi 2 baytla temsil edilirken, yanlış kodlama bu 2 baytı 2 ayrı karaktermiş gibi yorumluyor — işte Ã§ böyle ortaya çıkıyor.
En sık karşılaşılan durumlar: bir CSV dosyasını Excel'de açmak, eski bir e-posta istemcisinden kopyalanan metin, ya da bir web sitesinin kaynak kodunda charset etiketinin eksik olması.
Düzeltmenin en garantili yolu, dosyayı doğru kodlamayla yeniden açmak (mümkünse). Ama elinizde sadece bozulmuş metin varsa, yaygın bozulma kalıpları (Ã§→ç, Ã¼→ü, Ä±→ı gibi) bilinen, sabit eşleşmeler olduğu için bunları geri çevirmek genelde mümkün.
Kalıcı çözüm için: kod yazıyorsanız her yerde (veritabanı bağlantısı, HTML meta etiketi, dosya kaydetme) UTF-8'i açıkça belirtin. 'Bir gün kendiliğinden düzelir' diye bir şey yok, kodlama tutarlılığı elle sağlanması gereken bir şey.

Neden önemli?

Bozuk karakterler ilk bakışta sadece görüntü sorunu gibi durur, ama asıl zarar veri tarafındadır. Müşteri adları bozuk kaydedilmiş bir listeyle arama yaptığınızda 'Çelik' soyadlı kişiyi bulamazsınız. Bozuk metin bir kez veritabanına yazılıp üzerine yeni kayıtlar eklendikçe, temizlemek her geçen gün daha zor hale gelir. Fatura, kargo etiketi veya resmi bir yazıda bozuk bir ad ise doğrudan güven kaybıdır.

Ters yöndeki bozulma: soru işareti ve kutucuklar

Ã§ gibi kalıplar, UTF-8 bir dosyanın eski bir kodlamayla okunmasından çıkar. Tersi de olur: Windows-1254 ile kaydedilmiş bir dosya UTF-8 olarak açıldığında Türkçe harflerin yerinde içinde soru işareti olan elmas biçimli bir sembol ya da boş kutular görürsünüz. Bu durum daha tehlikelidir. Dosya bu haliyle kaydedilirse orijinal harf bilgisi kaybolur ve geri çevirmek mümkün olmaz. Bu sembolü gördüğünüzde dosyayı kaydetmeden kapatıp doğru kodlamayla yeniden açın.

Sık yapılan hatalar

Bozuk metni birden fazla kez 'düzeltmek'. Zaten düzeltilmiş bir metne aynı dönüşümü tekrar uygulamak yeni bir bozulma üretir.
CSV dosyasını Excel'de çift tıklayarak açmak. Bunun yerine Veri sekmesindeki metin veya CSV içeri aktarma seçeneğiyle kodlamayı UTF-8 olarak seçmek daha güvenlidir.
Excel için hazırlanan CSV'yi BOM olmadan kaydetmek. Excel'in UTF-8'i tanıması için dosyanın 'UTF-8 (BOM ile)' seçeneğiyle kaydedilmesi çoğu zaman gerekir.
Kodlama sorununu büyük küçük harf sorunuyla karıştırmak. Türkçedeki i-İ ve ı-I ayrımı, dil ayarı belirtilmeden yapılan dönüşümlerde 'istanbul' kelimesini 'ISTANBUL' yapabilir; bu ayrı bir hatadır.

Örnek bir senaryo

Bir e-ticaret sitesi sipariş listesini CSV olarak dışa aktarıyor, muhasebe ekibi dosyayı Excel'de açıyor ve tüm adreslerde Ã¼ ve ÅŸ gibi ifadeler görüyor. İlk tepki dosyayı elle düzeltmek oluyor. Daha kalıcı çözüm, dışa aktarma ayarında BOM'lu UTF-8 seçmek ya da muhasebe ekibine içeri aktarma sihirbazını göstermek. Elle düzeltilmiş eski dosyalar için yedek alınıp bir karakter düzeltme aracıyla toplu dönüşüm yapılıyor ve sonuç birkaç örnek kayıtla karşılaştırılıyor.

Düzeltmeden önce yedek alın

Hangi dönüşümün doğru olduğundan emin olmadan orijinal dosyanın üzerine yazmayın. Önce bir kopya üzerinde çalışın, birkaç farklı satırı kontrol edin ve ancak sonuçtan eminseniz asıl dosyayı değiştirin.