Bozuk Türkçe Karakter Düzeltme

Bozulma tam olarak nasıl oluşuyor

UTF-8 değişken genişlikte bir kodlamadır. "ü" harfi tek karakter olmasına rağmen iki bayt yer kaplar: C3 ve BC. Bu iki bayt Latin-1 gibi tek baytlık bir kodlamayla okunduğunda, iki ayrı karakter olarak görünür: Ã ve ¼.

1"Türkiye"  ->  bayt olarak: 54 C3 BC 72 6B 69 79 652Latin-1 okuyunca:   T  à  ¼  r  k  i  y  e   =  "Türkiye"

Metin aslında kaybolmamıştır. Baytlar yerinde durur, yalnızca yanlış harflerle gösterilir. Onarım da bu yüzden mümkündür: her karakterin kod noktasını yeniden bayta çevirip diziyi UTF-8 olarak okumak yeterlidir.

Neden bu araç doğru metne dokunmaz

Bir onarım aracının en tehlikeli hatası, bozuk metni onaramamak değil, doğru metni bozmaktır. İlkinde kullanıcı bir çözüm bulamaz ve devam eder; ikincisinde çalışan bir belgeyi kaybeder ve bunu günler sonra fark eder.

Koruma, katı UTF-8 çözümlemesinden gelir. Doğru yazılmış Türkçe metnin kod noktaları bayt olarak yeniden yorumlandığında geçerli bir UTF-8 dizisi oluşturmaz. Çözümleyici hata verir, araç da o bölümü olduğu gibi bırakır. Yani koruma bir kontrol listesi değil, işlemin doğasından gelir.

Kısmen bozuk belgeler

Gerçek dünyada bir belge nadiren baştan sona bozuktur. Veritabanı dışa aktarımlarında kodlama bir noktada değişir ve doğru satırlar bozuk satırların yanında durur. Bir sayfanın başlığı düzgün, gövdesi bozuk olabilir.

Metnin tamamını tek seferde çözmeye çalışan bir araç bu durumda tamamen başarısız olur: ilk doğru karakterde çözümleme hata verir ve sonuç "bozulma bulunamadı" olur. Bu araç bunun yerine bozuk BÖLÜMLERİ bulur ve her birini ayrı ayrı onarır. Aradaki doğru metin bayt bayt aynı kalır.

1Girdi:  Türkiye ve Türkiye2Çıktı:  Türkiye ve Türkiye3        ^^^^^^^ dokunulmadı

İki kez bozulmuş metin

Bozuk bir metin, bozuk hâliyle bir kez daha kaydedilirse hata katlanır. "Türkiye" bir kez daha aynı yanlışlıktan geçtiğinde "Türkiye" olur ve tek bir onarım geçişi yetmez: ilk geçiş "Türkiye" verir, ki bu hâlâ bozuktur.

Araç sonuç değişmeyene kadar tekrar dener ve kaç geçiş gerektiğini size söyler. İki veya daha fazla geçiş görüyorsanız, verinin bozuk hâlinin bir kere daha kaydedildiğini anlarsınız; bu genellikle onarılması gereken asıl sorunun kaynak sistemde olduğunu gösterir.

Neden "Ýstanbul" ayrı bir seçenek

Türkçede sık görülen ikinci bozulma farklıdır. ISO-8859-9 ile Windows-1254 veya Latin-1 karıştırıldığında "İstanbul" yazısı "Ýstanbul" olarak görünür. Altı harf etkilenir: İ, ı, Ş, ş, Ğ, ğ.

Eşleme belirsiz değildir, ama TESPİT belirsizdir. Ý harfi İzlandaca ve Çekçede gerçek bir harftir, Þ ve Ð de öyle. Her iki kodlamada da her bayt dizisi geçerlidir, dolayısıyla UTF-8 durumundaki gibi güvenilecek bir geçerlilik kontrolü yoktur. Metnin Türkçe olduğunu kanıtlayan hiçbir işaret bulunmaz.

Kaynağı düzeltmek

Bu araç bir belgeyi kurtarır, sistemi onarmaz. Bozulma tekrar ediyorsa sorun zincirin bir yerindeki kodlama varsayımındadır ve genellikle şu üç yerden birindedir: veritabanı bağlantısının karakter kümesi, HTTP yanıtındaki Content-Type başlığı, veya dosya okurken belirtilmeyen kodlama.

MySQL kullanıyorsanız bakılacak ilk yer utf8 ile utf8mb4 farkıdır: MySQL'in "utf8" adı verdiği kodlama gerçek UTF-8 değildir ve dört baytlık karakterleri, yani emojiyi taşıyamaz. Doğru seçim her zaman utf8mb4 olmalıdır.

Veri tarayıcınızdan çıkmaz

Yapıştırdığınız metin hiçbir sunucuya gönderilmez. Onarım tamamen tarayıcınızda çalışır; sayfa yüklendikten sonra bağlantınızı kesseniz bile araç çalışmaya devam eder. Bozuk metin çoğu zaman bir veritabanı dökümünün parçası olduğu için bu önemlidir.