Çeviri Hizmetleri
Türkçe karakter sorunları, MySQL, vs.
Türkçe karakter sorunu, bozuk karakterler, hosting şirketlerine ait hataların düzeltilmesi, joomla, mambo, sql, vs.
Şirketimiz, bu yazıda anlatılan bilgilerin kullanımından doğabilecek zararlardan sorumlu değildir.
Günümüzde birçok hosting şirketi en güncel MySQL sürümleriyle hizmet vermektedir. Müşteriler ise, MySQL sürümlerinin getirdiği farklılıklarla bağlantılı olarak, özellikle Türkçe diline özgü harflerin görüntülenmesi konusunda sorunlar yaşamaktadır.
Bu bölümde, Joomla, Mambo, vb. içerik yönetim sistemlerini işleten kullanıcıların karşılaştığı karakter sorunlarına değinilmiştir.
Burada, MySQL sürümlerini ikiye ayıracağız:
1. Eski sürümler: 4.1'e kadar olan tüm sürümleri kapsamaktadır.
2. Yeni sürümler: 4.1 ve üstü olan tüm sürümler.
Bunların arasındaki fark ise şöyledir:
1. Eski sürümler: Web sayfaları, sunucunun ayarlandığı dil kodlamasında görüntülenir. Sunucu eğer Türkçe diline uyumlu bir şekilde ayarlanmışsa herhangi bir sorun çıkmayacaktır; ki çoğunlukla da böyledir.
2. Yeni sürümler: Dahili tanımlıyıcı ayarlar daima "utf8" olarak ayarlanmıştır. Diğer bir deyişle, veriler hangi dil kodlamasında işlenirse işlensin, veya hangi dil kodlamasında görüntülenirse görüntülensin, dahili sistemde her zaman "utf8" olarak görüntülenirler. Bunun dışında, yeni MySQL sürümleriyle çalışan sunucular, kullanıcıların isteklerine göre ayarlanabilen parametrelere de sahiptir. Kullanıcı, bu parametreler yardımıyla, ara süreçlerde dil kodlamasını değiştirme imkanına sahiptir. Bu parametreler GLOBAL ve SESSION olmak üzere ikiye ayrılır.
GLOBAL (varsayılan ayarlar): Global ayarlar sunucunu ayarları ile ilgilidir ve varsayılan olarak belirlenmişlerdir. SQL sorgusunda aksi durum belirtilmedikçe, varsayılan parametreler, yani GLOBAL parametreler uygulanır. Bu parametreler konfigürasyon dosyaları (my.cnf , my.ini, vs.) yardımıyla ayarlanabilir, sunucu çalıştırıldığında komut istemi parametreleri olarak iletilir ve sunucu ayarlarının değiştirilmesi için girilen komutlara bağlı olarak anında değiştirilebilir. Ancak, bunları yapabilmek için, ROOT gibi üst düzey kullanım hakkına sahip olmak gerekmektedir (ki sunucuyu kendiniz işletmiyorsanız böyle bir hakka sahip değilsiniz denilebilir).
SESSION (geçici ayarlar): Aktif veritabanı bağlantısı ayarlarıyla ilgilidir. Veritabanı ile olan bağlantı kesildiğinde oturum kapatılar ve daha önce belirlenen geçici ayarlar sıfırlanır. Bu çalışma şekli hosting şirketi için daha güvenlidir, çünkü geçici ayarlar hiçbir yerde saklanmamakta ve sunucunun çalışmasını etkilememektedir. Kullanıcı, bu ayarlarla ilgili değişkenleri belirlemek için ilgili komutları girme ve sonuçları görüntüleme hakkına sahiptir.
Daha önce de söylediğimiz gibi, tüm bu parametreler (ki burada sadece dil kodlaması ile ilgili olanları inceleyeceğiz), varsayılan (global) ve geçici (session) olmak üzere 2 şekilde mevcuttur ve aşağıdaki komutlarla değiştirilir:
SET GLOBAL variable_name = new_value
SET SESSION variable_name = new_value
Mevcut ayarları görüntülemek için ise aşağıdaki komutlar uygulanır:
select @@global.variable_name
select @@session.variable_name
Örnek verecek olursak:
set session collation_server = latin5_turkish_ci;
select @@session.collation_server;
Sunucunun tüm parametrelerini görüntülemek için ise aşağıdaki komut kullanılabilir:
SHOW VARIABLES
Şimdi dil kodlaması ile ilgili olan parametrelere birlikte bir göz atalım:
| Parametrenin ismi | Tanımı |
| character_set | Varsayılan kodlamayı belirler. 4.1.1 numaralı MySQL sürümünden itibaren kullanılmamaktadır. |
| character_set_client | İstemciye (kullanıcıya) ait komutların gönderileceği dil kodlamasını belirler. |
| character_set_connection | İstemci (kullanıcı) tarafından character_set_client değişkeni yardımıyla gönderilen komutların dönüştürüleceği dil kodlamasını belirler. |
| character_set_database | Veritabanının varsayılan olarak kullanacağı dil kodlamasını belirler. Bu değişken, veritabanının değiştiği her sefer, sunucu tarafından otomatik olarak tekrar belirlenir. Veritabanının olmaması halinde, bu değişken, character_set_server değişkeni ile aynı değeri alır. |
| character_set_server | Tüm sunucunun varsayılan olarak kullandığı dil kodlamasını belirtir. |
| character_set_results | İstemci (kullanıcı) tarafından girilen komuttan sonra görüntülenen sonuçların hangi dil kodlamasında görüntüleneceğini belirler. |
| character_set_system | Tanımlayıcı değerlerin muhafaza edileceği dil kodlamasını belirtir. Her zaman UTF8 ayarına sahiptir. |
| collation_connection | Bağlantıyla ilgili karşılaştırmanın hangi dilde yapılacağını belirler. |
| collation_database | Veritabanındaki kayıtların hangi dilde karşılaştırılacağını belirler. Bu değişken, veritabanının değiştiği her sefer, sunucu tarafından otomatik olarak tekrar belirlenir. Veritabanının olmaması halinde, bu değişken, collation_server değişkeni ile aynı değeri alır. |
| collation_server | Karşılaştırma işlemleri için varsayılan olarak kullanılacak olan dil kodlamasını belirler. |
Şimdi ise, hosting şirketleri tarafından belirlenen yanlış MySQL ayarlarının ne olabileceğine bir göz atalım. Sorun şu ki, MySQL sunucuları varsayılan olarak latin1 kodlamasında kurulur. latin1 dil kodlaması iso-8859-1 dil kodlamasına tekabül ediyor. Türkçe'ye özgü bazı harfler "8859-1" tarafından desteklenirken "ç" ve “İ” gibi bazı harfler ise desteklenmiyor. Diğer bir deyişle, latin1 dil kodlaması ile çalışacak olmanız halinde "ç" ve "İ" gibi harfler yerine soru işaretleri (???) görürsünüz.
Farzedelim ki varsayılan dil kodlaması latin1 olarak ayarlanmış bir MySQL sunucusuna sahipsiniz.
SQL komut penceresi yardımıyla aşağıdaki komutları girdiğimizde:
# Yeni bir veritabanı oluşturuyoruz
CREATE DATABASE 'VERITABANI';
# Bir metin alanına sahip bir tablo oluşturuyoruz
CREATE TABLE 'TABLO' ( 'METIN' TEXT )
ENGINE = MYISAM ;
Latin1 olarak belirlenmiş bir veritabanına;
Latin1 olarak belirlenmiş "TABLO" isimli bir tabloya; ve
Latin1 olarak belirlenmiş "METIN" isimli bir metin alanına sahip oluruz.
Latin1 olarak ayarlanmış bir sunucuda Türkçe ile sorunsuz çalışan bir veritabanının oluşturulması için aşağıdaki adımların izlenmesi gerekmektedir:
# Yeni bir veritabanı oluşturuyoruz
CREATE DATABASE 'VERITABANI' COLLATE latin5_turkish_ci;
# Bir metin alanına sahip bir tablo oluşturuyoruz
CREATE TABLE 'TABLO'
( 'METIN' TEXT CHARACTER SET latin5 COLLATE latin5_turkish_ci )
ENGINE = MYISAM COLLATE latin5_turkish_ci;
Bu durumda, latin5 olarak ayarlanmış bir veritabanına, tabloya ve metin alanına sahip oluruz.
ANCAK;
1. Bir hosting şirketi değilseniz veya sunucuyu kendiniz işletmiyorsanız, veritabanını kendi SQL komutuyla oluşturma hakkına sahip olmazsınız. Genelde veritabanı, hosting şirketinin kontrol paneli yardımıyla oluşturulur ve varsayılan ayarları belirlemenize imkan vermez.
2. Joomla, mambo, vb. içerik yönetim sistemleriyle ilgili ek bileşenlerin kurulumunda çalıştırılan SQL komutları, dil kodlaması ile ilgili ayarları içermez. Dolayısıyla söz konusu ek bileşenler doğru olarak çalışmaz.
ÇÖZÜM:
1. SQL komutlarının tekrar kodlanması (ki tam bir baş ağrısıdır ve herkesin yapamayacağı bir şeydir);
2. Veritabanına girilen tüm kayıtların latin5 dil kodlamasına dönüştürülmesi.
Tercihimizi 2'nci seçenekten yana kullanmakla SQL komutlarının tekrar kodlanması işinden kurtulmakla birlikte, gerekli ek bileşenlerin dil kodlaması ile ilgili sorunlarına da çözüm getirmiş oluruz.
Bunun için, öncelikle, Türkçe karakterlerin hatalı olarak görüntülenmesine neden olan tüm alanların, tabloların ve veritabanlarının listesinin çıkartılması gerekmektedir. Diğer bir deyişle, latin5_turkish_ci olarak belirlenmemiş olan tüm dil ayarlarını değiştirmemiz gerekecektir. Listeyi çıkarttıktan sonra aşağıdaki SQL komutlarını kullanabiliriz:
| Veritabanının kodlamasını değiştirmek için | ALTER DATABASE 'veritabani_ismi' COLLATE latin5_turkish_ci |
| Tablonun kodlamasını değiştirmek için | ALTER TABLE 'tablo_ismi' COLLATE latin5_turkish_ci |
| Belirli bir alanın kodlamasını değiştirmek için | ALTER TABLE 'tablo_ismi' CHANGE 'alan_ismi' 'yeni_alan_ismi' VARCHAR( 100 ) CHARACTER SET latin5 COLLATE latin5_turkish_ci |
Alanlarla ilgili olarak belirlenmiş dil kodlamasının değiştirilmesinden sonra, yeni çıkan MySQL sürümlerinden önce kodlanmış olan bileşenler dahi normal bir şekilde çalışmaya başlayacaktır. Ancak, veritabanında soru işaretleri olarak görüntülenen verilerin kurtarılması mümkün değildir; ve bu verilerin, dil kodlaması değiştirildikten sonra tekrar girilmesi gerekecektir.