Büyük SQL dosyaları yüklenirken karakter seti hataları nasıl önlenir?

Büyük bir SQL dosyasını yeni bir sunucuya, farklı bir veritabanı sürümüne veya panel üzerinden içe aktarırken Türkçe karakterlerin bozulması, en sık karşılaşılan taşıma problemlerinden biridir. “İ”, “ş”, “ğ” gibi karakterlerin soru işaretine dönüşmesi çoğu zaman dosyanın bozuk olmasından değil; dışa aktarma, bağlantı ve içe aktarma aşamalarında farklı karakter setlerinin kullanılması nedeniyle oluşur. Bu nedenle işlemi başlatmadan önce dosya, veritabanı ve uygulama tarafında aynı dil kodlamasının kullanıldığından emin olmak gerekir.

Karakter seti hataları neden oluşur?

SQL aktarımında karakter seti, verinin hangi kodlama standardıyla okunup yazılacağını belirler. Eski sistemlerde latin1 veya utf8 kullanılmış olabilir. Güncel projelerde ise özellikle çok dilli içerik, emoji ve özel semboller için utf8mb4 tercih edilmelidir.

Hata genellikle şu noktalardan birinde ortaya çıkar:

• SQL dosyası farklı bir karakter setiyle dışa aktarılmıştır.
• Yeni veritabanının varsayılan karakter seti eski sistemden farklıdır.
• İçe aktarma sırasında bağlantı kodlaması belirtilmemiştir.
• Dosya editörle açılıp yanlış kodlamayla yeniden kaydedilmiştir.
• Panel veya araç büyük dosyayı parçalı işlerken bağlantı ayarını koruyamamıştır.

İçe aktarmadan önce dosyayı kontrol edin

Dosyayı doğrudan yüklemek yerine önce hangi karakter setiyle kaydedildiğini kontrol etmek zaman kazandırır. Büyük SQL dosyalarını klasik metin editörleriyle açmak risklidir; editör dosyayı kaydederken kodlamayı değiştirebilir veya dosyanın tamamını belleğe alamadığı için bozulmaya yol açabilir.

Sunucu üzerinde kontrol yapabiliyorsanız dosya kodlamasını incelemek için aşağıdaki komutlar kullanılabilir:

file -i yedek.sql
head -n 30 yedek.sql

SQL dosyasının ilk satırlarında SET NAMES, CHARACTER SET veya COLLATE ifadeleri bulunuyorsa içe aktarma davranışını etkileyebilir. Örneğin dosya utf8mb4 verisi içerirken başında latin1 tanımı varsa aktarım sonrası karakterler bozulabilir.

Veritabanı karakter setini doğru seçin

Yeni veritabanını oluştururken karakter seti ve collation değerini baştan doğru belirlemek en güvenli yaklaşımdır. WordPress, e-ticaret ve kurumsal web projelerinde genellikle utf8mb4 ve dile göre uygun bir collation tercih edilir. Genel kullanım için utf8mb4_unicode_ci veya MySQL 8 kullanılıyorsa utf8mb4_0900_ai_ci değerlendirilebilir.

CREATE DATABASE veritabani_adi
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

Mevcut veritabanında tablo bazlı farklılıklar varsa yalnızca veritabanı seviyesini değiştirmek yeterli olmayabilir. Tablo ve sütun collation değerleri de kontrol edilmelidir. Özellikle eski projelerden taşınan içeriklerde bazı tablolar latin1, bazıları utf8 olarak kalmış olabilir.

Büyük SQL dosyalarında panel yerine komut satırı kullanın

phpMyAdmin veya benzeri paneller küçük yedeklerde pratik olsa da büyük dosyalarda zaman aşımı, bellek sınırı ve parça parça aktarım problemleri yaşanabilir. Bu durum karakter seti ayarlarının aktarım boyunca tutarlı kalmasını da zorlaştırabilir. Güvenilir bir hosting altyapısında SSH erişimi varsa komut satırıyla içe aktarma daha kontrollü sonuç verir.

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

