UTF -32 - UTF-32

UTF-32 (32- bit Unicode transformační formát ) je kódování s pevnou délkou používá ke kódování Unicode body kódu , který používá přesně 32 bitů (čtyři bajty ) na místo v kódu (ale řadou významných bitů musí být nula, kolik je daleko méně než 2 32 bodů kódu Unicode, které ve skutečnosti potřebují pouze 21 bitů). UTF-32 je kódování s pevnou délkou, na rozdíl od všech ostatních formátů transformace Unicode, což jsou kódování s proměnnou délkou. Každá 32bitová hodnota v UTF-32 představuje jeden bod kódu Unicode a je přesně stejná jako číselná hodnota tohoto bodu kódu.

Hlavní výhodou UTF-32 je, že body kódu Unicode jsou přímo indexovány (ale písmena obecně, tj. „ Klastry grafému “ nebo některé emodži nelze přímo indexovat, ani není jednodušší vypočítat zobrazenou šířku řetězce). Nalezení N -tého bodu kódu v sekvenci bodů kódu je operace s konstantním časem . Naproti tomu kód s proměnnou délkou vyžaduje sekvenční přístup k nalezení N-tého bodu kódu v sekvenci. Díky tomu je UTF-32 jednoduchou náhradou v kódu, který používá celá čísla, která jsou zvýšena o jedno, aby prozkoumala každé umístění v řetězci, jak se běžně dělalo pro ASCII .

Hlavní nevýhodou UTF-32 je, že je prostorově neefektivní, používá čtyři bajty na bod kódu, včetně 11 bitů, které jsou vždy nulové. Znaky přesahující BMP jsou ve většině textů relativně vzácné (kromě např. Textů s některými populárními emodži) a pro odhady velikosti lze obvykle ignorovat. Díky tomu je UTF-32 téměř dvakrát větší než UTF-16 . Může být až čtyřikrát větší než UTF-8 v závislosti na tom, kolik znaků je v podmnožině ASCII .

Dějiny

Původní norma ISO 10646 definuje 32bitový kódovací formulář nazvaný UCS-4 , ve kterém je každý kódový bod v univerzální znakové sadě (UCS) reprezentován 31bitovou hodnotou od 0 do 0x7FFFFFFF (znaménkový bit byl nepoužitý a nula ). V listopadu 2003 byl Unicode omezen RFC 3629, aby odpovídal omezením kódování UTF-16 : výslovně zakázal kódové body větší než U+10FFFF (a také vysoké a nízké náhrady U+D800 až U+DFFF). Tato omezená podmnožina definuje UTF-32. Ačkoli standard ISO měl (od roku 1998 v Unicode 2.1) „vyhrazeno pro soukromé použití“ 0xE00000 až 0xFFFFFF a 0x60000000 až 0x7FFFFFFFF, tyto oblasti byly v novějších verzích odstraněny. Protože dokument Principles and Procedures of ISO/IEC JTC 1/SC 2 Working Group 2 uvádí, že všechna budoucí přiřazení kódových bodů budou omezena na rozsah Unicode, UTF-32 bude moci reprezentovat všechny kódové body UCS a UTF-32 a UCS-4 jsou totožné.

Analýza

Ačkoli pevný počet bajtů na bod kódu vypadá pohodlně, není tak užitečný, jak se zdá. Ve srovnání s UTF-8 a UTF-16 je zkrácení snazší, ale ne výrazně (oba mohou zpětně hledat bod, který se má zkrátit, a to maximálně při pohledu na 2–4 ​​kódové jednotky). V praxi například kvůli sekvencím emoji ZWJ (a/nebo modifikátorům emodži měnícím případně barvu kůže ) některé emodži již nejsou jedním kódovým bodem, například „👨‍🦲 Muž: Plešatý“ a „👩‍🦰 Žena: Červené vlasy“ a proto nelze na text spoléhat, že je seznamem symbolů, každý reprezentovaný jedním kódovým bodem.

Je extrémně vzácné, že si kód přeje najít N -tý bod kódu, aniž by dříve zkoumal body kódu 0 až N – 1. Analýza XML například nemůže dělat nic se znakem, aniž by se nejprve podíval na všechny předchozí znaky. Takže celočíselný index, který je zvýšen o 1 pro každý znak, může být nahrazen celočíselným offsetem, měřeno v kódových jednotkách a zvýšeno o počet kódových jednotek při zkoumání každého znaku. Tím se odstraní vnímané výhody rychlosti UTF-32.

UTF-32 nezjednodušuje výpočet zobrazené šířky řetězce, protože i u písma s „pevnou šířkou“ může být více než jeden kódový bod na pozici znaku ( kombinace znaků ) nebo více než jedna pozice znaků na bod kódu („ klastry grafémů “pro ideografy CJK ). Editory, které se omezují na jazyky zleva doprava a předkomponované znaky, mohou využívat výhod kódových jednotek pevné velikosti, ale je nepravděpodobné, že by takové editory podporovaly znaky jiné než BMP, a proto mohou stejně dobře fungovat s UTF-16 .

Použití

Hlavní použití UTF-32 je v interních rozhraních API, kde jsou data body jednoho kódu nebo glyfy, spíše než řetězce znaků. Například v moderním vykreslování textu je běžné, že posledním krokem je sestavení seznamu struktur, z nichž každá obsahuje souřadnice (x, y) , atributy a jeden kódový bod UTF-32 identifikující glyf, který se má kreslit. Informace, které nejsou v Unicode, jsou často uloženy v „nepoužitých“ 11 bitech každého slova.

Použití řetězců UTF-32 v systému Windows (kde wchar_t je 16 bitů) téměř neexistuje. V systémech Unix jsou řetězce UTF-32 někdy, ale zřídka, používány interně aplikacemi, protože typ wchar_t je definován jako 32bitový. Pro použití namísto UTF-16 lze kompilovat verze Pythonu až do 3,2 ; od verze 3.3 dále jsou všechny řetězce Unicode uloženy v UTF-32, ale s úvodními nulovými bajty optimalizovanými pryč „v závislosti na [bod kódu] s největším pořadovým číslem Unicode (1, 2 nebo 4 bajty)“, aby byly všechny body kódu takové velikosti . Programovací jazyky Seed7 a Lasso kódují všechny řetězce pomocí UTF-32 ve víře, že přímé indexování je důležité, zatímco programovací jazyk Julia se s vydáním 1.0 vzdálil od vestavěné podpory UTF-32, což zjednodušuje jazyk tak, aby měl pouze řetězce UTF-8 (se všemi ostatními kódováními považovanými za starší a přesunutými ze standardní knihovny do balíčku) podle „Manifestu UTF-8 Everywhere“.

Varianty

Náhradní poloviny, ačkoli jsou technicky neplatné, jsou často zakódovány a povoleny. To umožňuje překlad neplatných UTF-16 (například názvů souborů Windows) do UTF-32, podobně jako funguje varianta WTF-8 UTF-8. Někdy jsou místo znaků jiných než BMP kódovány spárované náhražky, podobně jako v CESU-8 . Vzhledem k velkému počtu nepoužívaných 32bitových hodnot je také možné zachovat neplatný UTF-8 pomocí kódování chyb UTF-8, které nejsou kódovány Unicode, ačkoli pro to neexistuje žádný standard.

Viz také

Reference

externí odkazy