WordPress'te Türkçe Karakterler Bozuk Görünüyor: Kalıcı Çözüm

Siteyi yeni sunucuya taşıdınız, yedeği geri yüklediniz ya da bir XML dosyasını içe aktardınız. Sayfa açılıyor, tasarım yerinde, ama metinlerin hâli içler acısı: "Çalışma saatlerimiz" yazıyor, başlıklarda "Güvenlik" görünüyor, menüde "Ä°letiÅŸim" var. WordPress Türkçe karakter sorunu diye aranan bu arıza, Türkiye'deki site sahiplerinin en sık karşılaştığı taşıma kazasıdır ve panik yaratmasının sebebi, tüm sitenin bir anda okunamaz hâle gelmesidir.

İyi haber şu: bu bir veri kaybı değildir. Harfleriniz veritabanında duruyor; sadece yanlış karakter setiyle yorumlanıyor. Kötü haber, forumlarda en sık verilen "yedeği tekrar alın" cevabının çoğu zaman işe yaramamasıdır — çünkü yedeği aynı yanlış ayarla tekrar alırsanız aynı sonucu alırsınız. Bu yazıda bozulmanın hangi katmanda gerçekleştiğini teşhis etmeyi, mysqldump ve wp-config.php tarafındaki doğru ayarları, hâlihazırda bozulmuş metni SQL ile geri döndürmeyi ve latin1 bir tabloyu veri kaybetmeden utf8mb4'e çevirmeyi baştan sona anlatacağım.

Bozuk Karakterler Neye Benziyor ve Ne Anlama Gelir#

Ekranda gördüğünüz bozukluğun şekli, hangi hatanın yapıldığını doğrudan söyler. Üç ayrı belirti vardır ve üçü farklı sorunlardır:

En sık karşılaşılan birincisidir ve iyi haber odur ki tamamen geri alınabilir. Türkçe harflerin UTF-8 karşılıkları latin1 gözüyle okunduğunda şu tabloya dönüşür:

Bu tabloyu ezberlemenize gerek yok ama bir şeye yarar: metinde "Ã", "Å", "Ä" harflerini görüyorsanız verinin sağlam olduğunu, sadece yanlış yorumlandığını bilirsiniz. Soru işaretleri görüyorsanız veri gerçekten kaybolmuştur ve tek çözüm önceki bir yedektir.

Sorun Hangi Katmanda: Üç Ayrı Karakter Seti Vardır#

Türkçe'de bu konu neredeyse hep tek bir ayara indirgeniyor, oysa bir metnin doğru görünmesi için üç katmanın aynı sette anlaşması gerekir:

1. Tablo/sütun karakter seti — verinin diskte hangi sette saklandığı (utf8mb4, utf8mb3, latin1).
2. Bağlantı karakter seti — PHP ile MySQL arasındaki oturumun hangi seti konuştuğu (SET NAMES). WordPress bunu wp-config.php içindeki DB_CHARSET değerinden kurar.
3. Çıktı karakter seti — tarayıcıya gönderilen HTML başlığı (<meta charset="UTF-8"> ve Content-Type başlığı).

Bozulma, bu üçünün birbirine uymadığı yerde doğar. Klasik senaryo şudur: veriler diskte doğru UTF-8 olarak duruyor, ama bağlantı latin1 kuruluyor. MySQL "sen latin1 istedin" diyerek UTF-8 baytları latin1 sanıp bir kez daha UTF-8'e çeviriyor. Sonuç: çift kodlanmış metin, yani yukarıdaki mojibake tablosu.

En kritik nokta şu: taşıma sırasında bozulma, çoğunlukla yedek alma anında olur, geri yükleme anında değil. Yedeği yanlış bağlantı setiyle aldıysanız, .sql dosyasının içine zaten bozulmuş metin yazılmıştır ve nereye geri yüklerseniz yükleyin bozuk gelir. Bu yüzden "yeni hostingde bir sorun var" teşhisi çoğu zaman yanlıştır.

Teşhis: Hangi Karakter Setiyle Karşı Karşıyasınız#

Tahmin etmeyin, sorun. phpMyAdmin'in SQL sekmesinden ya da SSH üzerinden mysql istemcisinden şu dört sorguyu sırayla çalıştırın.

Veritabanının varsayılan seti:

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = DATABASE();

Tabloların setleri (karışık bir liste görürseniz sorun buradadır):

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY TABLE_COLLATION;

Metin sütunlarının setleri — asıl belirleyici olan budur, çünkü bir sütun, tablonun varsayılanından farklı olabilir:

SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND CHARACTER_SET_NAME IS NOT NULL
  AND CHARACTER_SET_NAME <> 'utf8mb4';

Oturumun/bağlantının seti:

SHOW VARIABLES LIKE 'character_set%';

Son olarak, gerçekten çift kodlanmış satır var mı diye bakın:

SELECT ID, post_title
FROM wp_posts
WHERE post_title REGEXP 'Ã|Å|Ä|Â'
LIMIT 20;

Bu sorgu satır döndürüyorsa mojibake onarımı yapmanız gerekiyor demektir. Boş dönüyor ama sayfada bozuk görünüyorsa, veri sağlamdır ve sorun bağlantı ya da çıktı katmanındadır — yani wp-config.php veya tema tarafında.

Yedeği Doğru Almak: mysqldump ve --default-character-set#

Türkçe kaynaklarda neredeyse hiç geçmeyen ama tüm meselenin döndüğü nokta budur. mysqldump, bağlantıyı hangi karakter setiyle kurarsa dosyayı o sette yazar ve dosyanın başına o seti bildiren bir satır koyar.

Doğru komut:

mysqldump --default-character-set=utf8mb4 \
          --single-transaction \
          --routines \
          -u kullanici -p veritabani_adi > yedek.sql

WP-CLI kullanıyorsanız aynı parametre doğrudan geçirilir:

wp db export yedek.sql --default-character-set=utf8mb4

Yedeği aldıktan sonra dosyayı açmadan doğrulayın. Üç kontrol yeterlidir:

# Dosyanın kendi bildirdiği set
head -30 yedek.sql | grep -i 'SET NAMES'

# Dosyanın gerçek kodlaması
file -i yedek.sql

# Bozuk imza taraması: sonuç 0 olmalı
grep -c 'ş\|ü\|ğ' yedek.sql

file -i çıktısında charset=utf-8 görmelisiniz. charset=iso-8859-1 görüyorsanız dosya latin1 olarak yazılmıştır.

Şimdi kritik ayrım: dosyanın içeriği UTF-8 ama başlığı SET NAMES latin1 diyorsa, geri yükleme sırasında MySQL veriyi bir kez daha çevirir ve bozulma tam burada doğar. Bu durumun düzeltmesi tek satırdır:

sed -i 's/SET NAMES latin1/SET NAMES utf8mb4/g' yedek.sql

Bu, bozuk taşımaların önemli bir kısmını tek başına çözer ve neredeyse hiçbir Türkçe kaynakta yazmaz. Geri yüklerken de seti açıkça belirtin:

mysql --default-character-set=utf8mb4 -u kullanici -p veritabani_adi < yedek.sql

phpMyAdmin üzerinden çalışıyorsanız, Dışa Aktar → Özel ekranındaki "Karakter kümesi" açılır listesinin utf-8 olduğundan emin olun; varsayılanı değiştirilmiş paneller bu hatanın kaynağıdır. phpMyAdmin ile içe/dışa aktarmanın ayrıntıları için phpMyAdmin içe dışa aktarma yazısına bakın.

wp-config.php'deki DB_CHARSET ve DB_COLLATE Ayarları#

WordPress, MySQL bağlantısını wp-config.php içindeki iki sabite göre kurar:

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Üç kural:

1. DB_CHARSET değeri, tablolarınızın gerçek setiyle uyumlu olmalıdır. Tablolar latin1 iken buraya utf8mb4 yazmak, veriyi düzeltmez; sadece bozulmanın yerini değiştirir.
2. DB_COLLATE boş bırakılmalıdır. Boş olduğunda MySQL, karakter setinin varsayılan karşılaştırmasını kullanır. Buraya elle bir değer yazmak, özellikle taşıma sonrası, tablolarla çakışma üretir.
3. utf8 yazmayın, utf8mb4 yazın. MySQL'de utf8 aslında utf8mb3tür ve karakter başına en fazla 3 bayt taşır; Türkçe harfler sığar ama emoji ve bazı özel işaretler sığmaz, o karakterler sessizce kaybolur.

Değişiklikten sonra siteyi bir kez açıp yeni bir taslak yazı kaydedin ve içine Türkçe karakter yazın. Yeni kayıt düzgün görünüp eski yazılar bozuk kalıyorsa, tanı kesindir: bağlantı artık doğru, ama eskiden yazılmış veri diskte bozuk hâlde duruyor. Sıradaki bölüm tam olarak bunun içindir.

Bozulmuş Metni SQL ile Geri Döndürmek#

Çift kodlanmış metin geri alınabilir, çünkü bozulma matematiksel olarak tersine çevrilebilir bir işlemdir. Yapılacak şey, metni önce ikili (binary) forma indirip sonra doğru setle yeniden okumaktır.

