Az UTF-16-ot károsnak kell-e tekinteni?

Ez egy régi válasz.
Lásd: UTF-8 mindenhol a legfrissebb frissítésekért.

vélemény: Igen, az UTF-16-ot károsnak kell tekinteni . Éppen azért létezik, mert egy ideje téves vélekedés volt arról, hogy a widechar az lesz, ami most az UCS-4.

Az UTF-8 “anglo-centrizmusa” ellenére a szöveg egyetlen hasznos kódolásának kell tekinteni. Azt állíthatjuk, hogy a programok, weblapok és XML fájlok forráskódjainak, az operációs rendszer fájlneveinek és más számítógép-számítógép szöveges interfészeknek soha nem kellett volna létezniük. De amikor igen, akkor a szöveg nem csak az emberi olvasók számára szól.

Másrészt az UTF-8 rezsicsökkentés alacsony ár, miközben jelentős előnyökkel jár. Előnyök, például kompatibilitás a nem tudatos kódokkal, amelyek csak átengedik a karakterláncokat a char* karakterlánccal. Ez nagyszerű dolog. Kevés olyan hasznos karakter van, amelyek RÖVIDEBBEK az UTF-16-ban, mint az UTF-8-ban.

Úgy gondolom, hogy az összes többi kódolás végül elpusztul. Ez magában foglalja az MS-Windows, Java, ICU, python ne használja tovább kedvencként. Hosszas kutatások és beszélgetések után a cégemnél alkalmazott fejlesztési egyezmények betiltják az UTF-16 használatát bárhol, kivéve az OS API hívásokat, és ez a fontosság ellenére az alkalmazásunk teljesítménye és a Windows használata. Konverziós függvényeket fejlesztettek ki a mindig feltételezett UTF8 std::string s átalakítására natív UTF-16-ra, amelyet maga a Windows nem támogatja megfelelően .

Azoknak az embereknek, akik azt mondják, hogy „ használd, amire szükség van, ahol szükséges ”, azt mondom: óriási előnye van annak, ha mindenhol ugyanazt a kódolást használjuk, és nem látok elegendő okot arra, hogy tegyenek másként. Különösen azt gondolom, hogy a wchar_t hozzáadása a C ++ -hoz hiba volt, és ugyanígy az Unicode-kiegészítések is a C ++ 0x-hez. Bár az STL-implementációktól meg kell követelni, hogy minden A std::string vagy a char* paraméter unicode-kompatibilisnek tekinthető.

Én is ellenzem a “ use” -t mit akarsz “megközelítés. Nem látok okot az ilyen szabadságra. Elég zavart a szöveg témájában, ami mindezt a megtört szoftvert eredményezi. Miután fentebb említettem, meg vagyok győződve arról, hogy a programozóknak végre egyetértésre kell jutniuk az UTF-8-mal kapcsolatban, mint az egyik megfelelő módon. (Nem aszkii nyelvű országból származom, és Windows rendszeren nőttem fel, így utoljára várhatóan az UTF-16 elleni támadást várnám vallási alapon).

Szeretnék több információt megosztani arról, hogyan csinálok szöveget a Windows rendszeren, és mit ajánlok mindenki másnak a fordítás idején ellenőrzött unicode helyességért, egyszerű használatért és a kód jobb multiplatformosságáért. A javaslat lényegesen eltér attól, amit általában az Unicode Windows rendszeren történő használatának megfelelő módjaként javasolnak. Mégis, ezen ajánlások alapos kutatása ugyanezt a következtetést vonta le. Így jár:

• Ne használja a wchar_t vagy a std::wstring elemet a szomszédos ponttól eltérő helyen Az UTF-16-ot elfogadó API-k.
• Ne használja _T("") vagy L"" UTF-16 literálokat (ezeket az IMO-t ki kell venni a szabványból , az UTF-16 megszüntetésének részeként).
• Ne használja a _UNICODE konstansra érzékeny típusokat, függvényeket vagy származékaikat, például a LPTSTR vagy CreateWindow().
• Ennek ellenére _UNICODE mindig meghatározták kerülje a char* karakterláncok átadását a WinAPI számára a csendes fordítás
• std::strings és char* program bármely pontja UTF-8-nak számít (ha másként nem mondjuk)
• Az összes karakterláncom std::string, bár a char * vagy string karakterláncot átadhatja convert(const std::string &).

• csak olyan Win32-függvényeket használjon, amelyek elfogadják a szélessávú karaktereket (LPWSTR). Soha ne fogadja el a LPTSTR vagy a LPSTR alkalmazást. A paramétereket így adja át:

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

  (A házirend az alábbi konverziós függvényeket használja.)

• MFC karakterláncokkal :

  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); 

