UTF-16 zararlı olarak kabul edilmeli mi?

Muhtemelen tartışmalı bir sorunun ne olduğunu soracağım: “En popüler kodlamalardan biri olan UTF-16 zararlı olarak kabul edilmeli mi?”

Bu soruyu neden soruyorum?

Kaç programcı UTF-16'nın gerçekten değişken uzunluklu bir kodlama olduğunun farkında? Bununla, vekil çiftler olarak temsil edilen, birden fazla element alan kod noktaları olduğunu kastediyorum.

Biliyorum; Java, String, C # 's String, Win32 API, Qt GUI kütüphaneleri, ICU Unicode kütüphanesi, vb. gibi pek çok uygulama, çerçeve ve API kullanılır. BMP dışındaki karakterlerin listesi (iki UTF-16 öğesi kullanılarak kodlanması gereken karakterler).

Örneğin, şu karakterlerden birini düzenlemeyi deneyin:

• 𝄞 ( U + 1D11E ) MÜZİKSEL SEMBOL G CLEF
• 𝕥 ( U + 1D565 ) MATEMATİKSEL ÇİFT KİŞİLİK KÜÇÜK T
• 𝟶 ( U + 1D7F6 ) MATEMATİKSEL MONOSPACE DIGIT ZERO
• 𠂊 ( U + 2008A ) Han Karakteri

Yüklediğiniz yazı tipine bağlı olarak bazılarını kaçırabilirsiniz. Bu karakterlerin tümü BMP'nin (Temel Çok Dilli Düzlem) dışındadır. Bu karakterleri göremiyorsanız, onlara Unicode Karakter referansında bakmayı da deneyebilirsiniz .

Örneğin, Windows'ta bu karakterleri içeren dosya adları oluşturmaya çalışın; UTF-16 kullanan farklı uygulamalarda nasıl davrandıklarını görmek için bu karakterleri "geri al" ile silmeyi deneyin. Bazı testler yaptım ve sonuçlar oldukça kötü:

• Opera’nın düzenleme konusunda problemi var (geri silme işleminde gerekli 2 baskıyı silin)
• Not defteri onlarla doğru şekilde baş edemez (silme işlemi için gerekli 2 basışı silin)
• Pencere diyaloglarında bozuk dosya isimleri bozuk (geri silme işleminde 2 basma gerekli)
• Tüm QT3 uygulamaları onlarla başa çıkamaz - bir sembol yerine iki boş kareyi gösterin .
• Python u'X'!=unicode('X','utf-16'), X BMP dışında bir karakterde olduğunda doğrudan bazı platformlarda kullanıldığında bu karakterleri yanlış kodlar .
• Python 2.5 unicodedata, python UTF-16 Unicode dizeleriyle derlendiğinde bu tür karakterlerde özellik alamaz.
• StackOverflow, doğrudan Unicode karakterleri olarak düzenlenmişse bu karakterleri metinden kaldırıyor gibi görünmektedir (bu karakterler HTML Unicode çıkışları kullanılarak gösterilmiştir).
• WinForms TextBox, MaxLength ile sınırlı olduğunda geçersiz dize oluşturabilir .

UTF-16 kullanan birçok uygulamada bu tür hataların bulunması son derece kolaydır.

Öyleyse ... UTF-16'nın zararlı olarak kabul edilmesi gerektiğini düşünüyor musunuz?

Bu eski bir cevap. En son güncellemeler için UTF-8 Her Yerde
bölümüne bakınız .

Görüş: Evet, UTF-16 zararlı olarak kabul edilmelidir . Varlığının nedeni, bir süre önce, Widechar'ın şu anda UCS-4'ün olduğu gibi olacağı yönündeki yanlış bir inancı olduğu içindi.

UTF-8'in “merkez-merkezciliği” ne rağmen, metin için tek yararlı kodlama düşünülmelidir. Program kaynak kodlarının, web sayfalarının ve XML dosyalarının, işletim sistemi dosya adlarının ve diğer bilgisayardan bilgisayara metin arayüzlerinin asla bulunmaması gerektiği iddia edilebilir. Ancak yaptıklarında, metin yalnızca insan okuyucular için değildir.

Öte yandan, UTF-8 ek yükü, önemli avantajlara sahipken ödenmesi gereken küçük bir fiyattır. Dizeleri geçiren habersiz kodla uyumluluk gibi avantajlar char*. Bu harika bir şey. UTF-16’da SHORTER olan UTF-8’de olduğundan daha az kullanışlı karakter var.