Bu işlemi yapmadan önce mutlaka veritabanı yedeği alın ve mümkünse önce bir test kopyasında deneyin. İşlem geri alınamaz.

Tek bir satırda önce sonucu görün, hiçbir şeyi değiştirmeden:

SELECT post_title AS mevcut,
       CONVERT( CAST( CONVERT( post_title USING latin1 ) AS BINARY ) USING utf8mb4 ) AS onarilmis
FROM wp_posts
WHERE post_title REGEXP 'Ã|Å|Ä'
LIMIT 10;

onarilmis sütununda düzgün Türkçe görüyorsanız, onarım yöntemi doğrudur. Şimdi uygulayın:

UPDATE wp_posts SET
  post_title   = CONVERT( CAST( CONVERT( post_title   USING latin1 ) AS BINARY ) USING utf8mb4 ),
  post_content = CONVERT( CAST( CONVERT( post_content USING latin1 ) AS BINARY ) USING utf8mb4 ),
  post_excerpt = CONVERT( CAST( CONVERT( post_excerpt USING latin1 ) AS BINARY ) USING utf8mb4 );

UPDATE wp_terms SET
  name = CONVERT( CAST( CONVERT( name USING latin1 ) AS BINARY ) USING utf8mb4 );

UPDATE wp_comments SET
  comment_content = CONVERT( CAST( CONVERT( comment_content USING latin1 ) AS BINARY ) USING utf8mb4 ),
  comment_author  = CONVERT( CAST( CONVERT( comment_author  USING latin1 ) AS BINARY ) USING utf8mb4 );

Serileştirilmiş veri tuzağı#

Burada çok önemli bir uyarı var ve bu, yukarıdaki sorguları körü körüne her tabloya uygulayanların sitesini bozan şeydir. wp_options ve wp_postmeta tablolarındaki bazı değerler serileştirilmiş PHP dizileridir ve şu forma sahiptir:

a:2:{s:6:"baslik";s:9:"Güvenlik";s:5:"renk";s:4:"mavi";}

Buradaki s:9: ifadesi "sıradaki metin 9 bayt" demektir. Karakter onarımı metnin bayt uzunluğunu değiştirdiği için sayı artık tutmaz ve PHP diziyi çözemez. Sonuç: tema ayarlarınız, widget'larınız veya eklenti yapılandırmalarınız sıfırlanır.

Bu yüzden:

• wp_options ve wp_postmeta üzerinde yukarıdaki UPDATE sorgularını çalıştırmayın.
• Bu iki tabloda düzeltme gerekiyorsa, serileştirmeyi doğru işleyen WP-CLI aracını kullanın:

wp search-replace 'Güvenlik' 'Güvenlik' wp_options wp_postmeta --precise --all-tables-with-prefix --dry-run

--dry-run ile önce kaç satırın etkileneceğini görün, sonuçtan emin olduğunuzda parametreyi kaldırın. --precise bayrağı, WP-CLI'nin PHP tarafında serileştirmeyi açıp kapatmasını sağlar. Aynı aracın site adresi değiştirirken nasıl kullanıldığını WordPress site adresi yanlış değiştirildi yazısında bulabilirsiniz.

latin1 Tabloyu Veri Kaybetmeden utf8mb4'e Çevirmek#

Teşhis sorgusunda tablolarınızın latin1_swedish_ci olduğunu gördüyseniz, kalıcı çözüm dönüşümdür. Ama burada da bir tuzak var:

-- TEHLİKELİ: tablo latin1 ama içinde zaten UTF-8 baytlar varsa çift kodlar
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4;

CONVERT TO CHARACTER SET, "bu veri gerçekten latin1" varsayımıyla çalışır ve baytları yeniden kodlar. Oysa çoğu WordPress kurulumunda tablo latin1 etiketli olmasına rağmen içinde UTF-8 baytlar durur. Bu komut o durumda bozulmayı kalıcı hâle getirir.

Güvenli yöntem iki adımlıdır: sütunu önce ikili tipe alıp karakter seti bilgisini tamamen düşürün, sonra doğru setle metin tipine geri döndürün. Bu sırada baytlara dokunulmaz:

ALTER TABLE wp_posts
  MODIFY post_title   BLOB,
  MODIFY post_content LONGBLOB,
  MODIFY post_excerpt BLOB;

ALTER TABLE wp_posts
  MODIFY post_title   TEXT     CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
  MODIFY post_content LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
  MODIFY post_excerpt TEXT     CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE wp_posts
  DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Veritabanının varsayılanını da güncelleyin ki bundan sonra oluşturulacak tablolar doğru sette doğsun:

ALTER DATABASE veritabani_adi
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Dönüşüm sırasında karşılaşabileceğiniz bir hata da indeks uzunluğudur. utf8mb4 karakter başına 4 bayt ayırdığı için, eski MySQL sürümlerinde 767 baytlık indeks sınırına takılabilirsiniz; hata metni Specified key was too long şeklinde gelir. WordPress bu yüzden kendi tablolarında dizin uzunluklarını sınırlar. Kendi eklediğiniz tablolarda sorun yaşarsanız, indeksi 191 karakterle sınırlayın:

ALTER TABLE ozel_tablo DROP INDEX slug_idx, ADD INDEX slug_idx (slug(191));

Dönüşüm sırasında bir tablo bozulursa REPAIR TABLE yerine önce CHECK TABLE çalıştırın; InnoDB tablolarda onarım, yedekten geri yüklemeyle yapılır.

Bir Daha Yaşamamak İçin Taşıma Kontrol Listesi#

Sıradaki taşımada aynı akşamı yeniden yaşamamak için sıralamayı bozmayın:

1. Kaynak sunucuda setleri ölç. Yukarıdaki information_schema sorgularını çalıştır, çıktıyı bir yere kaydet.
2. Yedeği açık parametreyle al. mysqldump --default-character-set=utf8mb4.
3. Dosyayı doğrula. file -i ile kodlamayı, grep -c 'ÅŸ' ile bozuk imzayı kontrol et. Bozuk imza varsa taşımaya başlama, önce kaynağı düzelt.
4. Hedef veritabanını doğru setle oluştur. CREATE DATABASE ... CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
5. Geri yüklemeyi açık parametreyle yap. mysql --default-character-set=utf8mb4.
6. wp-config.php içinde DB_CHARSET = utf8mb4, DB_COLLATE boş.
7. Bir Türkçe test yazısı oluştur, ön yüzde ve panelde kontrol et.
8. Dosya tarafını unutma: tema dosyalarınız da UTF-8 (BOM'suz) kaydedilmiş olmalı; functions.php içindeki sabit metinler bu yüzden bozulabilir.

Taşımanın tamamı için sırayı web sitesi taşıma yazısındaki adımlarla birlikte yürütün; alan adı da değişiyorsa WordPress alan adı değiştirme yazısındaki search-replace adımlarını atlamayın.

Sıkça Sorulan Sorular#

Bozuk karakterler veri kaybı anlamına mı geliyor#

Hayır, "ÅŸ" ve "ü" gibi bozukluklar veri kaybı değildir. Bu görüntü, harflerin doğru baytlarının yanlış karakter setiyle yorumlanmasından doğar ve SQL ile bire bir geri döndürülebilir. Gerçek veri kaybının işareti soru işaretidir: metinde "??????" görüyorsanız, karakterin hedef karakter setinde karşılığı olmadığı için MySQL onu soru işaretine çevirmiş ve orijinal bayt silinmiştir. Bu durumda tek çözüm, bozulmadan önce alınmış bir yedeğe dönmektir.

utf8 ile utf8mb4 arasındaki fark nedir#

MySQL'deki utf8, aslında karakter başına en fazla 3 bayt taşıyan utf8mb3 setidir; utf8mb4 ise tam UTF-8 desteği sunar ve 4 bayta kadar çıkar. Türkçe harflerin tamamı 2 baytla ifade edildiği için utf8mb3 ile de sorunsuz saklanır. Ancak emoji, bazı matematiksel semboller ve nadir dillerin karakterleri 4 bayt gerektirir; bunlar utf8mb3 sütununa yazılmaya çalışıldığında sessizce kaybolur veya kayıt hata verir. Bu yüzden yeni kurulumlarda daima utf8mb4 kullanın.

phpMyAdmin'den yedek alırken hangi karakter setini seçmeliyim#

Dışa aktarma ekranındaki karakter kümesi listesinden utf-8 seçin. phpMyAdmin'in "Hızlı" dışa aktarma modu bu seçeneği göstermez, bu yüzden Özel modunu seçmeniz gerekir. Aktarma bittikten sonra indirilen .sql dosyasını bir metin editöründe açıp ilk satırlardaki SET NAMES ifadesini kontrol edin; latin1 yazıyorsa dosyayı geri yüklemeden önce utf8mb4 olarak değiştirin. Büyük dosyalarda editör yerine komut satırından sed kullanmak daha güvenlidir.

wp_options tablosunda karakter onarımı neden yapılmamalı#

Çünkü bu tablodaki birçok değer, uzunluk bilgisi içeren serileştirilmiş PHP dizisidir. Serileştirilmiş bir metinde s:9:"Güvenlik" ifadesindeki sayı, metnin bayt uzunluğunu bildirir; karakter onarımı bayt sayısını değiştirdiği için bu sayı artık tutmaz ve PHP diziyi çözemez. Sonuç, tema ayarlarının ve widget yapılandırmalarının sıfırlanmasıdır. Bu tablolarda düzeltme gerekiyorsa serileştirmeyi doğru işleyen wp search-replace --precise komutunu kullanın.

Yeni yazdığım yazılar düzgün ama eskiler bozuk görünüyor#

Bu, bağlantı ayarının artık doğru olduğunu ama diskteki eski verinin bozuk kaldığını gösterir. wp-config.php içindeki DB_CHARSET düzeltildiğinde ya da tablo seti değiştirildiğinde, o andan sonra yazılan her şey doğru saklanır; ancak daha önce çift kodlanmış olarak kaydedilmiş satırlar kendiliğinden düzelmez. Bunlar için CONVERT(CAST(CONVERT(... USING latin1) AS BINARY) USING utf8mb4) kalıbıyla tek seferlik bir onarım çalıştırmanız gerekir. Onarımı yalnızca wp_posts, wp_terms ve wp_comments gibi düz metin tablolarında uygulayın.

Dosya adlarındaki Türkçe karakterler de sorun çıkarır mı#

Evet ve bu, veritabanından bağımsız ayrı bir sorundur. Türkçe karakter içeren görsel adları (örnek-görsel.jpg), farklı işletim sistemleri ve dosya sistemleri arasında taşınırken bozulabilir; sunucu Linux, kaynak makine Windows ise kodlama farkı yüzünden dosya bulunamaz duruma gelir. Çözüm, medya dosyalarını yüklemeden önce adlarını ASCII'ye indirmektir: Türkçe harfleri sadeleştirin, boşluk yerine tire kullanın. Zaten yüklenmiş dosyalar için sunucuda convmv gibi bir araçla toplu yeniden adlandırma yapılabilir.

Taşıma yaptığım hosting firması mı sorumlu#

Genellikle hayır; bozulma neredeyse her zaman yedeğin alındığı anda, kaynak taraftaki bağlantı ayarından doğar. .sql dosyasında grep -c 'ÅŸ' komutuyla bozuk imza sayarak bunu kesin olarak doğrulayabilirsiniz: dosyada zaten bozuk metin varsa, hedef sunucunun yapabileceği bir şey yoktur. Sayı sıfır çıkıyor ama site bozuk görünüyorsa, o zaman geri yükleme sırasındaki bağlantı seti veya wp-config.php ayarı incelenmelidir. Doğru sıra her zaman önce dosyayı doğrulamaktır.

Kapanış#

Türkçe karakter bozulmasının tamamı tek bir cümlede toplanır: veri sağlamdır, yorum yanlıştır. Teşhisi ekrandaki bozukluğun şeklinden başlatın — "Ã/Å/Ä" görüyorsanız geri dönüş mümkündür, soru işareti görüyorsanız değildir. Ardından üç katmanı (tablo seti, bağlantı seti, çıktı seti) information_schema sorgularıyla ölçün, yedeği --default-character-set=utf8mb4 ile alın, dosyanın SET NAMES satırını kontrol edin ve gerekiyorsa CONVERT/CAST kalıbıyla tek seferlik onarımı yalnızca düz metin tablolarında çalıştırın. wp_options ve wp_postmeta tablolarına serileştirme yüzünden asla ham SQL ile dokunmayın.

Bu adımların hepsini SSH ve phpMyAdmin arasında gidip gelerek yapmak istemiyorsanız, taşımayı devretmek en pratik yoldur: site taşıma hizmeti veritabanı karakter seti dönüşümünü de kapsayacak şekilde yürütülür ve taşıma sonrası kontrol listesi sizin adınıza işletilir. Bozulmadan önceki hâle dönmeniz gerektiğinde işinizi kurtaracak şey düzenli alınmış anlık görüntülerdir; yedekleme hizmeti bunun için vardır. Yeni bir kuruluma geçiyorsanız, veritabanı varsayılanı utf8mb4 olarak gelen ve güncel MySQL sürümü çalıştıran bir ortam seçmek bu sorunu baştan ortadan kaldırır: WordPress hosting paketleri bu yapılandırmayla kurulur, kendi sunucusunu yönetmek isteyenler içinse VDS sunucu tarafında set ayarları tamamen sizin kontrolünüzdedir.