• Fájlokkal, fájlnevekkel és fstreamekkel való munka Windows rendszeren:

  • Soha ne adja át a std::string vagy const char* fájlnév-argumentumok a fstream családhoz. Az MSVC STL nem támogatja az UTF-8 argumentumokat, de rendelkezik egy nem szabványos kiterjesztéssel, amelyet a következőképpen kell használni:

  • std::string argumentumok konvertálása std::wstring a következővel: Utils::Convert:

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

    Manuálisan kell elvégeznünk távolítsa el a konvertálást, amikor az MSVC hozzáállása a fstream hez megváltozik.

  • Ez a kód nem több platformos, ezért előfordulhat, hogy manuálisan kell megváltoztatni a jövő
  • További információért tekintse meg a fstream unicode 4215-ös kutatási / megbeszélési esetet.
  • Soha ne állítson elő szöveges kimeneti fájlokat nem UTF8 tartalommal
  • RAII / OOD okokból kerülje az fopen() használatát. Ha szükséges, használja a fenti _wfopen() és WinAPI konvenciókat.

// 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 } 

megjegyzések

• nem tudok ' egyetérteni. Az utf16 előnyei az utf8-mal szemben sok ázsiai nyelv esetében teljesen uralják az Ön által tett pontokat. Naivitás azt remélni, hogy a japánok, a thaiföldi, a kínai stb. Feladják ezt a kódolást. A karakterkészletek közötti problematikus ütközések akkor fordulnak elő, amikor a karakterek többnyire hasonlónak tűnnek, kivéve a különbségeket. Azt javaslom, hogy szabványosítsuk: fix 7 bites: iso-irv-170; 8 bites változó: utf8; 16 bites változó: utf16; 32 bites fix: ucs4.
• @Charles: köszönöm a közreműködést. Igaz, néhány BMP karakter hosszabb az UTF-8-ban, mint az UTF-16-ban. De nézzünk szembe ' vel: a probléma nem a BMP kínai karakterek által elfoglalt bájtokban van, hanem a felmerülő szoftvertervezés összetettségében. Ha egy kínai programozónak egyébként is változó hosszúságú karaktereket kell terveznie, úgy tűnik, hogy az UTF-8 még mindig alacsony árat fizet a rendszer többi változójához képest. Lehet, hogy az UTF-16-ot használja tömörítési algoritmusként, ha a tér annyira fontos, de akkor sem lesz megfelelő az LZ számára, és az LZ vagy más általános tömörítés után körülbelül ugyanolyan méretű és entrópia szükséges.
• Alapvetően azt mondom, hogy elképzelhetetlen az az egyszerűsítés, amelyet a One kódolás kínál, amely kompatibilis a meglévő char * programokkal, és manapság a legnépszerűbb is.Szinte olyan, mint a régi jó " plaintext " napokban. Meg akar nyitni egy nevet tartalmazó fájlt? Nem kell törődni azzal, hogy milyen unicode-ot csinálsz stb. Azt javaslom, hogy mi, fejlesztők, az UTF-16-ot csak a súlyos optimalizálás speciális eseteire korlátozzuk, ahol egy apró teljesítmény emberhónapos munkát ér.
• A Linuxnak sajátos követelménye volt, amikor az UTF-8 belső használatát választotta: kompatibilitás a Unixszal. A Windows-nak nem kellett ' erre szüksége, és így amikor a fejlesztők megvalósították az Unicode-ot, hozzáadták szinte az összes szövegkezelő funkció UCS-2 verzióját, és a többbájtosakat egyszerűen átalakították UCS-2-vé, és hívja a többieket. THey később az UCS-2-et UTF-16-ra cseréli. A Linux viszont tartotta a 8 bites kódolásokat, és így az UTF-8-at használta, mivel ' ez a megfelelő választás ebben az esetben.
• @Pavel Radzivilovsky : BTW, az írásaid a " -ről azt hiszem, hogy az összes többi kódolás végül meghal. Ez azt jelenti, hogy az MS-Windows, a Java, az ICU, a python nem használja kedvencként. " és " Különösen azt gondolom, hogy a wchar_t hozzáadása a C ++ -hoz hiba volt, és a C ++ Ox unicode-os kiegészítései is. " vagy elég naivak, vagy nagyon arrogánsak . És ez olyan embertől származik, aki otthon kódol Linux alatt, és aki elégedett az UTF-8 karakterekkel. Egyenesen fogalmazva: Nem fog ' megtörténni .

Az Unicode kódpontok nem karakterek! Néha nem is karakterjelek (vizuális formák) .

Néhány példa:

• római számú kódpontok, például “ⅲ”. (Egyetlen karakter, amely úgy néz ki, mint a “iii”.)
• Kiemelt karakterek, mint az “á”, amelyek akár egyetlen kombinált karakterként “\ u00e1”, akár egy karakterként, és elválasztott diakritikusként “\ u0061 \ u0301 “.
• Olyan karakterek, mint a görög kisbetűs sigma, amelyeknek különböző formái vannak a szópozíciók középső (” σ “) és vége (” ς “) számára, de amelyeket a keresés szinonimáinak kell tekinteni.
• Unicode diszkrecionális kötőjel U + 00AD, amelyet vizuálisan megjeleníthet, vagy nem, a kontextustól függően, és amelyet a szemantikai keresésnél figyelmen kívül hagynak.