Bu komutta –default-character-set=utf8mb4 parametresi bağlantı sırasında verinin nasıl yorumlanacağını açıkça belirtir. Dosya gerçekten utf8mb4 ise bu yöntem Türkçe karakterlerin korunmasına yardımcı olur. Dosya latin1 ise önce doğru tespit yapılmalı, ardından dönüşüm planlanmalıdır.

Dışa aktarma aşamasında doğru parametreleri kullanın

Karakter seti hatalarını önlemenin en etkili yolu yalnızca içe aktarmaya değil, dışa aktarmaya da dikkat etmektir. Eski sunucu üzerinden yedek alırken bağlantı karakter setini açıkça belirtmek gerekir.

mysqldump --default-character-set=utf8mb4 -u kullanici -p veritabani_adi > yedek.sql

Eğer kaynak veritabanı gerçekten latin1 çalışıyorsa bu parametreyi rastgele utf8mb4 yapmak her zaman doğru değildir. Önce mevcut tablo ve sütun yapısı incelenmeli, ardından gerekirse kontrollü dönüştürme yapılmalıdır. Yanlış dönüşüm, zaten bozuk görünen karakterlerin kalıcı olarak bozulmasına neden olabilir.

WordPress ve uygulama ayarlarını gözden geçirin

Veritabanı doğru aktarılsa bile uygulama bağlantısı farklı karakter seti kullanıyorsa ekranda bozuk karakterler görülebilir. WordPress projelerinde wp-config.php dosyasındaki DB_CHARSET değeri kontrol edilmelidir. Modern kurulumlarda bu değer genellikle utf8mb4 veya utf8 olarak gelir; veritabanı yapısıyla uyumlu olması önemlidir.

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

Taşıma sonrasında yönetim paneli, tema dosyaları, e-posta şablonları ve özel eklenti tabloları da test edilmelidir. Çünkü bazı eklentiler kendi tablolarını farklı collation ile oluşturmuş olabilir.

Bozulmuş karakterlerle karşılaşırsanız ne yapmalısınız?

Aktarım sonrası içerikte “ü”, “ÄŸ” veya “?” gibi ifadeler görüyorsanız hemen tekrar tekrar içe aktarma yapmayın. Önce bozulmanın dosyada mı, veritabanında mı yoksa görüntüleme katmanında mı oluştuğunu ayırmak gerekir. SQL dosyasındaki ham veri doğru görünüyorsa sorun içe aktarma veya bağlantı ayarındadır. Dosyanın kendisi bozuksa kaynak sistemden yeniden yedek almak genellikle en temiz çözümdür.

Kurumsal projelerde işlem öncesi veritabanının birebir kopyası alınmalı, test ortamında deneme aktarımı yapılmalı ve örnek içerikler karşılaştırılmalıdır. Özellikle farklı hosting ortamları arasında taşıma yapılırken MySQL/MariaDB sürümü, varsayılan collation ve SSH erişimi gibi teknik detaylar önceden netleştirilmelidir.

Pratik kontrol listesi

• Kaynak veritabanının karakter seti ve collation değerlerini kontrol edin.
• SQL dosyasını büyük dosya uyumlu araçlarla inceleyin, rastgele kaydetmeyin.
• Yeni veritabanını utf8mb4 uyumlu oluşturun.
• Büyük dosyalarda mümkünse komut satırıyla içe aktarım yapın.
• mysql ve mysqldump işlemlerinde default-character-set parametresini belirtin.
• WordPress veya uygulama bağlantı ayarlarını veritabanıyla uyumlu hale getirin.
• Canlıya almadan önce Türkçe karakter içeren örnek kayıtları kontrol edin.

Bu kontroller standart bir taşıma planına eklendiğinde, büyük SQL dosyalarında karakter seti kaynaklı veri kaybı riski belirgin şekilde azalır ve yeni sunucu ortamına geçiş daha öngörülebilir hale gelir.