Diğer tüm kodlamaların sonunda öleceğine inanıyorum. Bu, MS-Windows, Java, ICU, python'un favorileri olarak kullanmayı bırakmasını içerir. Uzun araştırma ve tartışmaların ardından şirketimdeki geliştirme sözleşmeleri, OS API çağrıları dışında her yerde UTF-16 kullanılmasını yasakladı ve bu, uygulamalarımızdaki performansın önemine ve Windows kullanmamıza rağmen. Dönüşüm işlevleri, her zaman varsayılan UTF8'leri std::string, Windows'un kendisinin düzgün bir şekilde desteklemediği yerel UTF-16'ya dönüştürmek için geliştirilmiştir .

" İhtiyaç duyulan şeyi kullanın " diyenlere şunu söylüyorum: aynı kodlamayı her yerde kullanmanın çok büyük bir avantajı var, aksi halde yapmak için yeterli neden göremiyorum. Özellikle, wchar_tC ++ 'a eklemenin bir hata olduğunu ve Unicode' un C ++ 0x 'a eklendiğini düşünüyorum . STL uygulamalarından talep edilmesi gereken, ancak her std::stringveya char*parametrenin unicode uyumlu olarak kabul edilmesi gerektiğidir.

Ben de " ne istersen onu kullan " yaklaşımına karşıyım . Böyle bir özgürlük için sebep göremiyorum. Metin konusunda yeterince karışıklık var ve bu kırık yazılımlar ortaya çıkıyor. Yukarıda belirtildiği gibi, programcıların nihayet UTF-8'deki fikir birliğine varması gerektiğine ikna oldum. (İyi konuşmayan bir ülkeden geliyorum ve Windows'ta büyüdüm, bu yüzden en son UTF-16'ya dini gerekçelerle saldırması bekleniyor.)

Windows'ta metin nasıl yaptığım ve derleme zamanı denetimli unicode doğruluğu, kullanım kolaylığı ve kodun daha iyi çoklu platform özelliği için herkese önerdiklerim hakkında daha fazla bilgi paylaşmak istiyorum. Öneri, pencerelerde Unicode kullanmanın doğru yolu olarak genellikle önerilenlerden önemli ölçüde farklıdır. Ancak, bu önerilerin derinlemesine araştırılması aynı sonucu verdi. Yani işte gidiyor:

• UTF-16'yı kabul eden API'lerin bitişik noktalarından başka bir yerde kullanmayın wchar_tveya kullanmayın std::wstring.
• Kullanmayın _T("")veya L""UTF-16 değişmezleri (Bunlar IMO’nun UTF-16 itirazının bir parçası olarak standart dışı bırakılması gerekir).
• Tipleri, fonksiyonları ya da duyarlı onların türevleri kullanmayınız _UNICODEgibi sabit, LPTSTRya da CreateWindow().
• Yine de, _UNICODEher zaman tanımlanmış, char*dizelerin WinAPI'ye iletilmesinden kaçınmak için sessizce derlenmeden
• std::stringsve char*programın herhangi bir yerinde UTF-8 olarak kabul edilir (aksi belirtilmezse)
• Tüm dizelerim, std::stringchar * veya string değişmezine geçebildiğiniz halde convert(const std::string &).

• sadece widechars ( LPWSTR) işlevini kullanan Win32 işlevlerini kullanın . Asla kabul edenler LPTSTRveya LPSTR. Parametreleri bu şekilde geçirin:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (Politika aşağıdaki dönüşüm işlevlerini kullanır.)

• MFC dizeleriyle:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Windows'ta dosya, dosya adı ve fstream ile çalışmak:

  • Argümanları asla aileye iletmeyin std::stringveya vermeyin . MSVC STL UTF-8 argümanlarını desteklemez, ancak aşağıdaki gibi kullanılması gereken standart olmayan bir uzantıya sahiptir:const char*fstream

  • std::stringArgümanları std::wstringşununla dönüştür Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    MSVC'nin tutumu fstreamdeğiştiğinde , el ile kaldırmamız gerekir .

  • Bu kod çok platformlu değildir ve gelecekte manuel olarak değiştirilmesi gerekebilir
  • Daha fstreamfazla bilgi için bkz. Unicode araştırma / tartışma durumu 4215
  • Asla UTF8 olmayan içeriğe sahip metin çıktı dosyaları üretme
  • fopen()RAII / OOD nedenleriyle kullanmaktan kaçının . Gerekirse, _wfopen()yukarıdaki ve WinAPI kurallarını kullanın .

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

Unicode kod noktaları karakter değildir! Bazen onlar bile glif değildir (görsel formlar).

Bazı örnekler:

• "Ⅲ" gibi Romen rakamıyla kod noktaları. ("İii" gibi görünen tek bir karakter.)
• Tek bir birleşik karakter "\ u00e1" veya bir karakterle ayrılmış ve "diacritic" \ u0061 \ u0301 "karakterlerinden oluşan" á "gibi aksanlı karakterler.
• Yunanca küçük harf sigma gibi karakterlerin ortası ("σ") ve sonu ("ς") için farklı biçimlerde olan ancak arama için eşanlamlı olması gereken karakterler.
• İçeriğe bağlı olarak ve anlamsal arama için göz ardı edilen, görsel olarak görüntülenebilecek veya gösterilemeyen Unicode isteğe bağlı tire U + 00AD.