Az Unicode szerkesztésének egyetlen módja joga egy szakértő által írt könyvtár használata , vagy szakértővé válás és saját maga írása. Ha csak a kódpontokat számolja, akkor bűn állapotában él.

Megjegyzések

• Ez. Nagyon ezt. Az UTF-16 problémákat okozhat, de még az egész UTF-32 használata is problémákat okozhat (és fog is).
• Mi az a karakter? Meghatározhat egy kódpontot karakterként, és nagyjából jól boldogul. Ha a felhasználó által látható karakterjelre gondolsz, az valami más.
• @tchrist biztos abban, hogy helyet oszt ki, ez a meghatározás rendben van, de bármi másra? Nem túl sok. Ha a kombináló karaktert egyedüli karakterként kezeli (azaz törlés vagy " esetén vegye az első N karaktert " művelethez), akkor ' furcsa és helytelen viselkedést tapasztal. Ha egy kódpontnak csak akkor van jelentése, ha legalább egy másikkal kombináljuk, akkor ' nem kezelheti önmagában bármilyen értelmes módon.
• @Pacerier, ez késő a buliba, de ehhez hozzászólnom kell. Egyes nyelvekben nagyon nagy a kritikák lehetséges kombinációinak halmaza (vö. Vietnami, azaz mệt đừ). Nagyon hasznos, ha a diakritikusban egy karakter helyett kombinációk szerepelnek.
• egy kis megjegyzés a terminológiáról: kódpontok nem felelnek meg az unicode karaktereknek ; amiről Daniel itt beszél, azok a felhasználó által érzékelt karakterek , amelyek megfelelnek az unicode grafémaklasztereknek

Egy egyszerű ökölszabály van arra vonatkozóan, hogy az Unicode Transformation Form (UTF) miként használható: – utf-8 tároláshoz és kommunikációhoz – utf-16 adatfeldolgozáshoz – lehet, hogy megy az utf-32-vel, ha a platform API-jainak nagy része utf-32 (a UNIX világában elterjedt).

A legtöbb rendszer ma az utf-16-ot használja (Windows, Mac OS, Java, .NET, ICU (Qt). Lásd még ezt a dokumentumot: http://unicode.org/notes/tn12/

Vissza az “UTF-16 mint káros” oldalra, Azt mondanám: határozottan nem.

Azok, akik félnek a helyettesítőktől (azt gondolva, hogy az Unicode-ot változó hosszúságú kódolássá alakítják át), nem értik a többi (sokkal nagyobb) bonyolultságot, amelyek a karakterek és a karakterek közötti feltérképezést teszik lehetővé. a Nagyon bonyolult Unicode kódpont: karakterek, ligatúrák, variációválasztók, vezérlő karakterek stb. kombinálása.

Olvassa el itt ezt a sorozatot http://www.siao2.com/2009/06/29/9800913.aspx , és megtudhatja, hogyan válik az UTF-16 egyszerű problémává.

Megjegyzések

• Adjon meg néhány példát, ahol az UTF-32 elterjedt a UNIX világában!
• Nem, nem az UTF-16-ot szeretné használni az adatfeldolgozáshoz. ' fájdalmat okoz a szamárban. Megvan az UTF-8 összes hátránya, de egyik előnye sincs. Az UTF-8 és az UTF-32 is egyértelműen felülmúlja a korábban Mrs. UTF-16 néven ismert rosszindulatú hacket, akinek leánykori neve UCS-2 volt.
• Tegnap nemrég találtam egy hibát a Java core String osztályban equalsIgnoreCase módszer (a sztring osztály többi tagja is), amely soha nem lett volna ott, ha a Java az UTF-8-at vagy az UTF-32-et használta volna. Ezeknek az alvó bombáknak milliói vannak minden olyan kódban, amely az UTF-16-ot használja, és én beteg vagyok és elegem van belőlük. Az UTF-16 egy gonosz pox, amely alattomos hibákkal sújtja szoftverünket örökkön örökké. Nyilvánvalóan káros, ezért el kell vetni és ki kell tiltani.
• @tchrist Wow, tehát nem helyettesítő tudatosságú funkció (mert akkor írták, amikor még nem voltak, és sajnos olyan módon dokumentálják, hogy valószínűleg lehetetlen alkalmazkodni – megadja .toUpperCase (char)) helytelen viselkedést eredményez? ' tudatában van annak, hogy egy elavult kódponttérképpel rendelkező UTF-32 függvény nem kezelné ezt jobban? ' Szintén az egész Java API nem igazán jól kezeli a helyettesítőket, és az Unicode-ot érintő bonyolultabb pontok egyáltalán nem – és a későbbiekben a használt kódolás egyáltalán nem számítana.
• -1: A feltétel nélküli .Substring(1) a .NET-ben triviális példa valamire, amely megszakítja az összes nem BMP Unicode támogatást. Minden, ami UTF-16-ot használ, rendelkezik ezzel a problémával; ' túl könnyű fix szélességű kódolásként kezelni, és túl ritkán lát problémákat. Ez aktívan káros kódolássá teszi, ha támogatni kívánja az Unicode-ot.