Kurumsal Cihazlarda Unicode Uyumluluğunu Yönetme

```html
Bir MacBook'tan José adlı bir kullanıcı tarafından gönderilen bir yardım masası bileti, servis masasına José olarak ulaşır, yönlendirme kuralı departman adıyla eşleştiği için yanlış kuyruğa atanır ve keşif aracısının bildirdiği ana bilgisayar adı aynı aksanlı karakter için farklı bir bayt dizisi kullandığından varlık kaydına bağlanamaz. Üç ayrı hata, tek bir temel neden ve bunların hiçbiri, her cihazın yeni kurulmuş bir en-US Windows kutusu olduğu bir test ortamında görünmez.

Kurumsal cihazlar arasında Unicode uyumluluğu bir çeviri sorunu değildir. Bir bayt sorunudur ve her biri ayrı ayrı doğru yapılandırılmış sistemler arasındaki dikiş yerlerinde ortaya çıkar.

Bir cihaz filosunda kodlamanın gerçekten bozulduğu yer

Unicode 16.0, 154.998 karakter tanımlar. UTF-8, bunların tamamını bir ila dört bayt arasında kodlar ve RFC 3629, aralığı U+10FFFF ile sınırlar. Bu kısım bellidir. Belli olmayan şey, ortamınızdaki herhangi bir uç nokta, aracı, veritabanı sütunu veya barkod okuyucunun 0x7F'nin üzerinde bir baytla karşılaştığında ne yapacağıdır.

Bozulma neredeyse hiçbir zaman bir sistemin ortasında olmaz. Aktarım sırasında olur: bir aracı bir ana bilgisayar adı toplar, bir komut dosyası bir CSV yazar, bir API JSON yayınlar, bir LDAP senkronizasyonu bir görünen ad çeker. Her atlama yeniden kodlayabilir ve yanlış yeniden kodlayan bir atlama genellikle sessizdir.

Ayrıştırmaya değer dört hata sınıfı

Mojibake: bayt düzeyinde uyumsuzluk

Klasik José deseni, UTF-8 baytlarının CP1252 olarak okunmasıdır. İki bayt, C3 A9, teker teker yorumlanır. Bu kurtarılabilir: orijinal baytlar bozulmamıştır, sadece yanlış etiketlenmişlerdir, bu nedenle verileri yeniden kod çözme düzeltir. Acı verici ama üstesinden gelinebilir.

Kayıplı dönüşüm

Daha kötü durum. Latin1_General harmanlamasına sahip bir SQL Server VARCHAR sütunu, Kiril alfabesiyle yazılmış bir isim içeren bir eklemeyi kabul eder ve soru işaretleri saklar. Hata yok, uyarı yok ve orijinal baytlar gitmiştir. Bu, insanların CMDB'lerine güvenmemesine neden olan hata türüdür, çünkü bozulma kalıcıdır ve yazma işlemi başarılı görünmüştür.

Normalleştirme kayması

é karakteri, tek bir kod noktası olan U+00E9 veya bir temel harf artı bir birleştirici vurgu işareti olan U+0065 ve ardından U+0301 olabilir. Her ikisi de aynı şekilde işlenir. Hiçbiri, bir bayt karşılaştırması veya varsayılan bir SQL eşitlik kontrolü altında diğerine eşit değildir. HFS+, macOS dosya adlarında ayrıştırılmış biçimi (NFD) zorunlu kıldı ve APFS normalleştirmeye duyarsız olsa da, herhangi bir noktada bir Mac'ten geçen dosyalar ve yollar hala NFD dizileri taşır. Windows ve çoğu Linux aracı, birleştirilmiş biçim (NFC) üretir. Karşılaştırma mantığı Unicode Standard Annex #15'te tanımlanmıştır ve pratik kural, alımda NFC'ye normalleştirmek ve iki farklı platformdan gelen ham dizeleri asla karşılaştırmamaktır.

Karakterleri değil, baytları sayan depolama sınırları

MySQL'in "utf8" adlı karakter seti utf8mb3'tür: karakter başına üç bayt, yalnızca Temel Çok Dilli Düzlemi kapsar ve başka hiçbir şeyi kapsamaz. Emojiler U+1F300 ve üzerinde yaşar, bu nedenle tek bir emoji içeren bir bilet gövdesi 1366 hatasını tetikler ve eklemeyi geri alır. MySQL 8.0, utf8mb4'ü varsayılan yaptı, ancak bundan önce oluşturulmuş ve yerinde yükseltilmiş birçok üretim şeması var. Java'nın bitişik bir sorunu vardır: String UTF-16'dır, bu nedenle tek bir emoji bir vekil çifttir ve String.length() 2 değerini döndürür; bu, "50 karakter" olarak doğrulayan bir alanın, kullanıcının 48 olarak saydığı metni reddedebileceği anlamına gelir.

Karma bir filoda varsayılan davranış

Aşağıdaki tablo, bir müşteri bozuk cihaz adları bildirdiğinde ve hiç kimse bozulmanın nereden girdiğini söyleyemediğinde kullandığım referanstır.

Sistem	Varsayılan metin işleme	ASCII olmayana ne olur	Pratik sonuç
Windows 10/11 (eski uygulamalar)	ANSI kod sayfası, en-US'de CP1252	0–255 dışındaki her şey kaybolur veya "?" ile değiştirilir	Eski aracılar tarafından toplanan varlık adları bozuk gelir; "Beta: Unicode UTF-8 Kullan" yerel ayar anahtarı düzeltir ancak bazı iş hatası uygulamalarını bozar
PowerShell 5.1	Yönlendirme için UTF-16LE, Out-File için ANSI	Ardışık düzen aşamaları arasında sessiz yeniden kodlama	Komut dosyaları tarafından dışa aktarılan Envanter CSV'leri konsolda iyi görünür ve veritabanında yanlış görünür
PowerShell 7 / pwsh	BOM olmadan UTF-8	Korunur	Toplama komut dosyalarını pwsh'de standartlaştırmak, tüm bir hata sınıfını ortadan kaldırır
macOS (HFS+ mirası)	Dosya adları için NFD	Birleştirilmiş karakterler taban + birleştirici işarete ayrılır	Mac'lerden gelen dosya yolları, aynı görünseler bile Windows'tan gelen yollarla dize eşleşmez
Linux (glibc, LANG=C)	ASCII	0x7F üzerindeki baytlar reddedilir veya türsüz geçirilir	Sertleştirilmiş sunuculardaki Cron tabanlı toplayıcılar, LANG bir UTF-8 yerel ayarına ayarlanana kadar bozuk ana bilgisayar adları yazar
MySQL karakter seti "utf8" (utf8mb3)	Karakter başına maksimum 3 bayt	Emojiler ve bazı CJK uzantıları doğrudan reddedilir	Emoji içeren bilet gönderimleri 1366 hatasıyla başarısız olur ve tüm ekleme geri alınır
SQL Server VARCHAR + UTF-8 olmayan harmanlama	Tek baytlık kod sayfası	Harmanlama sayfası dışındaki karakterler "?" olur	İsimler yazma sırasında bozulur, bu nedenle hiçbir alt akış düzeltmesi onları kurtaramaz
Code 128 barkod okuyucuları	Klavye takozu aracılığıyla ASCII / Latin-1	Latin olmayan varlık etiketleri hiç kodlanamaz	CMDB ne desteklerse desteklesin varlık etiketlemesi ASCII olarak kalmalıdır

İki giriş vurgulanmayı hak ediyor. PowerShell 5.1, Windows ile birlikte gelir ve konsol, Out-File ve yönlendirme operatörleri arasında kodlamayı sessizce değiştirir; bu nedenle etkileşimli olarak çalışan toplama komut dosyaları, zamanlandığında bozuk CSV'ler üretir. Ve hala baskın varlık etiketi sembolojisi olan Code 128, Unicode modu olmayan 8 bitlik bir kodlamadır. QR kodları, ECI modu 26 aracılığıyla UTF-8 taşıyabilir, ancak çoğu klavye takozu tarayıcısı varsayılan olarak ECI 3'ü (ISO-8859-1) kullanır ve gerisini bırakır. Varlık etiketleriniz bir tarayıcıdan geçmek zorundaysa, onları ASCII tutun. Bu bir donanım kısıtlamasıdır, yazılım kısıtlaması değil.

Veritabanının neden genellikle gerçek darboğaz olduğu

Uç nokta yapılandırması görünür olduğu için ilgiyi çeker. Şema, hasarın kalıcı hale geldiği yerdir.

Yaygın bir sıra: CMDB, MySQL 5.7 üzerinde utf8mb3 varsayılanlarıyla oluşturuldu, servis masası daha sonra self-servis bir portala açıldı, kullanıcılar Slack ve Outlook'tan metin yapıştırmaya başladı ve uygulama günlüğünde haftada birkaç düzine oranında ekleme hataları göründü. Çözüm, bir karakter seti dönüşümüdür ve ücretsiz değildir.

Düzeltme	Tipik çaba	Kesinti süresi	Notlar ve ödünleşimler
MySQL utf8mb3'ten utf8mb4'e	Satır sayısına bağlı olarak saatlerden günlere	pt-online-schema-change ile dakikalar, yerinde ALTER ile daha uzun	VARCHAR(255) 765 bayttan 1020 bayta çıkar ve bu, COMPACT satır biçiminde 767 baytlık InnoDB indeks önekini aşar; önce DYNAMIC'e dönüştürün veya indekslenmiş sütunları VARCHAR(191) olarak kısaltın
SQL Server VARCHAR'tan NVARCHAR'a	Günler, çünkü uygulama kodu da onunla değişir	Tablo yeniden oluşturma artı regresyon testi	Latin metni için depolama kabaca iki katına çıkar; veriler çoğunlukla ASCII ise SQL Server 2019 UTF-8 harmanlamaları daha ucuz bir alternatiftir
Yazmada NFC'ye normalleştirme	Düşük, girdi merkezileştirilmişse tek kod yolu	Yok	Yalnızca her alım yolu kapsanıyorsa çalışır; tek bir doğrudan veritabanı yazıcısı karışık formları yeniden sunar
Windows UTF-8 yerel ayar anahtarı	Cihaz başına düşük, testte yüksek	Bir yeniden başlatma	Bazı eski uygulamalar ANSI sayfasını varsayar ve bozulur; filo dağıtımından önce 20 ila 30 makinede pilot uygulama yapın
Klavye takozu tarayıcılarını değiştirme	Haftalar, artı donanım bütçesi	Kademeli	Yalnızca varlık etiketlerinin Latin olmayan metin taşıması gerektiğinde haklı çıkar; genellikle etiketleri ASCII tutmak daha ucuzdur

InnoDB indeks detayı, listedeki diğer her şeyden daha fazla insanı tuzağa düşürür. VARCHAR(255)'i utf8mb3'ten utf8mb4'e dönüştürmek, maksimum anahtar uzunluğunu 765'ten 1020 bayta çıkarır; bu, COMPACT ve REDUNDANT satır biçimlerinde 767 baytlık önek sınırını aşar. ALTER, bir bakım penceresinin ortasında başarısız olur. Değişikliği planlamadan önce satır biçimini ve indeks genişliklerini kontrol edin, değişiklik sırasında değil.

Bir şeyi değiştirmeden önce denetim

Yerel ayarlara veya harmanlamalara dokunmadan önce, verilerde gerçekte ne olduğunu bulun. Beş kontrol çoğu ortamı kapsar:

• CMDB'de é, ü, ’ ve  değişmez dizilerini içeren kayıtları sorgulayın. Her biri belirli bir yanlış kod çözmenin imzasıdır ve bunları saymak size hangi ardışık düzenin hatalı olduğunu söyler.
• Her ana bilgisayar adı ve kullanıcı adı alanının NFC ve NFD biçimlerini karşılaştırın. Sıfır olmayan bir fark, en az bir toplayıcının ayrıştırılmış metin yazdığı anlamına gelir.
• Yalnızca veritabanı varsayılanını değil, her sütunun karakter setini ve harmanlamasını listeleyin. Yıllarca süren geçici tablo oluşturmadan sonra tek bir şema içinde karışık harmanlamalar yaygındır.
• Gelen e-posta bağlayıcınızın, RFC 2047 ile kodlanmamış başlıklar için hangi kodlamayı varsaydığını kontrol edin, çünkü şaşırtıcı sayıda biletleme entegrasyonu tahmin eder.
• İşletim sistemi ailesi ve yerel ayar başına en az bir cihazdan keşif çıktısını örnekleyin; buna yıllar önce kurulmuş ve hiç güncellenmemiş aracıların bulunduğu hava boşluklu veya şirket içi segmentler dahildir.

Sonuncusu göründüğünden daha önemlidir. Düzenlenmiş ortamlar, hastaneler, belediye ağları ve özellikle havacılık, daha uzun yenileme döngülerinde daha eski aracılar çalıştırma eğilimindedir; bu, CP1252 dönemi varsayımlarının tam olarak hayatta kaldığı yerdir.

Varlık ve hizmet yönetimi araçlarının uyduğu yer

Kodlama doğruluğu, tüm zincirin bir özelliğidir: keşif aracısı, aktarım, veritabanı, kullanıcı arayüzü, dışa aktarma. Dört satıcıdan bir araya getirilen bir yığın, size bunu yanlış anlamak için dört yer ve adı kimin katmanının bozduğu hakkında tartışmak için dört destek kuyruğu verir.

Bu, entegre bir platform için pratik argümandır. Ağ envanteri, varlık yönetimi ve servis masası tek bir şemayı ve tek bir harmanlamayı paylaştığında, keşif ile keşfedilen makineye atıfta bulunan bilet arasında yeniden kodlama atlaması olmaz.

Keşif ve servis masasını tek bir şemada birleştiren ekipler için, Alloy Software, envanter, varlık kayıtları ve biletlerin entegrasyonlar aracılığıyla birbirine dikilmek yerine aynı veritabanında bulunduğu orta pazar seçeneklerinden biridir; AlloyScan, eski şirket içi Alloy Discovery ürününün doldurduğu bulut tarafı keşif rolünü kapsar. Herhangi bir platformu değerlendirirken ilgili soru dardır: aracı UTF-8 bildiriyor mu, veritabanı utf8mb4 veya NVARCHAR depoluyor mu ve dışa aktarma, hedef Windows'ta Excel olduğunda bir BOM yazıyor mu?

Bu son noktayı bir deneme sırasında test etmeye değer. Windows'ta Excel, UTF-8 CSV'yi bayt sırası işareti olmadan CP1252 olarak açar; bu, temiz bir dışa aktarmayı çift tıklayan herkes için mojibake'ye dönüştürür. BOM yazan bir araç, dışa aktarma başına bir destek biletinden kaçınır; her zaman yazan bir araç, bunun yerine naif Unix ayrıştırıcılarını bozar. Hangi davranışı elde ettiğinizi ve yapılandırılabilir olup olmadığını kontrol edin.

Kimsenin bütçe ayırmadığı güvenlik açısı

Kurumsal cihazlar arasında Unicode uyumluluğu aynı zamanda bir saldırı yüzeyidir. Kiril а (U+0430) ve Latin a (U+0061) çoğu yazı tipinde görsel olarak aynıdır. Meşru olandan tek bir homoglifle farklılık gösteren bir ana bilgisayar adı veya hizmet hesabı, insan incelemesinden geçecek ve ikisini ayrı olarak ele alan bir veritabanında çakışmayacaktır. Alan adlarına yönelik IDN homograf saldırıları iyi bilinen sürümdür; gerçek bir varlık kaydını gölgeleyen haydut bir varlık kaydının olduğu dahili sürüm çok daha az ilgi görür.

Karşı önlem, alımda karma komut dosyası algılamadır. Karakterleri birden fazla Unicode komut dosyası bloğuna yayılan herhangi bir ana bilgisayar adını, kullanıcı adını veya varlık etiketini işaretleyin; kaydın meşru olarak komut dosyalarını karıştıran bir yerel ayara ait olmadığı sürece. Ucuz bir kontroldür ve hem saldırıları hem de dürüst kopyala-yapıştır kazalarını yakalar.

Önce ne düzeltilmeli

Sıra önemlidir, çünkü bazı düzeltmeler diğerlerini gereksiz kılar. Depolama katmanından başlayın: verileri tutamayan bir veritabanı, her yukarı akış düzeltmesini kozmetik yapar. Ardından yazmada normalleştirin, çünkü normalleştirme kayması bir birleştirme başarısız olana kadar görünmezdir. Ardından toplama komut dosyalarını standartlaştırın, PowerShell 5.1'deki her şeyi her dosya işleminde açık bir -Encoding utf8 ile pwsh'ye taşıyın. Uç nokta yerel ayar değişiklikleri en son gelir ve yalnızca eski bir uygulamanın gerçekten ANSI sayfasını gerektirdiği durumlarda gelir.

Windows UTF-8 yerel ayar seçeneğiyle ilgili bir uyarı: Windows 11'de hala beta olarak etiketlenmiştir ve ANSI Win32 API'lerini sabit kodlanmış kod sayfası varsayımlarıyla çağıran uygulamaları bozar. Herhangi bir filo çapında dağıtımdan önce, departmanlar arasında 20 ila 30 makinede tam bir ay boyunca pilot uygulama yapın ve bir geri alma yolu bulundurun, çünkü hata türü, metni tuhaf şekilde işleyen bir uygulama değil, başlamayacak bir uygulamadır.

Ve bazı verilerin kurtarılamaz olduğunu kabul edin. Yıllar önce tek baytlık bir sütun aracılığıyla yazılan satırlar, eskiden adların olduğu yerde soru işaretleri içerir. Hiçbir geçiş onları geri getirmez; kaynak cihazdan yeniden toplanmaları veya elle düzeltilmeleri gerekir.
```