WordPress "Unknown collation: utf8_general_ci" Hatası ve 3 Kesin Çözümü

"#1273 – Unknown collation" hatası; WordPress veritabanını yeni sunucuya taşırken, dışa aktarılan .sql dosyasındaki karakter seti sıralamasının (collation) hedef sunucudaki MySQL sürümü tarafından tanınmamasından kaynaklanır. En sık görüldüğü senaryo: güncel MySQL çalıştıran bir hosting'den (özellikle GoDaddy gibi yurt dışı sağlayıcılardan) alınan yedeğin, daha eski MySQL sürümlü bir sunucuya phpMyAdmin ile yüklenmesidir. Çözüm üç yoldan biriyle mümkün: hedef sunucuyu güncellemek, yedeği uyumluluk modunda almak veya .sql dosyasında bul-değiştir yapmak. Üçünü de adım adım anlatıyoruz.

Hata Neden Oluşur?

MySQL her sürümde yeni collation'lar ekler: utf8mb4_unicode_520_ci MySQL 5.6, utf8mb4_0900_ai_ci ise MySQL 8.0 ile geldi. Kaynak sunucu bu yeni collation'lardan biriyle çalışıyorsa, aldığınız .sql yedeği tablo tanımlarında o collation adını taşır. Hedef sunucunun MySQL sürümü bu adı tanımıyorsa import işlemi "#1273 – Unknown collation" hatasıyla durur. Yani sorun verinizde değil, iki sunucunun MySQL sürümleri arasındaki farktadır.

Çözüm 1: Hedef Sunucunun MySQL Sürümünü Güncelleyin

VPS veya kendi sunucunuzu kullanıyorsanız kalıcı çözüm budur: hedef sunucunun MySQL/MariaDB sürümünü kaynakla aynı veya daha yeni bir sürüme yükseltin; yedek hiçbir değişiklik gerektirmeden yüklenir. Paylaşımlı hosting'deyseniz sürümü siz değiştiremezsiniz — hosting firmasından PHP 8+ ve MySQL 8 destekli bir plana geçiş isteyin ya da aşağıdaki iki yöntemden biriyle ilerleyin.

Çözüm 2: Yedeği Uyumluluk Modunda Alın

Kaynak sunucuya hâlâ erişiminiz varsa en temiz yol, yedeği baştan doğru almaktır:

1. phpMyAdmin'de veritabanını seçip Dışa Aktar → Özel yöntemini açın.
2. "Maximal length of created query" bölümünün üstündeki uyumluluk ayarında MYSQL40 seçin (bazı sürümlerde "Database system or older MySQL server to maximize output compatibility with" olarak geçer).
3. Yedeği bu ayarla indirip hedef sunucuya normal şekilde import edin.

Bu modda dosya, eski sürümlerin de tanıdığı genel collation'larla yazılır ve hata oluşmaz.

Çözüm 3: .sql Dosyasında Bul-Değiştir

Elinizde yalnızca .sql dosyası varsa Notepad++ veya VS Code ile açıp (Word gibi ofis programlarıyla değil) Ctrl+H ile şu değişimleri sırasıyla "tümünü değiştir" olarak uygulayın:

1. utf8mb4_0900_ai_ci → utf8mb4_general_ci
2. utf8mb4_unicode_520_ci → utf8mb4_unicode_ci
3. Hedef sunucu utf8mb4'ü hiç tanımıyorsa (çok eski MySQL): utf8mb4 → utf8 — bu adım emoji ve bazı özel karakterleri desteklemez hâle getirir, yalnızca zorunluysa uygulayın.

Kaydedip import'u tekrarlayın. Son olarak wp-config.php dosyasında DB_CHARSET değerinin utf8mb4 (3. adımı uyguladıysanız utf8) olduğundan, DB_COLLATE değerinin ise boş bırakıldığından emin olun — WordPress doğru collation'ı bu ayarlarla kendisi seçer.

Taşıma Sonrası Kontrol Listesi

• Türkçe karakter testi: Birkaç yazı ve menü başlığında ğ-ş-ç-ı-ö-ü karakterlerinin bozulmadığını kontrol edin; bozulma varsa import karakter seti yanlış seçilmiştir, yedeği utf8mb4 olarak yeniden yükleyin.
• Adres ayarları: Alan adı da değiştiyse veritabanında siteurl ve home değerlerini güncelleyin.
• Kalıcı bağlantılar: Panelden Ayarlar → Kalıcı Bağlantılar sayfasını bir kez kaydedin; 404 hatalarının çoğu bununla çözülür.
• Eski yedeği saklayın: Orijinal .sql dosyasını, site en az bir hafta sorunsuz çalışana kadar silmeyin.

Sık Sorulan Sorular

Bu hata veri kaybına yol açar mı?

Hayır. Hata import işleminin başında oluşur ve işlem durur; verileriniz .sql dosyasının içinde sağlam durmaktadır. Risk, hatayı çözerken dosyada yanlış bul-değiştir yapmaktır — bu yüzden değişikliğe başlamadan önce .sql dosyasının bir kopyasını mutlaka ayırın.

utf8mb4 yerine utf8 kullanmak güvenli mi?

Mecbur kalmadıkça önerilmez. utf8mb4, emojiler ve 4 baytlık özel karakterler dahil tam Unicode desteği sunar; MySQL'in eski utf8 türü bu karakterleri kaydedemez. Yalnızca hedef sunucu utf8mb4'ü hiç tanımıyorsa geçici çözüm olarak kullanın ve ilk fırsatta güncel MySQL sürümlü bir sunucuya geçin.

Hangi collation değerini seçmeliyim?

Güncel WordPress kurulumları için standart: karakter seti utf8mb4, collation utf8mb4_unicode_ci (MySQL 8'de varsayılan utf8mb4_0900_ai_ci de sorunsuzdur). Türkçe içerikte iki seçenek de doğru sıralama yapar; önemli olan tüm tabloların aynı collation'ı kullanması, karışık yapıda kalmamasıdır.

Hata phpMyAdmin dışında, komut satırında da çıkar mı?

Evet; sorun phpMyAdmin'e değil MySQL sürümüne bağlı olduğu için mysql komutuyla import ederken de aynı #1273 hatası alınır. Çözümler birebir aynıdır; komut satırında ek olarak sed ile bul-değiştiri tek komutta yapabilirsiniz, ancak yine önce dosyanın kopyasını alın.

Site taşımayı kendim mi yapmalıyım, uzmana mı bırakmalıyım?

Küçük bir blog ve güncel yedek varsa bu rehberle kendiniz taşıyabilirsiniz. E-ticaret verisi, üyelik sistemi veya yoğun trafikli bir kurumsal site söz konusuysa uzman desteği alın: yanlış taşınan veritabanı sipariş kaybına ve SEO trafik düşüşüne yol açar; düzeltmesi, önlemekten her zaman pahalıdır.

Taşımayı Dert Etmeyin

Veritabanı taşıma, tek harf hatasının siteyi çökertebildiği bir iştir; vaktiniz veya yedeğiniz kıymetliyse süreci devretmek en ucuz sigortadır. Sunucu ve veritabanı işlerinde yazılım hizmetimizle destek oluyoruz; WordPress'in bakım yüküyle uğraşmak yerine panelden yönetilen kurumsal bir altyapıya geçmeyi düşünüyorsanız web tasarım hizmetimize göz atın ve ücretsiz teklif alın — mevcut sitenizi kayıpsız taşıyacak planı birlikte çıkaralım.