Moleküler biyolojide ve genetik tıpta en yıkıcı, en öldürücü mutasyon türü "Çerçeve Kayması Mutasyonu"dur (Frameshift Mutation).

Biyolojinin temel kanunudur: Hücredeki ribozom, DNA'dan kopyalanan haberci RNA (mRNA) zincirindeki nükleotidleri (A, U, G, C) üçerli harf grupları —yani "kodonlar"— halinde okuyarak amino asitleri dizer. Örneğin: AUG - GCA - UAC... Her üç harf, kusursuz bir proteini inşa eder.

Fakat genetik zincirin arasına yanlışlıkla fazladan tek bir nükleotid girdiğinde veya tek bir harf silindiğinde ne olur?
Ribozomun okuma penceresi bir harf kayar! O saniyeden sonra gelen tüm üçlüler anlamsızlaşır; ortaya çıkan protein tamamen bozulur, katlanamaz, çöker ve hücre ölür. Alfabedeki tek bir eksen kayması, kütüphaneler dolusu bilgiyi bir saniyede anlamsız bir gürültü yığınına çevirir.

Web hosting sektöründe, veritabanı yönetiminde ve altyapı transferlerinde de tam olarak bu genetik tercüme felaketini birebir yaşatan, her sistem mühendisinin hayatında en az bir kez soğuk terler dökmesine yol açan meşhur bir kabus vardır: "Ücretsiz Site Taşıma" Vaadiyle Yapılan Migration ve Ardından Veritabanındaki Tüm Türkçe Karakterlerin Soru İşaretine (?) Dönüşmesi.

"Bize Gelin, Sitenizi Ücretsiz Taşıyalım!"

Hosting firmalarının pazarlama departmanlarının en sevdiği kanca kampanyasıdır:
"Mevcut firmanızdan memnun değil misiniz? Bize gelin! Alanında uzman teknik ekibimiz tüm sitelerinizi, veritabanlarınızı ve e-postalarınızı eski sunucunuzdan yeni bulut altyapımıza sıfır kesintiyle ve tamamen ücretsiz taşısın!"

On yıldır aynı eski sunucuda sitesini barındıran şirket patronu bu cazip teklife kanar. Yeni paketi satın alır, eski cPanel şifrelerini desteğe iletir: "Hadi bakalım, taşıyın."

Destek masasındaki genç teknisyen için bu işlem görünüşte çocuk oyuncağıdır:
Eski sunucuya girilir, mysqldump ile veritabanı dışarı aktarılır, dosya yeni sunucuya çekilir ve mysql -u root < yedek.sql komutuyla içeri basılır. İki dakikalık bir kopyala-yapıştır operasyonu!

Fakat o teknisyenin unuttuğu çok karanlık bir tarihsel enkaz vardır: Türkiye İnternetinin Karakter Kodlaması (Encoding) Çöplüğü.

Latin5, Latin1 ve UTF-8 Arasında Kırk Yıllık Kaos

1990'ların sonu ve 2000'lerin başında MySQL veritabanlarında evrensel UTF-8 standardı henüz yerleşmemişti.

O yıllarda Türk geliştiriciler Türkçe karakterleri (ş, ğ, ı, ç, ö, ü, İ) saklayabilmek için iki yola başvururlardı:

  • Ya Windows'un ISO standardı olan latin5 (ISO-8859-9 / Turkish) karakter setini seçerlerdi,
  • Ya da MySQL'in varsayılanı olan latin1 (ISO-8859-1 / Swedish) tablosunu kullanır, fakat PHP kodunun içine SET NAMES 'latin5' diyerek veritabanını kandırırlardı!

Daha da kötüsü: 2015'ten sonra yazılımcılar UTF-8'e geçmeye karar verdiğinde veritabanını doğru dönüştürmek yerine; o eski latin1 tablosunun içine UTF-8 baytları yazmaya başladılar!
Buna veritabanı teorisinde "Çift Kodlama" (Double Encoding / Mojibake) denir.
Yani veri fiziksel olarak bir karakter setindedir; ama mantıksal olarak başka bir karakter seti gibi saklanmıştır!

Eski sunucudaki o eski MySQL 5.1 sürümü ve eski PHP 5.4 motoru, bu çarpık evliliği bir şekilde hoş görür ve web sitesinde yazıları düzgün gösterirdi. Çürük bir kolonun üzerinde duran ama mucize eseri yıkılmayan bir gecekondu gibi...

Ta ki yeni nesil, modern bir Linux sunucuya taşınana kadar!

Sabah Gelen Hiyeroglif Faciası

Genç teknisyen yedeği alır.
Yeni sunucuda ne çalışmaktadır? Modern MySQL 8.0 veya MariaDB 10.11.
Yeni sunucunun varsayılan karakter seti nedir? Dört baytlık emojileri bile destekleyen kusursuz utf8mb4 ve utf8mb4_unicode_ci.

Teknisyen eski SQL dosyasını yeni veritabanına import eder.
MySQL 8.0 o eski bozuk baytları okumaya çalışır:
"Ben bunu okuyamıyorum, bu bayt dizilimi geçerli bir UTF-8 karakteri değil!" der.
Ve geçerli olmayan her bir baytın yerine ne basar?
Bir adet soru işareti: ?

