Karakter Seti (Charset) Kontrol Aracı
Karakter kodlaması, sayfadaki baytların hangi harflere karşılık geldiğini belirler. Yanlış ya da eksik bildirildiğinde Türkçe metin bozulur: "güzel" yerine "güzel", "şirket" yerine "ÅŸirket" görünür. Bu araç kodlamanızı üç düzeyde denetler — bildirim var mı, doğru yerde ve doğru biçimde mi, ve en önemlisi sayfanın metninde gerçekten bozuk karakter kalmış mı.
Bildirimi kontrol etmek yetmez, sonuca bakmak gerekir
Charset denetleyicilerinin çoğu sayfada bir charset etiketi bulup "tamam" der. Oysa bozuk karakterlerin büyük kısmı beyanın yanlışlığından değil, içeriğin zaten bozuk kaydedilmiş olmasından kaynaklanır. Metin bir zamanlar yanlış kodlamayla veritabanına yazılmışsa, sayfanız UTF-8 bildirse de o metin bozuk görünmeye devam eder. Bu araç bu yüzden beyanın yanında sayfa metnini de tarar ve bozuk kodlamanın imza dizilerini (ü, ÅŸ, Ä°, ’ gibi) sayar. Beyan doğru ama metin bozuksa sorun içerikte, veritabanı bağlantısının kodlamasında ya da bir dışa/içe aktarma adımındadır.
1024 bayt kuralı
HTML spesifikasyonu, karakter kodlaması bildiriminin belgenin ilk 1024 baytı içinde TAMAMLANMASINI ister. Sebebi basittir: tarayıcı belgeyi baştan okumaya başlar ve kodlamayı bilmeden ayrıştıramaz. Bildirim geç gelirse tarayıcı bir tahminle başlar; tahmin tutmazsa ayrıştırmayı iptal edip baştan yapmak zorunda kalır. Bu hem gereksiz iş hem de karakter bozulması riski demektir. Dikkat edilmesi gereken nokta, sınırın karakter değil BAYT cinsinden olmasıdır: <head> içinde uzun yorum satırları, satır içi stil blokları ya da çok sayıda meta etiketi bu bütçeyi hızla tüketir. Doğru yer, <head> açılışının hemen ardıdır.
Öncelik sırası: BOM, HTTP başlığı, sonra meta
Kodlama üç ayrı yerde bildirilebilir ve çakışma hâlinde uygulanacak sıra bellidir. En üstte, dosyanın başındaki bayt sırası işareti (BOM) gelir. Onun altında sunucunun gönderdiği HTTP Content-Type başlığı bulunur. En altta ise sayfadaki meta etiketi yer alır. Bu sıra, çok sık yaşanan bir kafa karışıklığının kaynağıdır: geliştirici sayfada UTF-8 etiketi görür ama sunucu başka bir kodlama bildiriyorsa tarayıcı sunucuyu dinler ve etiket hiçbir işe yaramaz. Bu araç iki bildirimi karşılaştırır ve çeliştiklerinde hangisinin uygulandığını söyler.
Neden UTF-8?
Türkçe içerik ISO-8859-9 ya da windows-1254 gibi kodlamalarla da taşınabilir; bu kodlamalar Türkçe harfleri kapsar. Ancak kapsamları oradan öteye gitmez: emoji, matematiksel işaretler, farklı alfabelerden alıntılar ve pek çok tipografik karakter temsil edilemez. UTF-8 tüm bunları tek bir kodlamada taşır ve bugün web'in ortak paydasıdır. Eski bir kodlamadan UTF-8'e geçerken dikkat edilmesi gereken nokta şudur: yalnız etiketi değiştirmek metni düzeltmez, bozar. İçeriğin kendisinin de yeniden kodlanması gerekir.
Bozuk karakter (mojibake) nasıl oluşur?
Baytlar bozulmaz; bozulan, o baytları okuma kuralıdır. En yaygın örüntü, UTF-8 olarak yazılmış metnin Latin-1 olarak okunmasıdır. UTF-8'de "ü" harfi iki bayttan oluşur; bu iki bayt tek tek Latin-1 harfleri gibi okunduğunda ekranda "ü" belirir. Aynı şekilde "ş" için "ÅŸ", "İ" için "Ä°", kesme işareti için "’" görünür. Bu izler, sorunun nerede olduğunu da söyler: yalnız veritabanından gelen metinlerde çıkıyorsa bağlantı kodlaması, yalnız belirli sayfalarda çıkıyorsa o sayfanın kaydedildiği dosya kodlaması, her yerde çıkıyorsa sunucu bildirimi şüphelidir.
Sorularla
Sıkça Sorulan Sorular
Charset etiketi nereye konmalı?
<head> açılışının hemen ardına, mümkünse ilk satıra. Bildirimin belgenin ilk 1024 baytı içinde tamamlanması gerekir; <head> içindeki uzun yorumlar veya satır içi stiller bu bütçeyi tüketip etiketi sınırın dışına itebilir.
HTTP başlığında charset varsa meta etiketine gerek var mı?
Teknik olarak yok — tarayıcı başlığı dinler. Yine de eklemek önerilir: sayfa dosya olarak kaydedilip açıldığında ya da başlık bir ara katmanda kaybolduğunda bildirim ortadan kalkar. Tek satırlık bir güvencedir. Eklerken ikisinin AYNI değeri bildirmesine dikkat edin.
Sayfamda UTF-8 yazıyor ama Türkçe karakterler yine bozuk, neden?
Beyan doğru ama içerik zaten bozuk kaydedilmiş olabilir. Metin bir zamanlar yanlış kodlamayla veritabanına yazıldıysa, sayfanın UTF-8 bildirmesi onu düzeltmez. İkinci olasılık, HTTP başlığının farklı bir kodlama bildirmesi ve meta etiketinizi ezmesidir. Bu araç iki durumu da ayırt eder: metinde bozuk dizi sayarsa sorun içerikte, çelişki raporlarsa sorun bildirimdedir.
ISO-8859-9 kullanıyorum, UTF-8'e geçmeli miyim?
Evet, ama dikkatli bir geçişle. Yalnız etiketi değiştirmek mevcut metni bozar; içeriğin de yeniden kodlanması gerekir. Veritabanı, tablo/kolon karakter setleri, bağlantı kodlaması, şablon dosyalarının kendi kodlaması ve sunucu başlığı birlikte ele alınmalıdır. Geçiş sonrası bu araçla metinde bozuk dizi kalmadığını doğrulayabilirsiniz.
BOM zararlı mı?
Tarayıcı açısından değil — aksine kodlamayı kesin belirler ve öncelik sırasının en üstündedir. Sorun sunucu tarafında çıkabilir: bazı dillerde BOM, çıktının başına görünmez karakter olarak sızar ve "headers already sent" gibi hatalara ya da sayfanın başında beklenmedik boşluğa yol açar. Dosyalarınızı BOM'suz UTF-8 olarak kaydetmek yaygın tercihtir.
Bu araç sitemin tamamını mı kontrol ediyor?
Hayır, girdiğiniz tek sayfayı denetler. Kodlama sorunları genellikle site geneli olsa da, veritabanından gelen belirli içeriklerde yerel de olabilir. Tüm sayfaları taramak için Derin Tarama aracını kullanabilirsiniz.