Veritabanı Taşıdım Türkçe Karakterler Bozuldu: Collation Sorunu ve Çözümü

Yeni hostinge geçtiniz, eski sunucudan aldığınız yedek.sql dosyasını phpMyAdmin'in İçe Aktar sekmesine sürüklediniz ve ilerleme çubuğu yarıda kırmızıya döndü: #1273 - Unknown collation: 'utf8mb4_0900_ai_ci'. Ya da daha sinsi olanı yaşadınız: import "başarıyla tamamlandı" dedi, siteyi açtınız ve ürün başlıkları Kaşık Setı diye görünüyor. İki ekran da aynı gibi hissettiriyor ama arkalarındaki problem tamamen farklı ve çözümleri de birbirinin yerine geçmez.

Bu ayrımı en baştan netleştirelim, çünkü internetteki çözümlerin çoğu bu ikisini karıştırdığı için işe yaramıyor:

• Sorun 1 — Dosya hiç yüklenmedi. Hedef MySQL/MariaDB sürümü, dump içindeki collation adını tanımıyor. Tablo bile oluşmadı. Bu bir uyumluluk sorunu; verinizde hiçbir şey yok, çünkü veri henüz gelmedi.
• Sorun 2 — Dosya yüklendi ama veri bozuldu. Baytlar yanlış karakter setiyle okundu veya yanlış karakter setine çevrildi. Tablolar dolu, satırlar yerinde, ama metin okunmuyor. Bu bir kodlama sorunu.

Aşağıda önce hangisinde olduğunuzu 30 saniyede belirleyeceğiz, sonra her biri için ayrı ayrı ilerleyeceğiz. Sonda da "bul-değiştir ile ç yerine ç yazayım" refleksinin neden geçici bir yama olduğunu, hangi durumda verinin geri gelmeyecek şekilde gittiğini göstereceğim.

Hangi Sorundayım: 30 Saniyelik Ayrım#

Cevabı ekrandaki belirti veriyor:

? işaretleriyle Ã bloklarını ayırt etmek kritik. ç gibi görüntüler bilginin hâlâ orada olduğunu, sadece yanlış gözlükle okunduğunu gösterir; geri döndürülebilir. Düz ? ise MySQL'in bir karakteri hedef karakter setinde temsil edemediği için sildiği anlamına gelir ve o bayt artık yok.

Bu, Türkçe için özellikle acımasız bir detay: ç ö ü Ç Ö Ü harfleri latin1 (cp1252) tablosunda vardır, dolayısıyla latin1 üzerinden geçseler bile bozuk görünüp geri gelebilirler. Ama ş ğ ı İ latin1'de hiç yoktur. Bir bağlantı latin1 olarak açılıp veri o bağlantıdan geçtiyse ş harfi ? olur ve hiçbir SQL hilesi onu geri getiremez. Bu yüzden eski sunucu hâlâ ayaktaysa, tamir denemelerine girişmeden önce oradan temiz bir yedek almak her zaman daha ucuzdur.

"Unknown collation: 'utf8mb4_0900_ai_ci'" Hatası Neden Çıkıyor#

Bu hata neredeyse her zaman şu senaryodan gelir: yedek MySQL 8.0 veya üstünde alınmış, hedef sunucu ise MariaDB ya da MySQL 5.7. utf8mb4_0900_ai_ci, MySQL 8.0 ile gelen ve o sürümde varsayılan olan bir sıralama (collation) kuralıdır. MariaDB bu collation'ı hiçbir sürümünde desteklemez; MySQL 5.7 de tanımaz. Dump dosyası içindeki her CREATE TABLE satırında bu ad geçtiği için sunucu ilk tabloda durur.

Hata satır numarası da verir:

ERROR 1273 (HY000) at line 42: Unknown collation: 'utf8mb4_0900_ai_ci'

