Türkçe Karakter Sorunlarımız
28 Temmuz 2008Türkçe’mize özgü özel karakterlerimiz (ö, ü, ç, ş, ğ, ı, Ö, Ü, Ç, Ş, Ğ, İ), bilgisayarın hayatımıza girdiği ilk günden itibaren sorun oluşturmuştur. Bilgisayar’ın gelişimine ve standartların oluşumuna ilk başta katkı vermemiş olan ülkeler de bizlerle benzer kaderi paylaşmıştır.
Türkçe karakter sorunlarımız saklama, gösterim, sıralama, büyük – küçük harf dönüşümü gibi kategorilere ayrılabilir. UTF serisi kodlama standartları ile beraber saklama ve gösterim sorunları büyük ölçüde çözülmüştür ve sistemler arası uyumlu hale gelmiştir. UTF standardının yardımı ile eskisi kadar çok Türkçe karakter sorunu ile karşılaşmaz olduk.
Ancak ı ve İ harflerimiz ile ilgili öyle bir sorunumuz var ki, ne yazık ki çözülmesi ile ilgili umudumu kaybetmiş durumdayım. İngiliz i harfinin büyük hali I olmaktayken, Türkçe i harfi’nin büyük hali ise İ olmaktadır. Ancak her iki i harfinin de her kodlama standardındaki sayısal değeri aynıdır. Aslında karakteristik olarak benzer karakterler olsalar da bu özellikleri nedeni ile birbirinden oldukça ayrı karakterlerdir.
Kullandığımız alfabenin Latin ailesinden geliyor olması nedeni ile ne yazık ki tüm yabancı isimler orijinal hali ile yazılarak kullanılmaktadır. Örneğin Linux ismi, Linüks değil de Linux olarak yazılmaktadır. Bu metni Türkçe olarak büyütürsek LİNUX, İngilizce olarak büyütürsek LINUX olarak yazılmaktadır. Ancak orijinalini yazma eğilimimiz olduğu için LINUX olanını kullanırız. Bu durum tüm kuralları alt üst etmektedir. Bu, bizim dilimizde bir metnin bir bütün olarak Türkçe olması söz konusu olamayacağı anlamına gelmektedir. Örneğin bu cümle Türkçe olarak yazıldı, ama içindeki Linux özel ismi Türkçe değildir ve büyük hali de LINUX‘tur.
Bu durum nedeni ile özellikle ana dili Türkçe olmayan geliştiriciler tarafından geliştirilmiş olan (tüm yabancı menşeyli yazılımlar bu kategoridedir) yazılımlarda Türkçe karakter sorunu bulunmaktadır.
Örneğin; PostgreSQL’in Türkçe sıralama ve harf küçültüp büyütme yapabilmesi için dil seçimi ile ilgili tüm çevre değişkenlerinin tr_TR olarak kurulu olması ihtiyacı bulunmakta. Ancak aynı PostgreSQL’in sunucu süreçleri İngilizce dili olarak kurulmuş olan çevre değişkenli bir ortamdan başlatılmaktadır. SQL cümleciklerinin özel kelimelerinin tamamı standart tanım gereği İngiliz dili ile ifade edilen kelimeler (INSERT, INTO, INDEX, …) olması ve küçük büyük harf ayrımı yapılmaması gerektiği belirtilmiş durumda. PostgreSQL küçük büyük harf ayrımını yapmamak için hepsini küçük harfe dönüştürerek bir yapıda tutmakta ve kullanıcının girdiği SQL cümleciklerinin SQL özel kelimelerini de küçülterek bunlarla karşılaştırmakta. Ancak kendi içinde tuttuğu yapı insert, into, index iken kullanıcının girdisi ınsert, ınto, ındex’e dönüştürülmekte. Bu nedenle büyük harflerle yazılmış SQL sorguları işletilememekteydi. Yıllar önce bu sorunu fark edip PostgreSQL geliştiricileri ile paylaştım. Yerel ayarlardan etkilenen bir küçültme işevi olan tolower()’ı kullanmamalarını, özellikle İngilizce küçültme yapan ayrı bir işlev kullanmalarını rica ettim. Beni kırmayıp, sorunu güzelce anlayıp 3-4 günde çözüm getirdiler ve bir sonraki sürümde bu yamanın dahil olacağını ilettiler.
Aynı sorun PHP’de de var. Tamamiyle İngilizce harflerden oluşabilen PHP fonksiyon isimleri ne yazık ki aynı hataya düşülerek yerel dil duyarlı bir işlevle küçültülmeye çalışılmaktadır. Sonuç PostgreSQL ile aynı olmaktadır. PHP geliştiricilerine de hata raporu ilettim. Ancak bu durumu 2003 yılından beri biliyoruz deyip gene çözüm sağlamamayı yeğlediler. Ben her defasında hazırlamış olduğum bu yamayı kullanarak yeniden PHP derlemek zorunda kalıyorum.
Aynı sorun ne yazık ki Java’da da var. Ingilizce olması gereken ifadeler Türkçe yerel dil ayarlı ortamda bambaşka bir hal almakta. Özellikle içinde i ya da I harfleri bulunuyorsa. Karşılaştırmalar çalışmamakta, Bean’lerin setter veya getter methodları bulunamamakta.
Önceleri UNIX’in libc kütüphanesini tasarlayanları suçladım. Yerel duyarlı tolower() / toupper() işlevini geliştiren zihniyet, sadece İngilizce olabilecek olan ifadelerin küçük büyük harf ayrımı yapılmaksızın her yerel dil ayarı altında karşılaştırılabilmeleri için tolower_english() ve toupper_english() sürümlerini hazırlamaz mı hiç? Ancak işin ayrıntılarına inince bu da çözüm sağlamıyor. Lütfen okumaya devam ediniz.
Bu savaşı devam ettirdik ve Türkçe bilmeyen geliştiricileri yola getirdik diyelim. Bu sefer de hem Türkçe hem İngilizce olabilecek olan veri türleri ile ilgili sorunlarımız var. Örneğin bir kullanıcı doğrulama sürecinde ad ve soyad bilgilerini kullandığımızı düşünelim. Küçük ve büyük harf ayrımı da yapmadığımızı düşünelim.
ismail -> İSMAİL (Türkçe bir isim olan İsmail’in doğal dilinde büyütülmesi)
michael -> MICHAEL (Yabancı bir isim olan Michael’in doğal dilinde büyütülmesi)
Uygulamanızı kullanan hem Türk hem de yabancı kullanıcılar olduğunu düşünün. Türk olan kullanıcı ismail, İsmail, İSMAİL gibi verileri girecektir. Ancak yabancı olan kullanıcı Michael, MICHAEL olarak girecektir. Buna göre siz hangi dilde küçültme veya büyütme yaparak karşılaştırmaya sokacaksınız? Ülkemizin köklü bankalarından İş Bankası bu sorunu i ve ı’yı aynı harf kategorisine koyarak çözmüş. “sezai, SEZAİ, sezaı, SEZAI” bu girdilerin hepsi de Türkçe olan Sezai ismini doğrulamaktadır. Benzer şekilde “michael, MİCHAEL, MICHAEL, mıchael” girdilerinin hepsi de yabancı olan Michael ismini doğrulamaktadır. Bu yaklaşım sistemi çalışır duruma getiriyor, günü kurtarıyor olsa da kesinlike doğru çözüm değildir. Yanlış ifadeler doğru gibi kabul edilmektedir.
Ben bu ı ve İ sorunundan bıkmış durumdayım. Ama ne yazık ki çözüm yolu yok. Türkçe i harfini kodlama standardında İngiliz i harfinden ayrı tutsak bu sefer şekil olarak aynı oldukları için karışacaklar. Sırf bu sorunu çözmek için alfabemizi de değiştiremeyeceğimize göre bu sorunla yaşamaya devam edeceğiz. Yanlış da olsa İş Bankası’nın uyguladığı yöntem, sistemi çalışır tutan tek yöntem gibi göründüğü için ben olsam hiç beğenmesem de aynı yöntemi uygulardım.
Etiketler: java, karakter, libc, Linux, php, postgresql, sorunlar, sql, tr_TR, turkce, unix, utf