İki Ad Aynı Görünüp Farklı Karşılaştırılabilir: Unicode Normalization Açıklaması

Two accented lowercase e shapes assembled from small blocks, with one accent joined and the other separate.

Aynı görünen adların neden farklı karşılaştırıldığını, NFC normalleştirmesini ve metin eşleşmesinin kimlik doğrulama sınırlarını öğrenin.

Yapay zekâ ile hazırlanmış temsili editoryal görsel.

İki ad ekranda aynı göründüğü hâlde farklı Unicode kod noktası dizileri içerebilir. Yazılım metinleri karşılaştırırken, müşteri ararken veya içe aktarılan kaydın zaten var olup olmadığını kontrol ederken bu fark önem kazanır. Normalleştirme, belirli eşdeğer dizilere tutarlı temsil sağlar; iki kaydın aynı kişiyi anlattığını kanıtlamaz.

Küçük bir örnek

“é” harfi U+00E9 olarak veya sıradan “e” harfinin ardından U+0301 birleştirici aksan işaretiyle temsil edilebilir. Yazı tipi ikisini aynı gösterebilir; doğrudan metin karşılaştırması ise farklı diziler görür. Unicode Standard Annex #15 bu ilişkiler için normalleştirme biçimlerini tanımlar. NFC kanonik birleştirmeyi, NFD kanonik ayrıştırmayı kullanır. İkisi de aksanları silmek yerine kanonik eşdeğerliği korur.

Ad işleyen sistemde mesele yalnız görüntünün doğru olması değildir. Metni karşılaştıran bütün yolların temsil konusunda anlaşması ve gerektiğinde kişinin verdiği özgün değerin erişilebilir kalması gerekir.

Karşılaştırmanın iki tarafını da normalleştirin

JavaScript bu işlemi String.prototype.normalize() yöntemiyle sunar. Açıkça NFC kullanan örnek şöyledir:

const first = "José";
const second = "José";
const same = first.normalize("NFC") === second.normalize("NFC");

Bu örnekte normalleştirmeden sonra metinler eşit karşılaştırılır. Kuralı yalnız yeni form girişlerine uygulamak, eski aktarımları ve diğer giriş noktalarını tutarsız bırakır. Dönüşümün yerini belirleyin; tarayıcı formunun yanında API, içe aktarma işi ve arama dizinini de kapsayın.

Uyumluluk biçimleri ayrı karar ister

NFKC ve NFKD uyumluluk ilişkilerini de dikkate alır. Görünen metinde korumak isteyebileceğiniz ayrımları değiştirebilir. İsmi daha kapsamlı geliyor diye uyumluluk biçimini seçmeyin. Kalıcı saklama dönüşümünde kullanmadan önce istediğiniz sonucu yazın ve kullanıcılarınız için anlamlı örnekleri test edin.

Görünen ad için kişinin verdiği değeri koruyup ayrıca karşılaştırma değeri tutmak çoğu sistemde uygulanabilir bir seçimdir. Bu bir uygulama tasarımı önerisidir; Unicode standardının veritabanı şemanızı zorunlu olarak böyle belirlediği anlamına gelmez.

Normalleştirme kimlik çözümleme değildir

Yazı sistemleri arasında çeviri yapmaz, bütün yazım farklarını kaldırmaz veya takma adın hesap sahibine ait olduğunu belirlemez. Farklı alfabelerde görsel olarak benzeşen harfleri de güvenilir kimlik belirtecine dönüştürmez. Ad eşleşmesi hesap erişimini, ödemeyi veya kayıt birleştirmeyi etkiliyorsa ek doğrulama gerekir.

İkisinin de adı José olan iki kişiyi düşünün. Metinler tamamen eşleşebilir; yine de iki ayrı kişidirler. Tersine bir kişinin tercih ettiği ad değişirken hesabı aynı kalabilir. Kayıt için kalıcı iç kimlik kullanın; adı kullanıcıya gösterilen özellik olarak ele alın.

Sistemi örneğin ötesinde test edin

Birleşik ve ayrışmış yazımı, gerçekten farklı yazımı ve aynı adı taşıyan ilgisiz kaydı içeren test verisi oluşturun. Aramanın eşdeğer biçimleri bulduğunu, ilgisiz kaydı ise otomatik birleştirmediğini doğrulayın. Dışa aktarın, yeniden içe alın ve karşılaştırmayı tekrarlayın.

Normalleştirme kuralını belgeleyin ve hizmetler arasında tutarlı tutun. Değiştirirseniz türetilmiş dizinleri korunmuş özgün değerlerden yeniden kurun; benzersizlik kısıtı uygulamadan önce olası çakışmaları inceleyin. Amaç öngörülebilir metin işlemektir: eşdeğer kodlamalar tutarlı davranır, insanlar hakkındaki kararlar ise açık kurallarla verilir.

Kaynaklar

İlgili yazılar