Epin Satış Scriptinde Türkçe Karakterler Bozuluyor mu? Veritabanının Sana Yıllarca Sakladığı Üç Baytlık Yalanı ve Kalıcı Onarım Yöntemini Açıklıyoruz

Çoğu işletme sahibi karakter bozulmasını basit bir görsel kusur sanır. Ürün adında "Ünlü" yazması gerekirken "Ãœnlü" görünür, sipariş notunda soru işaretleri belirir, müşteriye giden e-postada isim tanınmaz hâle gelir. Çözüm olarak bozuk kayıtları elle düzeltir, bir süre rahat eder, sonra yeni siparişlerde aynı manzara geri gelir. Bu noktada genellikle "tema bozuk" veya "tarayıcı sorunu" denip geçilir.

Gerçek şu: karakter bozulması bir görüntü sorunu değil, veri sorunudur ve bozulduğu anda geri dönüş her geçen gün zorlaşır. Çünkü bir metin yanlış karakter setinde kaydedildiğinde orijinal bilgi kaybolmaz, sadece yanlış yorumlanır; ama üstüne bir kez daha yanlış dönüşüm uygulanırsa bilgi gerçekten kaybolur. Bu yazıda bir epin scripti kurulumunda karakterlerin hangi noktalarda bozulduğunu, veritabanının sana yıllardır sakladığı üç baytlık kısıtlamayı, bozulmuş veriyi nasıl kurtaracağını ve bir daha bozulmaması için hangi sözleşmeyi kuracağını anlatıyoruz.

Türkçe Karakterler Gerçekten Kayboldu mu, Yoksa Yanlış Gözlükle mi Bakıyorsun?

Bir metin bilgisayarda harf olarak değil bayt dizisi olarak durur. Aynı bayt dizisi farklı karakter setleriyle okunduğunda farklı harfler üretir. "ü" gördüğünde aslında olan şudur: veri doğru kaydedilmiştir, ancak okuma sırasında yanlış set kullanılmıştır. Bu durumda veri sağlamdır ve tek bir ayar düzeltmesiyle her şey yerine oturur. Soru işareti veya boş kare gördüğünde ise durum farklıdır: karakter kaydedilirken hedef sette karşılığı bulunamamış ve yerine vekil bir işaret yazılmıştır. Bu, gerçek ve geri dönüşü olmayan bir kayıptır.

Teşhisi netleştirmek için ikili bir test yap. Aynı kaydı hem panelden hem doğrudan veritabanı arayüzünden oku. İkisinde de bozuksa veri bozuk kaydedilmiştir. Panelde bozuk, veritabanı arayüzünde doğru görünüyorsa okuma katmanında bir uyumsuzluk vardır. Panelde doğru, dışa aktardığın dosyada bozuksa dışa aktarma katmanı suçludur. Bu üç ayrım, bir dijital ürün satış scriptinde sorunu saatler yerine dakikalar içinde yerelleştirir.

utf8 ile utf8mb4 Arasındaki Üç Baytlık Yalan

Yıllarca kurulum belgelerinde "karakter setini utf8 yap" yazdı ve herkes bunu yaptı. Ancak popüler veritabanı sunucularındaki utf8 adı verilen set, evrensel kodlamanın tamamını değil yalnızca üç bayta sığan bölümünü destekler. Türkçe harfler bu aralığa girer, dolayısıyla yıllarca sorun görünmez. Sorun, müşteri sipariş notuna bir emoji yazdığında veya bazı uzak dil karakterleri içeren bir oyun adı sisteme girdiğinde patlar: o karakter dört bayt gerektirir, sığmaz ve ya kayıt kesilir ya da o noktadan sonrası silinir.

Bu yüzden doğru tercih dört bayt destekli tam evrensel kodlamadır. Yeni kurulan bir e-pin satış yazılımında hiçbir gerekçe bunu atlamayı haklı çıkarmaz. Mevcut bir sistemi dönüştürürken dikkat edilecek tek nokta indeks uzunluklarıdır: karakter başına ayrılan azami bayt arttığı için çok uzun metin kolonlarındaki indeksler sınırı aşabilir. Bunun çözümü indeksi kısaltmak veya kolon uzunluğunu makul bir değere indirmektir; karakter setinden vazgeçmek değil.

Bağlantı Karakter Seti: Veritabanı Doğru, Kapı Yanlış

En çok kafa karıştıran senaryo şudur: veritabanı da tablo da kolon da doğru karakter setinde, ama kayıtlar gene bozuk düşüyor. Sebebi neredeyse her zaman aynıdır: bağlantı karakter seti. Uygulama veritabanına bağlandığında hangi sette konuşacağını bildirmelidir. Bildirmezse sunucunun varsayılanı kullanılır ve bu varsayılan genellikle eski bir Batı Avrupa setidir. Uygulama doğru baytları gönderir, kapıda yanlış set devreye girer ve veri dönüştürülerek bozulmuş hâlde kaydedilir.