Unicode düzenlemeyi doğru yapmanın tek yolu, bir uzman tarafından yazılmış bir kütüphane kullanmak veya bir uzman olmak ve kendiniz yazmaktır. Eğer sadece kod noktaları sayıyorsanız, günah halinde yaşıyorsunuz demektir.

Hangi Unicode Dönüşüm Formunun (UTF) ne kullanılacağına dair basit bir kural vardır: - depolama ve iletişim için utf-8 - veri işleme için utf-16 - kullandığınız platform API'sının çoğu ise utf-32 ile gidebilirsiniz utf-32 (UNIX dünyasında yaygın).

Günümüzde çoğu sistem utf-16'yı kullanır (Windows, Mac OS, Java, .NET, ICU, Qt). Ayrıca bu belgeye bakın: http://unicode.org/notes/tn12/

"Zararlı olarak UTF-16" ya dönersek diyeceğim: kesinlikle hayır.

Vekillerden korkan insanlar (Unicode'u değişken uzunluktaki bir kodlamaya dönüştürdüklerini düşünerek), karakterlerle eşleştirmeyi Unicode kod noktası haline getiren diğer (çok daha büyük) karmaşıklıkları anlamıyorlar: karakterleri, bitişik harfleri, varyasyon seçicileri birleştirme , kontrol karakterleri vb.

Sadece bu diziyi burada okuyun http://www.siao2.com/2009/06/29/9800913.aspx ve UTF-16'nın nasıl kolay bir problem haline geldiğini görün.

Evet kesinlikle.

Neden? Egzersiz kodu ile ilgili olmalı .

Bu kod noktası kullanım istatistiklerine Tom Christiansen'in büyük bir kurumunda bakarsanız, trans-8bit BMP kod noktalarının, BMP olmayan kod noktalarından daha büyükse birkaç sıra kullanıldığını göreceksiniz:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

TDD dictum'unu ele al: "Test edilmemiş kod bozuk kod", ve "unceccised kod bozuk kod" olarak tekrar yazın ve programcıların BMP olmayan kod noktaları ile ne sıklıkla uğraşmaları gerektiğini düşünün.

UTF-16 ile değişken genişlikteki bir kodlama olarak uğraşmamakla ilgili hataların UTF-8'deki eşdeğer hatalardan fark edilmemesi çok daha muhtemeldir . Bazı programlama dilleri UCS-2 yerine UTF-16 olarak vermeyi garanti etmemektedir ve bazı yüksek seviye programlama dilleri kod noktaları yerine kod birimlerine erişim sunar (C kodunun size erişim izni vermesi gerekir) wchar_tbazı platformların ne yapabileceğinden bağımsız olarak kullanırsanız kod noktaları .

UTF-16'yı düşünmenin zararlı olarak kabul edilebileceğini düşünüyorum, daha büyük bir unicode anlayışı kazanmanız gerektiğini söylüyor .

Sübjektif bir soru hakkında fikrimi sunduğum için oy kullanmadığım için, detaylı çalışayım. UTF-16 hakkında sizi rahatsız eden tam olarak nedir? UTF-8’de her şeyin kodlanmış olmasını tercih eder misiniz? UTF-7? Veya nasıl UCS-4? Tabii ki bazı uygulamalar, sürekli karakter kodunu işlemek için tasarlanmamıştır - ancak uluslararası sınırlar arasındaki iletişim için, özellikle günümüzün küresel bilgi alanında gereklidir.

Fakat gerçekten, eğer UTF-16'nın zararlı olarak algılanması gerektiğine inanıyorsanız, kafa karıştırıcı veya yanlış bir şekilde uygulanabilir (unicode kesinlikle olabilir), o zaman hangi karakter kodlaması yönteminin zararsız olduğu düşünülür?

EDIT: Açıklığa kavuşturmak için: Neden bir standardın uygun olmayan uygulamalarını standardın kalitesinin bir yansıması olarak düşünün? Başkalarının daha sonra belirttiği gibi, sadece bir uygulama uygun olmayan bir alet kullandığı için, aletin kendisinin kusurlu olduğu anlamına gelmez. Öyle olsaydı, muhtemelen "var anahtar kelimesi zararlı olarak kabul edildi" ya da "zararlı olarak kabul edilir" gibi şeyler söyleyebiliriz. Sanırım bu soru, standardın niteliğini ve niteliğini, birçok programcının onu doğru şekilde uygulama ve kullanmadaki zorluklarla karıştırdığını, bunun da unicode'un kendisinin nasıl çalıştığını anlama konusundaki yetersizliklerinden kaynaklandığını düşünüyorum.

Utf-16 kodlamasında yanlış bir şey yok. Ancak, 16 bit birimleri karakter olarak gören diller muhtemelen kötü tasarlanmış sayılmalıdır. Her charzaman bir karakteri temsil etmeyen ' ' adlı bir türün olması kafa karıştırıcıdır. Çoğu geliştirici bir karakter tipinin bir kod noktasını veya karakteri göstermesini bekleyeceğinden, çoğu kod BMP'nin karakterlerine maruz kaldığında büyük olasılıkla kırılacaktır.

Ancak utf-32 kullanarak bile her 32 bit kod noktasının her zaman bir karakteri temsil edeceği anlamına gelmediğine dikkat edin. Karakterleri birleştirme nedeniyle gerçek bir karakter birkaç kod noktasından oluşabilir. Unicode asla önemsiz değildir.

BTW. Muhtemelen Utf-8 ile beslenen karakterlerin 8 bit olmasını bekleyen platform ve uygulamalara sahip aynı hata sınıfı vardır.

Kişisel tercihim her zaman UTF-8'i kullanmak. Neredeyse her şey için Linux'ta standart. Birçok eski uygulamayla geriye dönük olarak uyumludur. Latince olmayan karakterler için kullanılan diğer UTF formatları için kullanılan fazladan boşluk açısından çok az ek yük vardır ve latin karakterler için boşlukta önemli bir tasarruf vardır. İnternette latin dilleri yüce hüküm sürüyor ve sanırım öngörülebilecek gelecek için olacaklarını düşünüyorum. Orijinal gönderideki ana argümanlardan birine değinmek için: hemen hemen her programcı UTF-8'in bazen çok baytlık karakterleri olacağının farkındadır. Herkes bununla doğru bir şekilde ilgilenmiyor, ancak genellikle UTF-16 için söylenenden daha fazla olanın farkındalar. Ancak, elbette, başvurunuz için en uygun olanı seçmeniz gerekir. Bu yüzden ilk etapta birden fazla var.

Eh, sabit boyutlu semboller kullanan bir kodlama var. UTF-32'yi kesinlikle kastediyorum. Ancak her sembol için 4 bayt çok fazla boşa harcanmıştır, neden günlük durumlarda kullanalım?

Aklıma gelen sorunların çoğu, bazı yazılımların Unicode standardının gerisine düştüğü, ancak durumu düzeltmek için hızlı olmadığı gerçeğinden kaynaklanmaktadır. Opera, Windows, Python, Qt - Hepsi UTF-16 yaygın olarak bilinmeden ve hatta ortaya çıkmadan önce ortaya çıktı. Bununla birlikte, Opera, Windows Gezgini ve Not Defteri'nde BMP dışındaki karakterlerde artık sorun olmadığını (en azından bilgisayarımda) doğrulayabiliyorum. Fakat yine de, programlar vekil çiftleri tanımıyorsa, UTF-16'yı kullanmazlar. Bu tür programlarla başa çıkmaktan kaynaklanan problemler ne olursa olsun, UTF-16'nın kendisi ile ilgisi yoktur.

Ancak, eski BMP destekli yazılım problemlerinin biraz abartıldığını düşünüyorum. BMP dışındaki karakterlere yalnızca çok özel durumlarda ve alanlarda rastlanır. Göre Unicode resmi SSS , "Hatta Doğu Asya metinde, vekil çiftleri insidansı ortalama olarak tüm metin depolama% 1'den de az olmalıdır". Tabii ki, BMP dışındaki karakterler ihmal edilmemelidir, çünkü bir program Unicode uyumlu değilse, ancak çoğu program bu karakterleri içeren metinlerle çalışmak için tasarlanmamıştır. Bu yüzden eğer desteklemiyorlarsa, tatsız, ama bir felaket değil.

Şimdi alternatifi düşünelim. UTF-16 olmasaydı, ASCII olmayan metinler için uygun bir kodlamaya sahip olmazdık ve UCS-2 için oluşturulan tüm yazılımların Unicode uyumlu kalması için tamamen yeniden tasarlanması gerekiyordu. İkincisi büyük olasılıkla Unicode'un benimsenmesini yavaşlatır. Ayrıca, UTC-8'in ASCII ile ilgili olarak yaptığı gibi UCS-2'deki metin ile uyumluluğunu koruyamazdık.

Şimdi, tüm eski sorunları bir kenara koyarsak, kodlamanın kendisine karşı çıkan argümanlar nelerdir? Bugünlerde geliştiricilerin UTF-16'nın değişken uzunluk olduğunu bilmediğinden şüpheliyim, her yerde Wikipedia'ya yazılan her yer var. Birisi karmaşıklığı muhtemel bir sorun olarak belirttiyse, UTF-16'nın ayrıştırılması UTF-8'den daha az zordur. Ayrıca, sadece UTF-16'da dize uzunluğunu belirlemekle uğraşmanın kolay olduğunu düşünmek yanlıştır. UTF-8 veya UTF-32 kullanıyorsanız, bir Unicode kod noktasının mutlaka bir karakter anlamına gelmediğinin farkında olmalısınız. Bunun dışında kodlamaya karşı önemli bir şey olduğunu sanmıyorum.

Bu nedenle kodlamanın kendisinin zararlı olarak kabul edilmesi gerektiğini düşünmüyorum. UTF-16 basitlik ve kompaktlık arasında bir uzlaşmadır ve ihtiyaç duyulan yerde gerekli olanı kullanmanın bir zararı yoktur . Bazı durumlarda ASCII ile uyumlu kalmanız gerekir ve UTF-8'e ihtiyacınız vardır, bazı durumlarda Han ideografları ile çalışmak ve UTF-16'yı kullanarak yer kazanmak istiyorsanız, bazı durumlarda sabit karakterleri gösteren genel karakterlerin gösterimini yapmanız gerekir. uzunluk kodlaması. Daha uygun olanı kullanın, doğru şekilde yapın.

Özellikle Doğu Asya dillerinde yıllar süren Windows uluslararasılaştırılması beni mahvedebilir, ancak dizelerin program içi dahili gösterimi için UTF-16'ya, düz metin benzeri belgelerin ağ veya dosya depolaması için UTF-8'e dayanıyorum. UTF-16 genellikle Windows'ta daha hızlı işlenebilir, bu yüzden Windows'ta UTF-16 kullanmanın temel yararı budur.

UTF-16'ya sıçraması, uluslararası metinleri işleyen ortalama ürünlerin yeterliliğini önemli ölçüde artırdı. Vekil çiftlerin göz önünde bulundurulması gereken (sadece silmeler, sokmalar ve çizgi kırma) ve ortalama durum çoğunlukla düz geçiş olduğunda, sadece birkaç dar durum söz konusudur. Ve JIS varyantları gibi daha önceki kodlamaların aksine, UTF-16 vekil çiftleri çok dar bir aralıkta sınırlar, böylece kontrol gerçekten hızlıdır ve ileri ve geri çalışır.

Verilmiş, kabaca doğru kodlanmış UTF-8'de de hızlı. Ancak, vekil çiftleri iki UTF-8 dizisi olarak yanlış kodlayan birçok kırık UTF-8 uygulaması da var. Yani UTF-8 de kurtuluş garantisi vermez.

IE, vekilleri 2000’den bu yana oldukça iyi bir şekilde bir araya getirir, tipik olarak UTF-8 sayfalarından dahili bir UTF-16 temsiline dönüştürülmesine rağmen; Firefox’un da haklı olduğuna eminim, bu yüzden Opera’nın ne yaptığını umursamıyorum.

UTF-32 (aka UCS4) çoğu uygulama için anlamsızdır, çünkü çok fazla alan gerektirir, bu yüzden hemen hemen bir nonsterter.

UTF-8 kesinlikle, muhtemelen yüksek performanslı rastgele erişime ihtiyaç duyan algoritmalarda dahili kullanım için UTF-32 eşliğinde kullanılabilecek bir yoldur (ancak karakterleri birleştirmeyi yok sayar).

Hem UTF-16 hem de UTF-32 (ve LE / BE değişkenlerinin yanı sıra) endiyan sorunlarından muzdariptir, bu nedenle asla harici olarak kullanılmamalıdırlar.

UTF-16? kesinlikle zararlı. Burada sadece tuz tanem var, ancak bir programdaki metin için kabul edilebilir üç kodlama var:

• ASCII: Daha iyi bir şey sağlayamayan düşük seviyeli şeyler (örneğin: mikrodenetleyiciler) ile çalışırken
• UTF8: dosyalar gibi sabit genişlikte bir ortamda depolama

• tamsayı kod noktaları ("CP"?): programlama diliniz ve platformunuz için en uygun tam sayı dizisidir (düşük dirençler sınırında ASCII'ye dönüşür). Eski bilgisayarlarda int32 ve 64 bit adreslemeli bir şeyde int64 olmalıdır.

• Açıkçası, eski koda olan arayüzler, eski kodun doğru çalışmasını sağlamak için gereken kodlamayı kullanır.

Unicode , 0x10FFFF (1.114.112 kodlarına) kadar kod noktalarını tanımlar, çok dilli bir ortamda çalışan dizeler / dosya adları vb. İle ilgili tüm uygulamaların bu sorunu çözmesi gerekir.

Utf-16 : yalnızca 1.112.064 kodlarını kapsar. Unicode'un sonunda olanlar 15-16 uçaklarından olmasına rağmen (Özel Kullanım Alanı). Utf-16 kavramının kırılması dışında gelecekte daha fazla büyüyemez .

Utf-8 : teorik olarak 2,216,757,376 kodları kapsar. Unicode kodlarının mevcut aralığı, maksimum 4 byte dizisi ile temsil edilebilir. O ile zarar vermez bayt sırası bu ASCII ile "uyumlu" olduğu, sorunun.

Utf-32 : teorik olarak 2 ^ 32 = 4,294,967,296 kodları kapsar. Şu anda kodlanmış değişken uzunluklu değildir ve muhtemelen gelecekte olmayacak.

Bu gerçekler açıklayıcıdır. Utf-16'nın genel kullanımının savunuculuğunu anlamıyorum . Değişken uzunluklu kodludur (endeksle erişilemez), şu anda bile tüm Unicode aralığını kapsama problemi vardır , bayt sırası ele alınmalıdır, vb. diğer yerler. Çok platformlu kod yazarken Utf-8'i doğal olarak kullanmak ve dönüşümleri yalnızca son noktalarda platforma bağımlı bir şekilde (önceden önerildiği şekilde) yapmak daha iyi olsa da. Dizine göre doğrudan erişim gerekli olduğunda ve hafıza sorun olmadığında, Utf-32 kullanılmalıdır.

Asıl sorun, Windows Unicode = Utf-16 ile ilgili birçok programcının değişken uzunluk kodlu olduğunu bile bilmemesi veya görmezden gelmesidir .

Genellikle * nix platformunda olduğu gibi oldukça iyidir, Utf-8 kodlu geniş c dizeleri (wchar_t *) Utf-32 olarak yorumlanır .

Bunu listeye ekle:

Sunulan senaryo basittir (burada sunacağımdan daha da basit!): 1. WinForms TextBox bir formda boş duruyor. 20'ye ayarlanmış bir MaxLength var .

2.Kullanıcı TextBox içine yazar veya belki de metni yapıştırır.

3. Metin Kutusuna ne yazdığınız veya yapıştırdığınızın hiçbir önemi yoktur, 20 ile sınırlandırılırsınız, ancak sempatik olarak 20'nin üzerindeki metinde bip sesi çıkarır (burada YMMV; bana bu etkiyi verecek şekilde ses düzenimi değiştirdim!).

4.Küçük metin paketi daha sonra heyecan verici bir maceraya başlamak için başka bir yere gönderilir.

Şimdi bu kolay bir senaryodur ve herkes bunu boş zamanlarında yazabilir. Kendimi WinForms kullanarak birden çok programlama dilinde yazdım çünkü sıkıldım ve daha önce hiç denemedim. Ve birden fazla gerçek dilde metin yazarken, çünkü bu yoldan kabloluyum ve çılgınca evrendeki herkesten daha fazla klavye düzenine sahibim.

Sıkıntıyı hafifletmek için Magic Carpet Ride adını bile verdim .

Bu işe yaramadı, buna değerdi.

Bunun yerine, şu 20 karakteri Magic Carpet Ride formuma girdim :

0123401234012340123 𠀀

Ahh.

Bu son karakter, Unicode'un ilk Uzatma B ideografı olan U + 20000'dir (yani, U + d840 U + dc00, yakın arkadaşlarına, olduğu gibi, deforme edilmekten utanmadığı)

Ve şimdi bir top oyunumuz var.

Çünkü TextBox.MaxLength hakkında konuştuğunda

Metin kutusuna manuel olarak girilebilecek maksimum karakter sayısını alır veya ayarlar.

gerçekte ne demek

Metin kutusuna manuel olarak girilebilecek maksimum UTF-16 LE kod birimi sayısını alır veya ayarlar ve dilbilgisi karakterine sahip, sadece birinin takıntılı olduğu bir dilbilimsel karakter anlayışıyla şirin oyunları oynamaya çalışan herhangi bir dizeden acımasızca keser Kaplan arkadaşının rahatsız edici bulacağını söyledi (daha fazla bilgi alması gerekiyor!).

Dokümanı güncellemeye çalışacağım ve göreceğim
... UCS-2 - UTF-16 serilerini hatırlayan normal okuyucular , TextBox.MaxLength'ın basit kavramına olan mutsuzluğumu ve en azından bu durumda nasıl ele almaları gerektiğini not edecek Draconian davranışının yasadışı bir sıra oluşturduğu durumlarda, .Net Framework’ün diğer bölümlerinin

• System.Text.EncoderFallbackException: Dizin 0'daki Unicode karakter \ uD850, belirtilen kod sayfasına çevrilemedi. *

istisna, bu dizgiyi .NET Framework'ün herhangi bir yerine iletirseniz (meslektaşım Dan Thompson'ın yaptığı gibi).

Şimdi tamam, belki de tam UCS-2 - UTF-16 serisi pek çok kişinin ulaşamayacağı bir yerde.
Ancak TextBox.Text’in bir System.String üretmeyeceğini beklemek mantıklı değil mi? Bu başka bir .Net Framework parçasının atmasına neden olmaz mı? Demek istediğim, kontrolde bir olay şeklinde, size daha akıllı kesimi kolayca ekleyebileceğiniz bir kısaltmayı söyleyen bir şans olması gibi değil - kontrolün kendisinin yapmasının sakıncalı olmadığını doğrulamak. Beklenmedik istisnaların bir uygulamayı kaba bir hizmet reddi olarak feshetmesine yol açabilecek şekilde sınıflandırabilirseniz, bu serseri kontrolünün güvenlik sorunlarına yol açabilecek bir güvenlik sözleşmesini ihlal ettiğini söyleyeceğim kadar ileri giderim. Neden herhangi bir WinForms süreci ya da yöntemi ya da algoritması ya da tekniği geçersiz sonuçlar üretmeli?

Kaynak: Michael S. Kaplan MSDN Blog

UTF-16'nın zararlı olduğunu söyleyemem. Zarif değil, ancak GB18030'un GB2312 ve UTF-8'in de ASCII ile yaptığı gibi UCS-2 ile geriye dönük uyumluluk amacına hizmet ediyor.

Ancak, Microsoft ve Sun'ın 16 bitlik karakterlerin etrafında büyük API'ler oluşturmasından sonra, Unicode'un yapısında köklü bir değişiklik yapmak zararlıydı. Değişimin farkındalığının yayılmaması daha zararlıydı.

UTF-16, işleme ve alan arasındaki en iyi uzlaşmadır ve bu nedenle çoğu büyük platform (Win32, Java, .NET) onu dizelerin dahili gösterimi için kullanır.

UTF-16'nın amacını hiç anlamadım. En verimli alanı temsil etmek istiyorsanız UTF-8 kullanın. Metni sabit uzunlukta olarak ele almak istiyorsanız, UTF-32'yi kullanın. İkisini de istemiyorsanız, UTF-16'yı kullanın. Daha da kötüsü, UTF-16'daki tüm genel (temel çok dilli düzlem) karakterleri tek bir kod noktasına uyduğundan, UTF-16'nın sabit uzunlukta olduğunu varsayan hataların zor ve ince olacağını düşünür, ancak Bu UTF-8 ile, uluslararası hale getirmeye çalıştığınız anda kodunuz hızlı ve yüksek sesle başarısız olacaktır.

_{Henüz yorum yapamadığımdan, bunu bir cevap olarak yazıyorum, çünkü yazarlarla başka türlü bağlantı kuramıyorum utf8everywhere.org. Diğer yığın değişimlerinde yeterince üne sahip olduğum için yorum ayrıcalığını otomatik olarak alamıyorum.}

Bu, Görüş'e yapılan bir yorum anlamına gelir : Evet, UTF-16'nın zararlı bir cevap olduğu düşünülmelidir .

Bir küçük düzeltme:

Yanlışlıkla bir UTF-8 geçişini birini engellemek için char*Windows API işlevlerinin ANSI-string sürümleri içine bir tanımlamalıdır UNICODEdeğil _UNICODE. _UNICODEgibi harita işlevleri _tcsleniçin wcslendeğil, MessageBoxiçin MessageBoxW. Bunun yerine, UNICODEtanım ikincisi ile ilgilenir. Kanıt olarak, bu MS Visual Studio 2005'in WinUser.hbaşlığından:

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

En azından bu hatanın düzeltilmesi gerekiyor utf8everywhere.org.

Öneri:

Belki de rehber, bir veri yapısının Geniş dize versiyonunun açıkça kullanılmasının bir örneğini içermeli, onu kaçırmayı / unutmayı daha kolay hale getirmek için. Geniş dizili veri yapılarının sürümlerinin kullanılması Geniş dizili işlev sürümlerinin kullanılması, birinin yanlışlıkla böyle bir işlevin bir ANSI dizesi sürümünü çağırması olasılığını azaltır.

Örnek olarak:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Birisi UCS4 ve UTF-32'nin aynı olduğunu söyledi. Hayır, ama ne demek istediğini biliyorum. Bunlardan biri olsa da, diğerinin kodlamasıdır. Keşke ilkden endian'ı belirtmeyi düşünmeseydiler, böylece burada endianess savaşı da yapmazdık. Bunun olacağını görmediler mi? En azından UTF-8 her yerde aynı (6-byte'lık orijinal spesifikasyona uymadığı sürece).

UTF-16 kullanıyorsanız , çok baytlı karakterleri işlemeyi dahil etmeniz gerekir . 2n'yi bir bayt dizisine dizine sokarak Nth karakterine gidemezsiniz. Yürümek ya da karakter indeksine sahip olmalısın. Aksi takdirde bir hata yazdın.

C ++ 'nın şu anki taslak özelliği, UTF-32 ve UTF-16'nın küçük endian, büyük endian ve belirtilmemiş varyantları olabileceğini söylüyor. Gerçekten mi? Unicode, herkesin en başından beri küçük endian yapmak zorunda olduğunu belirtmiş olsaydı, her şey daha basit olurdu. (Ben de büyük-endian ile iyi olurdu.) Bunun yerine, bazı insanlar bunu bir şekilde, bir başkasını uyguladı ve şimdi hiçbir şey için sersemlikten mahrum kaldık. Bazen yazılım mühendisi olmak utanç verici.

Geliştiricinin yeterince dikkatli olmasının zararlı olduğunu düşünmüyorum.
Ve eğer iyi biliyorlarsa bu işlemi kabul etmeleri gerekir.

Bir Japon yazılım geliştiricisi olarak, UCS-2'yi yeterince büyük buluyorum ve alanı sınırlandırıyorum, mantığı basitleştiriyor ve çalışma zamanı belleğini azaltıyor, bu nedenle utc-16'yı UCS-2 sınırlaması altında kullanmak yeterince iyi.

Kod noktaları ve baytların orantılı olduğunu varsayan dosya sistemi veya başka bir uygulama vardır, böylece ham kod noktası sayısının bazı sabit boyutta depolamaya uygun olacağı garanti edilebilir.

Bunun bir örneği, UCS-2'yi dosya adı depolama kodlaması olarak belirten NTFS ve VFAT'dir .

Bu örnek gerçekten UCS-4'ü desteklemeyi istiyorsa, yine de her şey için utf-8'i kullanmayı kabul edebilirim, ancak sabit uzunluk aşağıdaki gibi iyi noktalara sahiptir:

1. Uzunluğa göre boyutu garanti edebilir (veri boyutu ve kod noktası uzunluğu orantılıdır)
2. hash araması için kodlama numarasını kullanabilir
3. sıkıştırılmamış veriler makul boyuttadır (utf-32 / UCS-4 ile karşılaştırıldığında).

Herhangi bir gömülü aygıtta bile bellek / işlem gücünün ucuz olması durumunda, ekstra önbellek hataları veya sayfa hataları ve ekstra bellek kullanımı için cihazın biraz yavaş olduğunu kabul edebiliriz, ancak bu yakın gelecekte gerçekleşmeyecek sanırım ...

"En popüler kodlamalardan biri olan UTF-16'nın zararlı olduğu düşünülmeli mi?"

Oldukça muhtemel, ancak alternatiflerin mutlaka daha iyi olduğu düşünülmemelidir.

Temel sorun, glifler, karakterler, kod noktaları ve bayt dizileri hakkında birçok farklı kavramın olmasıdır. Bunların her biri arasındaki haritalama, normalleştirme kütüphanesinin yardımı ile bile önemsiz değildir. (Örneğin, Latin dilindeki bir komut dosyasıyla yazılan Avrupa dillerindeki bazı karakterler tek bir Unicode kod noktasıyla yazılmaz. Ve bu karmaşıklığın daha basit bir ucunda!) Bunun anlamı her şeyin doğru olması oldukça şaşırtıcı. zor; tuhaf hatalar beklenir (ve sadece burada onlar hakkında sızlanmak yerine, ilgili yazılımın sağlayıcılarına söyleyin ).

UTF-16'nın zararlı olarak kabul edilmesinin tek yolu, örneğin, UTF-8'in BMP dışındaki kod noktalarını kodlamanın farklı bir yoluna sahip olmasıdır (bir vekil olarak). Kod, kod noktasına göre erişmek veya yinelemek istiyorsa, bunun farktan haberdar olması gerektiği anlamına gelir. OTOH, "karakterleri" kabul eden önemli bir varolan kodun, her zaman iki baytlık bir miktara sığabileceği anlamına gelir - oldukça yaygın, eğer yanlışsa, varsayım - en azından hepsini yeniden inşa etmeden çalışmaya devam edebilir. Başka bir deyişle, en azından doğru şekilde kullanılmayan karakterleri görüyorsunuz !

Sorunuzu kafasına çevirip, Unicode'un lanet olası bütününün, zararlı olduğu düşünülmeli ve herkesin 8-bit kodlama kullanması gerektiğini (son 20 yılda, bunun neden olduğu yerde görmedim: korkunç) Çeşitli ISO 8859 kodlamaları, artı Kiril ve EBCDIC paketi için kullanılan tüm setler üzerinde kafa karışıklığı ve… iyi, Unicode tüm hataları için atıyor. Keşke farklı ülkelerin yanlış anlamaları arasında bu kadar kötü bir uzlaşma olmasaydı.