Bir CSV dosyasını Excel’de açıyorsunuz ve “çalışma” yazması gereken yerde çalışma görüyorsunuz. Ya da eski bir sistemden gelen listede Ýstanbul ve aðaç yazıyor.
Bu ikisi aynı sorun değil. Farklı sebeplerden doğuyorlar ve onarımları da farklı. Ayrımı bilmek işe yarıyor, çünkü bir metni yanlış yöntemle “düzeltmek” onu geri dönüşsüz biçimde daha da bozabiliyor.
Harfler bilgisayarda nasıl saklanıyor
Bilgisayar harf saklamıyor, sayı saklıyor. Hangi sayının hangi harfe karşılık geldiğini bir tablo söylüyor ve bu tablonun adı karakter kodlaması.
İngiliz alfabesi için sorun yok: tek bir tablo (ASCII) yeterli ve herkes onu kullanıyor. Sorun ş, ğ, ı, İ, ç, ö, ü gibi harflerde başlıyor, bunlar o tabloda yok ve tarihsel olarak birden çok farklı çözüm üretildi:
- UTF-8, bugünün standardı. Türkçe harfler burada iki bayt yer kaplıyor, İngiliz harfleri bir bayt.
- ISO-8859-9 (Latin-5). Türkçe için yapılmış eski tablo. Her harf tek bayt.
- windows-1252. Batı Avrupa için yapılmış eski tablo. Türkçe harflerin çoğu yok, ama tablo tüm bayt değerlerine bir karşılık veriyor.
Bozulma, metnin bir tabloyla yazılıp başka bir tabloyla okunmasından doğuyor. Veri kaybolmuyor, yanlış tabloya bakılıyor.
Birinci tip: çalışma
Metin doğru şekilde, UTF-8 ile kaydedilmiş. Onu okuyan program ise windows-1252 sanıyor.
UTF-8’de “ç” iki bayttan oluşuyor. windows-1252 tek baytlı bir tablo olduğu için bu iki baytı iki ayrı harf sanıyor ve ç yazıyor. Aynı şekilde ı → ı, ş → ÅŸ, ğ → ÄŸ.
Tanınması kolay: metin uzuyor ve her Türkçe harfin yerine iki tuhaf karakter geçiyor. Ã, Ä, Å harfleri yoğun biçimde görünüyorsa tip budur. “çalışma” kelimesi çalışma oluyor: yedi harf ondan fazla karaktere çıkıyor.
İkinci tip: Ýstanbul, aðaç
Bu sefer metin Latin-5 ile yazılmış, okuyan program windows-1252 sanıyor. İki tablo da tek baytlı olduğu için harf sayısı değişmiyor, yalnızca yanlış harfler görünüyor.
Latin-5’te “İ” harfinin oturduğu sayı, windows-1252’de “Ý” harfine denk geliyor. Aynı şekilde ğ → ð, ş → þ, İ → Ý, ı → ý. Yani “İstanbul” Ýstanbul, “ağaç” aðaç oluyor, harf sayısı aynı kalıyor.
Bu tip Türkiye’ye özgü ve yabancı onarım araçlarının çoğunda hiç yok, çünkü Latin-5 Türkçe için yapılmış bir tablo ve İngilizce metinlerde hiç karşılaşılmıyor.
Üçüncü durum: üst üste bozulma
Bir metin birden çok sistemden geçmişse bozulma katmanlanabiliyor: önce bir kez yanlış okunuyor, o hâliyle yeniden kaydediliyor, sonra tekrar yanlış okunuyor. Ortaya ç gibi daha da uzun diziler çıkıyor.
Bunun onarımı katman katman geri almak: bir kez çevir, hasar azaldı mı bak, azaldıysa tekrar dene. Hasar artıyorsa dur.
Onarım neden her zaman güvenli değil
Onarım, bozulmanın tersini uygulamak: metni onu bozan tablonun gördüğü baytlara geri çevirip doğru tabloyla okumak. Kulağa mekanik geliyor ama iki tuzağı var.
Birincisi: yanlış yol da geçerli sonuç üretebiliyor. Bir metni yanlış yolla çevirdiğinizde ortaya hata değil, başka bir geçerli metin çıkıyor, yalnızca anlamsız harflerle dolu. Örneğin Ç harfi ve kesme işareti belirli bir sırada geldiğinde çevirim “ǒ” gibi bir harf üretebiliyor. Program “başardım” diyor, çıktı bozuk.
Bu yüzden çıktının bir makullük denetiminden geçmesi gerekiyor: Türkçe bir metinde bulunmaması gereken harf blokları çıktıysa o yol reddedilmeli.
İkincisi: düzgün metne dokunmamak gerekiyor. Zaten doğru olan bir metni “onarmaya” çalışmak onu bozar. Doğru davranış, bir yolu ancak hasarı gerçekten azaltıyorsa uygulamak ve azaltmıyorsa metni olduğu gibi bırakıp bunu kullanıcıya söylemek.
Nerede karşılaşılıyor
- CSV ve Excel. En sık kaynak. Excel bir CSV’yi açarken kodlamayı kendisi tahmin ediyor ve Türkçede sık yanılıyor. Çözüm: dosyayı çift tıklamak yerine Veri sekmesinden içe aktarıp kodlamayı elle UTF-8 seçmek.
- Eski veritabanları ve yönetim panelleri. Latin-5 döneminden kalma sistemler.
- E-posta ve form çıktıları. Başlıkta bildirilen kodlama ile gövdenin gerçek kodlaması ayrışıyor.
- Altyazı dosyaları. İndirilen SRT’lerin çoğu Latin-5.
- Log ve dışa aktarım dosyaları.
Aynı sorun dosya adlarında ve arşivlerde
Bozulma yalnızca metnin içinde olmuyor; dosya adları da aynı kurala tabi. ZIP arşivi bunun en görünür örneği.
ZIP biçimi, dosya adlarının hangi tabloyla yazıldığını tek bir bit ile bildiriyor. Bu bit konmazsa arşivi açan program adı çok eski bir tablo (CP437) sanıyor ve “ölçü.png” arşivden bozuk çıkıyor. İngilizce adlarda hiç fark edilmiyor, Türkçe adlarda her seferinde görünüyor, bu yüzden bizim ZIP yazıcımızda o bitin konması sınanan bir kural.
Aynı sorun e-posta eklerinde, indirilen dosyalarda ve eski sunuculardan gelen arşivlerde de çıkıyor. Yapabileceğiniz tek şey arşivi başka bir programla açmayı denemek: 7-Zip ve WinRAR bazı durumlarda adı doğru çözebiliyor.
Nasıl önlenir
Tek kural: her yerde UTF-8. Dosyayı kaydederken kodlamayı UTF-8 seçin, dışa aktarırken UTF-8 seçeneği varsa kullanın, bir sistem “Türkçe” ya da “ANSI” kodlama öneriyorsa kabul etmeyin. Bozulma ancak iki taraf farklı tablo kullandığında oluşuyor; ikisi de UTF-8 kullanırsa oluşmuyor.
Elinizdeki bozuk metni onarmak
Türkçe karakter düzeltme aracı üç kodlama yolunu birden deniyor (yukarıdaki iki tip ve Latin-5 varyantı) ve hangisinin uygulandığını söylüyor. Üst üste bozulmayı katman katman geri alıyor, düzgün metne dokunmuyor, çıktı makullük denetiminden geçmezse o yolu reddediyor. Metniniz tarayıcıdan çıkmıyor.
İki komşu iş de aynı yerde: metni büyük/küçük harfe çevirirken i↔İ ve ı↔I ayrımını doğru yapmak, ve elinizdeki metin taranmış bir belgeden geliyorsa OCR ile çıkarmak.