Bu tuzağın sinsiliği, kurulumdan aylar sonra ortaya çıkabilmesidir. Sunucu taşındığında, barındırma sağlayıcısı bir güncelleme yaptığında ya da veritabanı bağlantısı için farklı bir sürücüye geçildiğinde varsayılan değişir ve yeni kayıtlar bozulmaya başlar. Eski kayıtlar sağlam kalır, yeni kayıtlar bozuk olur; aynı tabloda iki farklı gerçeklik oluşur. Bu yüzden bağlantı seti asla varsayılana bırakılmamalı, her bağlantıda açıkça bildirilmelidir. Pinova bunu bağlantı katmanında zorunlu bir adım olarak uygular; sunucu varsayılanı ne olursa olsun oturum tek bir sette açılır.

Tedarikçi Dosyaları ve Besleme Servisleri Neden Her Gün Yeni Çöp Üretiyor?

Ürün kataloğunu elle yazmıyorsan, veri sana dışarıdan geliyor: tedarikçinin tablo dosyası, bir besleme adresi veya bir API yanıtı. Bu kaynakların hiçbiri senin karakter seti tercihini bilmek zorunda değildir. Türkiye'de yaygın olarak kullanılan masaüstü tablo programları, dosyayı varsayılan olarak Windows'un yerel setinde kaydeder. Sen o dosyayı evrensel kodlama varsayarak okursan, Türkçe harflerin tamamı bozulur. Üstelik bu bozulma her içe aktarmada tekrarlanır; yani kaynağı düzeltmeden yaptığın her onarım bir sonraki senkronizasyonda silinir.

Doğru yaklaşım içe aktarma katmanına bir karakter seti kapısı koymaktır. Dosya okunmadan önce kodlaması tespit edilir, gerekiyorsa hedef sete dönüştürülür ve ancak sonra işlenir. API yanıtlarında ise yanıt başlığındaki set bildirimine güvenilmeli, bildirim yoksa güvenli bir varsayılan seçilip doğrulama yapılmalıdır. Bir epin yazılım kurulumunda içe aktarma katmanı, kalenin en zayıf duvarıdır ve önce orası sağlamlaştırılmalıdır.

Bozulmuş Veriyi Nasıl Geri Kazanırsın, Nasıl İki Kat Bozarsın?

Onarımın altın kuralı şudur: önce yedek al, sonra tek bir kayıt üzerinde dene, ancak sonra toptan uygula. Çift bozulma tipindeki veriler kurtarılabilir çünkü orijinal baytlar hâlâ orada durur, sadece bir kez fazla yorumlanmışlardır. Bu durumda yapılacak iş, metni bozulmaya yol açan sette geri okuyup doğru sette yeniden yazmaktır. Bu işlem doğru yapıldığında veri harfi harfine geri gelir.

Tehlike, bu işlemi zaten sağlam olan kayıtlara uygulamaktır. Sağlam bir kaydı bozulma varsayarak dönüştürürsen onu gerçekten bozarsın ve ikinci kez geri dönemezsin. Bu yüzden onarım mutlaka seçici olmalıdır: sadece bozulma imzası taşıyan kayıtlar işlenmeli. Karışık bir tabloda en güvenli yol, bozulmuş kayıtları bir desen araması ile listeleyip kümeyi gözle doğruladıktan sonra o kümeye dokunmaktır. Yedek almadan yapılan toptan dönüşüm, bir dijital ürün satış yazılımında geri dönüşü olmayan tek hatadır.

Kalıcı Çözüm: Uçtan Uca Tek Karakter Seti Sözleşmesi

Karakter bozulması, yama yapılacak bir hata değil, ihlal edilmiş bir sözleşmedir. Sözleşme şudur: veri zincirin her durağında aynı karakter setinde konuşur. Bu duraklar veritabanı sunucusu, veritabanı, tablo, kolon, bağlantı oturumu, uygulama iç kodlaması, sayfa başlığı, form gönderimi, e-posta başlığı, dışa aktarma dosyası ve yedek dosyasıdır. On bir durak; biri farklıysa zincir kırılır.

Pratikte bu sözleşmeyi kurmak bir kereliktir ve sonrasında sorun tamamen kaybolur. Kurulum sırasında tüm katmanlar tek sette tanımlanır, bağlantı açıkça bildirilir, içe aktarma kapısına dönüştürücü konur, dışa aktarma dosyalarına doğru başlık yazılır ve yedekler set bilgisi korunacak biçimde alınır. Bundan sonra müşteri adında kesme işareti, ürün adında özel harf veya sipariş notunda emoji olması hiçbir şeyi bozmaz. Bu katmanların nasıl kurulduğunu özellikler bölümünde inceleyebilir, kendi kataloğunla test etmek için paketleri karşılaştırabilirsin.

Karakter bozulması, dijital ürün satan bir işletmede güvenilirliğin en görünür çatlağıdır: müşteri kendi adını bozuk gördüğünde ödeme altyapına da temkinli yaklaşır. Zincirin on bir durağını tek sette konuşturmuş bir sistemin nasıl davrandığını kendi Türkçe kataloğunla denemek istersen canlı demo üzerinden ürün ekleyip dışa aktarabilir, ardından fiyat bölümünden ihtiyacına uygun paketi seçebilirsin.