Aynı ailede karşınıza çıkabilecek diğer adlar: utf8mb4_0900_as_cs (büyük/küçük harfe duyarlı sürüm) ve utf8mb4_tr_0900_ai_ci (Türkçe'ye özel sürüm). MariaDB tarafında ise MySQL'in bilmediği utf8mb4_uca1400_ai_ci gibi adlar vardır; taşıma ters yönde yapılıyorsa bu kez MySQL şikâyet eder.

Bir de daha az bilinen ikinci tuzak var: MySQL 8 dump'ları karakter seti adını utf8mb3 olarak yazabilir. MariaDB bu adı 10.6 sürümünden itibaren tanır; daha eski bir MariaDB'ye aktarıyorsanız Unknown character set: 'utf8mb3' hatası alırsınız. Çözümü aynı mantıkta: adı eski karşılığı olan utf8 ile değiştirmek.

Hedef sunucunuzun neyi desteklediğini görmek için:

SELECT VERSION(), @@version_comment;
SHOW COLLATION WHERE Charset = 'utf8mb4';

Çıktıda utf8mb4_0900_ai_ci yoksa, dosyayı olduğu gibi yüklemeye çalışmanın anlamı yok — dosyayı dönüştürmeniz gerekiyor.

Dump Dosyasını Uyumlu Collation'a Dönüştürme#

En temiz yöntem, SQL dosyası içindeki collation adlarını hedefin tanıdığı karşılıklarıyla değiştirmektir. Bu bir "bul-değiştir" işlemi ama az önce eleştirdiğim türden değil: burada veriye dokunmuyoruz, sadece tablo tanımlarındaki etiketleri düzeltiyoruz. Veri satırları hiç değişmiyor.

Hangi ad neye karşılık geliyor:

Linux veya macOS'ta, SSH erişiminiz varsa tek komutla:

sed -e 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' \
    -e 's/utf8mb4_0900_as_cs/utf8mb4_bin/g' \
    -e 's/utf8mb4_tr_0900_ai_ci/utf8mb4_turkish_ci/g' \
    yedek.sql > yedek-uyumlu.sql

Dosya sıkıştırılmışsa diski şişirmeden akış hâlinde çevirebilirsiniz:

zcat yedek.sql.gz \
  | sed 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' \
  | gzip > yedek-uyumlu.sql.gz

Windows'ta PowerShell ile:

(Get-Content yedek.sql -Raw) `
  -replace 'utf8mb4_0900_ai_ci','utf8mb4_unicode_ci' `
  -replace 'utf8mb4_tr_0900_ai_ci','utf8mb4_turkish_ci' |
  Set-Content yedek-uyumlu.sql -Encoding utf8

Bir uyarı: -Raw dosyanın tamamını belleğe alır. 1 GB'ın üzerindeki dump'larda PowerShell'i kilitler; o boyutlarda ya sunucu tarafında sed kullanın ya da dosyayı bölün. SSH erişiminizin olup olmadığından emin değilseniz cPanel'de SSH erişimi ve terminal yazısı hangi menüden açacağınızı anlatıyor.

Kaynağa Erişiminiz Varsa Daha Sağlam Alternatif#

Eski sunucu hâlâ elinizdeyse, dosyayı sonradan yamalamak yerine baştan uyumlu bir dump almak daha temizdir. MySQL 8 tarafında veritabanını ve tabloları taşımadan önce ortak paydaya çekin:

ALTER DATABASE eski_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE urunler
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER DATABASE yalnızca bundan sonra oluşturulacak tabloları etkiler; mevcut tablolar için tek tek ALTER TABLE ... CONVERT TO çalıştırmanız gerekir. Bu işlem tabloyu yeniden yazdığı için büyük tablolarda zaman alır ve önceden yedek almadan yapılmaz. Yedeğin nasıl alınacağı için mysqldump ile veritabanı yedekleme adımlarını izleyebilirsiniz.

Import Geçti Ama Metin Bozuk: Asıl Hikâye#

İkinci sorun bambaşka bir mekanizmadır ve tek bir cümleyle özetlenir: baytlar doğru, etiket yanlış. MySQL'de metin üç ayrı katmanda karakter seti taşır ve bunların üçü de birbirinden bağımsız yanlış ayarlanabilir:

1. Sütun/tablo karakter seti — verinin diskte hangi kodlamada olduğu iddiası.
2. Bağlantı karakter seti — istemci ile sunucu arasında baytların hangi kodlamada aktığı (SET NAMES).
3. Uygulama çıktısı — PHP'nin gönderdiği Content-Type başlığı ve HTML <meta charset>.

Klasik bozulma şu şekilde oluşur: eski sitede sütunlar latin1 ilan edilmiş ama uygulama içine UTF-8 baytları yazmış. MySQL bunu doğrulamaz, sessizce kabul eder. Yıllarca sorun çıkmaz, çünkü uygulama da aynı yanlış varsayımla okur; iki hata birbirini götürür. Taşıma anında bu denge bozulur: yeni sunucuda sütun utf8mb4 olur ve baytlar bir kez daha kodlanır. ç harfinin UTF-8 karşılığı C3 A7 iken, bu iki bayt latin1 sanılıp yeniden çevrilince C3 83 C2 A7 olur — ekranda gördüğünüz ç tam olarak budur. Buna çift kodlama denir.

Aynı belirtinin WordPress'e özel yansımalarını, wp-config.php içindeki DB_CHARSET ve DB_COLLATE sabitleriyle birlikte WordPress Türkçe karakter sorunu yazısında ayrıca ele aldık.

Teşhis: Verinin Gerçekten Hangi Kodlamada Olduğunu Bulmak#

Tahmin yürütmeden önce baytlara bakın. Bozuk görünen bir satırın ham hâlini isteyin:

SELECT baslik, HEX(baslik), LENGTH(baslik), CHAR_LENGTH(baslik)
FROM yazilar
WHERE id = 17;

Yorumlama tablosu — ç harfi örneği üzerinden:

LENGTH ile CHAR_LENGTH farkı da ipucu verir: UTF-8'de Türkçe harfler 2 bayt tuttuğu için LENGTH her zaman büyük olmalıdır. İkisi eşitse veri tek baytlık bir kodlamada duruyordur. Sunucu ve bağlantı tarafındaki mevcut ayarları da görün:

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
SHOW FULL COLUMNS FROM yazilar;

SHOW FULL COLUMNS çıktısındaki Collation sütunu, her metin alanının gerçekte ne ilan ettiğini satır satır gösterir. Karışık bir veritabanında bazı tabloların latin1_swedish_ci, bazılarının utf8mb4_general_ci olduğunu burada yakalarsınız.

Doğru Çözüm: Bozuğu Onarmak Değil, Doğru Geri Yüklemek#

Eski sunucu hâlâ erişilebilir durumdaysa yapılacak en doğru şey, tamir denemesi değil, baytları olduğu gibi taşıyan bir dump almaktır. Veri diskte doğru UTF-8 olarak duruyor ama sütun latin1 ilan ediyorsa, mysqldump'a "bu veriyi latin1 kabul et ve dönüştürme" demeniz gerekir:

mysqldump -u kullanici -p \
  --skip-set-charset \
  --default-character-set=latin1 \
  --single-transaction \
  eski_db > ham.sql

Bu dosya içinde baytlar hiç dokunulmadan, gerçek UTF-8 hâliyle durur. Şimdi sadece tablo tanımlarındaki etiketleri düzeltin:

sed -e 's/CHARSET=latin1/CHARSET=utf8mb4/g' \
    -e 's/COLLATE=latin1_swedish_ci/COLLATE=utf8mb4_unicode_ci/g' \
    -e 's/ COLLATE latin1_swedish_ci//g' \
    ham.sql > duzeltilmis.sql

Ve utf8mb4 bağlantısıyla geri yükleyin:

mysql -u kullanici -p --default-character-set=utf8mb4 yeni_db < duzeltilmis.sql

Bu üç adım, çift kodlamayı ortaya çıkmadan önlediği için en az veri kaybı riski taşıyan yoldur. phpMyAdmin üzerinden çalışıyorsanız, dışa aktarma ekranında karakter setini elle seçmeniz gerektiğini unutmayın; ekranların yerini phpMyAdmin içe ve dışa aktarma yazısında bulabilirsiniz.

Zaten Bozulmuş Veriyi Kurtarmak#

Eski sunucu kapandıysa ve elinizde yalnızca bozuk veri varsa, iki farklı senaryoya iki farklı müdahale gerekir.

Senaryo A — Sütun latin1 ilan ediyor, baytlar UTF-8. Veri henüz yeniden kodlanmamış; sadece yanlış etiketli. Baytları koruyup etiketi değiştirmek için ikili (binary) ara adım kullanılır:

ALTER TABLE yazilar MODIFY baslik BLOB;
ALTER TABLE yazilar MODIFY baslik TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

BLOB'a geçiş MySQL'e "bunu metin sayma, bayt say" der; ikinci adımda aynı baytlar bu kez utf8mb4 olarak yorumlanır. Doğrudan CONVERT TO CHARACTER SET çalıştırmak burada yanlıştır, çünkü baytları gerçekten dönüştürerek bozulmayı kalıcı hâle getirir.

Senaryo B — Dönüşüm zaten olmuş, ekranda ç var. Bu kez baytlar fiilen değişti; geri almak için ters yönde bir tur atmak gerekir:

UPDATE yazilar
SET baslik = CONVERT(BINARY(CONVERT(baslik USING latin1)) USING utf8mb4)
WHERE baslik LIKE '%Ã%' OR baslik LIKE '%Å%' OR baslik LIKE '%Ä%';

İçeriden dışarı okuyun: CONVERT(... USING latin1) metni latin1'e geri çevirerek çift kodlamanın dış katmanını soyar, BINARY() sonucu ham bayt olarak sabitler, dıştaki CONVERT(... USING utf8mb4) de bu baytları doğru şekilde etiketler.

Üç kural bu sorguyu güvenli kılar:

1. Önce yedek alın. Bu UPDATE geri alınamaz; yanlış senaryoya uygularsanız veriyi bir kat daha bozarsınız.
2. Önce SELECT ile deneyin. Aynı ifadeyi UPDATE yerine SELECT içinde çalıştırıp gözle doğrulayın.
3. Bir kez çalıştırın. İkinci kez çalıştırmak sağlam veriyi bozar; bu yüzden WHERE şartı ile yalnızca bozuk satırları hedefleyin.

Eski sunucu latin1 değil de Türkçe'ye özel latin5 (ISO-8859-9) kullanıyorduysa, sorgudaki latin1 yerine latin5 yazmanız gerekir. Bunu HEX() çıktısından ayırt edebilirsiniz: ş harfi latin5'te tek bayt FE, latin1'de ise hiç yoktur.

Neden Bul-Değiştir Yamalı Bir Çözümdür#

En sık başvurulan yöntem, ç → ç, ÄŸ → ğ gibi eşlemeleri bir SQL REPLACE zinciriyle uygulamaktır. İşe yarıyormuş gibi görünür; ilk on satırı düzeltir, sonra sessizce yeni sorunlar üretir:

• Liste asla tamamlanmaz. Türkçe için ç ğ ı ö ş ü ve büyük harfleri, ayrıca â î û ve tırnak/tire karakterlerinin ayrı bozuk karşılıkları vardır. Birini atlarsanız o karakter bozuk kalır ve bir daha aranmaz.
• Kısmi eşleşmeler zincirleme bozar. Değiştirme sırası önemlidir; Ã içeren bir kalıbı önce uygularsanız, sonraki kuralın yakalaması gereken üç baytlık diziyi ortadan ikiye bölmüş olursunuz.
• Kök neden yerinde kalır. Sütun hâlâ yanlış karakter seti ilan ediyorsa, bir sonraki kayıt yine bozuk yazılır. Bir hafta sonra aynı sorunla, bu kez yeni içerikte karşılaşırsınız.
• Sıralama ve arama yanlış kalır. Collation yalnızca görüntüyü değil, ORDER BY sonucunu ve WHERE ... LIKE eşleşmesini de belirler. Metni gözle düzeltmek bu davranışı düzeltmez.

Bul-değiştir'in meşru olduğu tek yer var: tablo tanımlarındaki collation adlarını değiştirmek, yani bu yazının başındaki uyumluluk sorunu. Orada veriye değil, şemaya dokunuyorsunuz.

Türkçe İçin Hangi Collation Seçilmeli#

utf8mb4 karakter seti tartışmasız; asıl karar collation'da. Üç seçenek pratikte anlamlı:

Türkçe'nin noktalı/noktasız i sorunu burada somutlaşır: utf8mb4_unicode_ci ile WHERE ad = 'ISIL' sorgusu Işıl kaydını yakalar; utf8mb4_turkish_ci ile yakalamaz, çünkü Türkçe'de I'nın küçüğü ıdır. Hangisinin doğru olduğu uygulamanıza bağlıdır, ama veritabanı genelinde tek bir collation kullanmak her ikisinden de önemlidir. Farklı collation'lara sahip iki tabloyu JOIN ettiğinizde MySQL Illegal mix of collations hatası verir ve sorgu hiç çalışmaz.

Uygulama tarafında bağlantıyı da hizalamayı unutmayın; PHP/PDO için:

$pdo = new PDO(
    'mysql:host=localhost;dbname=site_db;charset=utf8mb4',
    $kullanici,
    $parola,
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

DSN içindeki charset=utf8mb4 bağlantı açılırken SET NAMES utf8mb4 çalıştırır. Bu satır eksikse tablolar doğru olsa bile veri yine bozuk yazılır.

Taşımadan Önce 6 Maddelik Kontrol Listesi#

1. Kaynak sunucuda SHOW VARIABLES LIKE 'character_set%' ve SELECT VERSION() çıktılarını kaydedin.
2. Hedef sunucuda SHOW COLLATION WHERE Charset='utf8mb4' ile desteklenen adları doğrulayın; sürümler farklıysa dönüştürme adımını baştan planlayın.
3. Yedeği --single-transaction ve doğru --default-character-set ile alın.
4. Yedeği açıp ilk 40 satırına bakın: CREATE TABLE satırlarındaki CHARSET= ve COLLATE= değerleri beklediğiniz gibi mi?
5. Gerçek veriyle test edin — Türkçe'nin altı özel harfini birden içeren bir satır (Şişli Çiğdem Bağı Ütü Işıl) en hızlı testtir.
6. Import'tan sonra siteyi açmadan önce doğrudan veritabanından bir SELECT çekin. Ekranda bozuk görünen metnin veritabanında sağlam olması, sorunun uygulama katmanında olduğunu söyler.

Bağlantı bilgilerini nereden alacağınızı hatırlamıyorsanız veritabanı bilgileri nereden bulunur yazısı kontrol panelindeki yerlerini gösteriyor.

Sıkça Sorulan Sorular#

utf8mb4_0900_ai_ci hatası veriyi bozar mı?#

Hayır, bu hata veriyi bozmaz — tam tersine hiçbir şeyin yazılmasına izin vermez. Sunucu tanımadığı collation adını gördüğü anda o ifadeyi reddeder ve import durur. Riskli olan durum, hatanın ilk tablodan sonra çıkması ve kısmen dolu bir veritabanıyla kalmanızdır. Bu yüzden dönüştürülmüş dosyayı yüklemeden önce hedef veritabanını tamamen boşaltmak (DROP DATABASE ve yeniden oluşturmak) en temiz başlangıçtır.

utf8 ile utf8mb4 arasındaki fark nedir?#

MySQL'in eski utf8 karakter seti aslında utf8mb3'tür ve karakter başına en fazla 3 bayt saklar. Bu, Türkçe harfler için yeterlidir ama emoji ve bazı nadir Unicode karakterleri için değildir. utf8mb4 4 bayta kadar çıkar ve Unicode'un tamamını kapsar. Yeni kurulan her veritabanında utf8mb4 kullanılmalıdır; utf8 yalnızca eski sistemlerle uyumluluk için vardır ve MySQL 8'de kullanımdan kaldırılma sürecindedir.

Soru işaretine dönüşen karakterleri geri getirebilir miyim?#

Veritabanı üzerinden hayır. Soru işareti, MySQL'in bir karakteri hedef karakter setinde temsil edemediği için yerine koyduğu bir vekildir; orijinal bayt kaydedilmemiştir, dolayısıyla geri hesaplanamaz. Tek kurtarma yolu, bozulmanın olmadığı bir kaynaktan gelmektir: eski sunucudaki veritabanı, taşımadan önce alınmış bir yedek veya uygulamanın kendi log/arşiv kayıtları. Bu nedenle eski sunucuyu, yeni sistem doğrulanana kadar kapatmamak gerekir.

Tablolarımın collation'ını topluca nasıl değiştiririm?#

Tek tek ALTER TABLE yazmak yerine, information_schema üzerinden gereken komutları ürettirebilirsiniz: SELECT CONCAT('ALTER TABLE \', TABLE_NAME, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') FROM information_schema.TABLES WHERE TABLE_SCHEMA='veritabani_adi';` Çıkan listeyi kopyalayıp çalıştırın. Ancak bu komut baytları gerçekten dönüştürür; verinin doğru etiketli olduğundan emin değilseniz önce yedek alın ve bu yazıdaki teşhis adımlarını uygulayın.

phpMyAdmin'de import ederken karakter setini ne seçmeliyim?#

İçe Aktar ekranındaki "Dosyanın karakter kümesi" alanı, dosyadaki baytların hangi kodlamada olduğunu belirtir; hedef veritabanının ne olduğunu değil. Modern bir mysqldump çıktısı için doğru seçim utf8mb4'tür. Dosya çok eski bir sistemden geliyorsa ve içinde SET NAMES latin1 satırı varsa, dosya kendi kodlamasını zaten bildirdiği için buradaki seçim yok sayılabilir. Emin olmak adına dosyanın ilk satırlarını bir metin editöründe açıp SET NAMES ifadesini kontrol edin.

Taşıma sonrası sadece bazı tablolar bozuk, neden?#

Bu, veritabanının zaman içinde farklı araçlarla büyütüldüğünü gösterir. Eski tablolar bir kurulum sihirbazının varsayılanı olan latin1_swedish_ci ile, sonradan eklenen tablolar ise güncel bir aracın varsayılanı olan utf8mb4 ile oluşturulmuştur. Taşıma sırasında ikisi farklı davrandığı için sadece biri bozulur. SHOW TABLE STATUS çıktısındaki Collation sütununu tarayarak hangi tabloların ayrıştığını hızlıca görebilir ve müdahaleyi yalnızca onlara uygulayabilirsiniz.