Ya da baytları kaba kuvvetle UTF-8'e zorlar ve ortaya o meşhur hiyeroglif çorbası çıkar:

  • "Şirketimiz" kelimesi -> "Þirketimiz"
  • "Çözümlerimiz" kelimesi -> "Çözümlerimiz"
  • "İletişim" kelimesi -> "Ä°letiÅŸim"

Ve sabah saat 09:00'da şirket patronu yeni sunucudaki web sitesini açar.
Gözlerine inanamaz!
On yıllık şirket web sitesi, tüm blog yazıları, ürün açıklamaları, müşteri yorumları adeta uzaylı alfabesine veya soru işareti tarlasına dönmüştür:
"Firmam?z 1995 y?l?ndan beri mü?terilerine kaliteli hizmet..."

Patronun tansiyonu fırlar. Telefon ahizesi yerinden fırlar:

"Siz benim sitemi ne hale getirdiniz?! On yıllık emeğimi Çinceye çevirmişsiniz! Tüm metinler soru işareti olmuş! Derhal sitemi eski haline getirin yoksa sizi mahkemede süründürürüm!"

İki Saniyede Yok Olan Bilgi: Geri Dönüşsüz Bozulma

İşin en korkunç boyutu şudur:
Eğer ekranda Þirketimiz görüyorsanız, hala bir umut vardır! Çünkü alttaki baytlar hala duruyordur; sadece karakter seti haritası (charset mapping) yanlıştır. Doğru bir iconv veya Python scriptiyle o baytlar tekrar geri çözülebilir.

Fakat eğer veritabanına import edilirken karakterler gerçekten ? (soru işareti) karakterine dönüştüyse...
Geçmiş olsun!
Çünkü soru işareti ASCII tablosunda 0x3F baytıdır.
Orijinal "Ş" harfinin de, "Ç" harfinin de, "Ğ" harfinin de o zengin bayt kimliği silinmiş; yerine tek bir 0x3F basılmıştır!

Artık dünyadaki hiçbir yapay zeka veya algoritma o soru işaretinin aslında hangi harf olduğunu bilemez! Veri fiziksel ve matematiksel olarak tamamen yok olmuştur.

Destek masasında o an başlayan çaresizlik ameliyatını yaşayan bilir:
Mühendis eski sunucuya koşar. Eski sunucunun yedeğini bir daha alır.
mysqldump --default-character-set=latin1 --skip-set-charset gibi garip parametrelerle dener.
Metin editöründe 500 MB'lık SQL dosyasını açıp sed komutlarıyla toplu arama-değiştirme yapmaya çalışır.
Saatler geçer; patron hatta bekler, genç mühendisin elleri titrer.

Veri Göçünün Cerrahi Protokolü

Bir veritabanını başka bir sunucuya taşımak basit bir dosya kopyalama işlemi değil; bir kan nakli operasyonudur. Yanlış kan grubu hastayı öldürür.

Profesyonel bir sistem mühendisi şu kuralları asla çiğnemez:

  1. Önce Karakter Kodlamasını Teşhis Edin: Yedeği almadan önce eski veritabanının değişkenlerine bakın:
    SHOW VARIABLES LIKE 'character_set_%';
    SHOW VARIABLES LIKE 'collation_%';
    Tabloların hangi sette oluşturulduğunu değil, verinin içine hangi sette yazıldığını tespit edin.
  2. Binary (Ham) Dump Alın: Karakter dönüşümü karmaşası yaşamamak için dump alırken --default-character-set=binary parametresini kullanarak veriyi karakter olarak değil, saf bayt (hex/binary) olarak çekin. Böylece MySQL taşırken araya girip harfleri bozamaz.
  3. Yeni Sunucuda Karakter Setini Eşleştirin: Veriyi doğrudan modern UTF-8'e zorlamayın. Önce yeni sunucuda veritabanını eski karakter setiyle (latin5 ise latin5) açın, veriyi import edin. Verinin pürüzsüz geldiğini gördükten sonra, SQL komutlarıyla kontrollü olarak ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 diyerek dönüştürün.
  4. Eski Sunucuyu Asla Hemen Kapatmayın: Yeni sunucudaki tüm Türkçe karakterlerin, formların ve arama motoru sonuçlarının eksiksiz çalıştığı onaylanana kadar eski sunucu en az 1 hafta boyunca canlı bir güvence olarak açık tutulmalıdır.

Tıpta genetik kodun tek bir harfi kaydığında ölümcül hastalıklar doğar.

Veri tabanında da tek bir karakter seti uyuşmazlığı, on yıllık bir kurumsal hafızayı soru işaretlerinden ibaret bir enkaz haline getirir.

Taşıma vaatlerine kanıp körlemesine veritabanı kopyalamayın. Alfabenize ve baytlarınıza sahip çıkın; çünkü dijital dünyada silinen bir harfin cenazesini hiçbir vaat kaldıramaz.