Unicode

• Některé programy (například databáze Oracle ), které interně představují svá data Unicode ve formátu UTF-16, mají (nebo již zažily) poruchu převodu na UTF-8: znak mezi U + 10 000 a U + 10FFFF, uložený ve dvou 16- bit slova, je převeden na UTF-8 jako posloupnost dvou znaků Unicode. To vedlo k „náhodnému“ vytvoření CESU-8 a má tu výhodu, že usnadňuje používání Unicode na 16bitových platformách.
• Znak Unicode nulový U + 0000 je kódován v UTF-8 jako jediný nulový bajt 0x00 . Podle standardu Unicode nemá tento znak žádný zvláštní význam; nicméně (z historických koncepčních důvodů) považují knihovny pro zpracování řetězců jazyka C tento řídicí znak za konec řetězce, což komplikuje implementaci některých aplikačních případů . Pod platformou Java  se zrodila verze „  (en) Modified UTF-8 “ využitím „16bitové“ přenositelnosti CESU-8 a přidáním možnosti kódování U + 0000 pod sekvenci 0xC0 0x80. (obvykle zakázáno v UTF-8): výměnou tímto způsobem s nativními C knihovnami podporované platformy může platforma snadno spravovat všechny platné texty Unicode i kompilované soubory tříd (přenosný alternativní formát, nezávislý na endianness a slově velikost).

UTF-16 je dobrý kompromis, kdy místo v paměti není příliš malá, protože drtivá většina znaků Unicode přiřazených ke spisům moderních jazyků (včetně nejčastěji používaných znaků) jsou ve vícejazyčném základně plánu, a proto může být zastoupen na 16 bitů. Francouzská verze ISO / IEC 10646 nazývá tato 16bitová slova „seizets“, ale mezinárodní verze je přesto popisuje jako klasická 16bitová slova složená ze dvou bajtů a podléhající obvyklým pravidlům endismu .

Body kódu šestnácti dalších rovin vyžadují transformaci dvou 16bitových slov:

• odečíst 0x10000 od bodu kódu a ponechat 20bitové číslo v rozsahu 0x00 až 0xFFFFF;
• 10 nejvýznamnějších bitů (číslo mezi 0x00 a 0x3FF) je přidáno k 0xD800 a dává první kódovou jednotku ve vysoké poloviční zóně ( 0xD800 až 0xDBFF );
• 10 nejméně významných bitů (číslo mezi 0x00 a 0x3FF) je přidáno k 0xDC00 a dává druhou kódovou jednotku v nízké poloviční zóně ( 0xDC00 až 0xDFFF );

Protože většina běžně používaných znaků je umístěna v základní rovině, je kódování dalších klipů často špatně testováno v softwaru, což vede k chybám nebo problémům se zabezpečením i v široce distribuovaném softwaru. Některé právní rámce, jako je GB 18030 , mohou požadovat podporu dalších plánů, které zejména obsahují znaky přítomné ve vlastních jménech.

Je možné určit začátek kódovací sekvence z kteréhokoli bodu v textu představovaném v UTF-16 provedením maximálně jednoho dalšího čtení, pouze pokud je tento kódový bod v dolní poloviční oblasti. Tato forma je ekonomičtější a rychlejší na zpracování textů obsahujících několik znaků ASCII (U + 0000 až U + 007F) než UTF-8.

Tato transformace má však dvě nekompatibilní schémata kódování, která závisí na uspořádání bajtů v 16bitové celočíselné reprezentaci. Abychom tuto nejednoznačnost vyřešili a umožnili přenos mezi heterogenními systémy, je nutné přidat informace označující použité kódovací schéma (UTF-16BE nebo UTF-16LE) nebo před kódovaný text uvést kódový bod. Valid U + FEFF (přiřazeno znaku „nerozbitný prostor s nulovou šířkou“, znak nyní vyhrazený pro toto výhradní použití jako značka řazení bytů), protože kódový bod „obrácený“ U + FFFE platný je neznak, v textech zakázaný vyhovuje Unicode a ISO / IEC 10646 .

Druhou chybou UTF-16 je, že text transformovaný s ním a přenášený jedním ze dvou kódovacích schémat obsahuje velký počet bajtů, které mají hodnotu null nebo mají hodnotu, která je v rozporu s hodnotami d. 'Bajty vyhrazené určitými výměnnými protokoly.

Jedná se zejména o kódování, které platforma Java interně používá , stejně jako Windows pro jeho API kompatibilní s Unicode (s typem wchar).

UTF-32 se používá, když je paměťový prostor není problém a my musíme mít přístup k znaky přímo a beze změny velikosti ( egyptské hieroglyfy ).

Výhodou této standardizované transformace je, že všechny prvky kódu mají stejnou velikost. Není proto nutné číst další kódové body k určení začátku reprezentace kódového bodu.

Tento formát je však obzvláště neekonomický (včetně paměti), protože zbytečně „plýtvá“ alespoň jedním bajtem (vždy nulovým) na znak. Velikost paměti v textu má negativní vliv na výkon, protože vyžaduje více čtení a zápisů na disk v případě plné RAM a také snižuje výkon mezipaměti paměti procesorů.

U textů psaných v současných moderních jazycích (na rozdíl od určitých vzácných znaků doplňkové ideografické roviny), a proto pouze s použitím kódových bodů základní vícejazyčné roviny, tato transformace zdvojnásobuje množství potřebné paměti ve srovnání s UTF-16.

Stejně jako UTF-16, UTF-32 má několik kódovacích schémat v závislosti na uspořádání bytů skládajících celé číslo více než 8 bitů (dvě kódovací schémata UTF-32 jsou standardizována, UTF-32BE a UTF-32LE). Je proto také nutné specifikovat toto kódovací schéma nebo ho určit předponou textu reprezentací v UTF-32 kódového bodu U + FEFF. Stejně jako UTF-16 je přítomnost nulových bajtů ve standardizovaných schématech kódování UTF-32 nekompatibilní s mnoha protokoly pro výměnu mezi heterogenními systémy.

Také tento formát se používá nejčastěji jen velmi lokálně pro určité zpracování jako přechodná forma, se kterou se snáze manipuluje, a často dáváme přednost transformaci UTF-16, která je často efektivnější pro zpracování a ukládání velkého množství textů, převod mezi tyto dva jsou velmi snadno proveditelné a velmi levné, pokud jde o složitost zpracování.

Ve skutečnosti je mnoho knihoven pro zpracování textu psáno pouze s UTF-16 a je efektivnější než UTF-32, i když texty obsahují znaky dalších rovin (protože tento případ obrázku zůstává v drtivé většině případů vzácný).

Mějte však na paměti, že transformace na UTF-32 používá 32bitové kódové body, z nichž mnohé nemusí představovat žádný platný bod kódu (hodnoty mimo dva intervaly představující platné body kódu U + 0000 až U + D7FF a U + E000 až U + 10FFFF), proto žádný platný nebo vyhrazený znak (jakékoli informace v nich obsažené proto nemohou být textem ve smyslu Unicode). Přenos textů s použitím těchto neplatných hodnot kódu v jednom ze standardizovaných kódovacích schémat UTF-32 je zakázán pro jakýkoli systém vyhovující Unicode (je nutné místo toho použít body kódu pro soukromé použití), protože to nebude možné zastupovat je v jiné transformaci UTF, se kterou jsou tři standardizované UTF bijektivně kompatibilní.

Čínský standard GB 18030

Jedná se o transformaci Unicode, která není definována konsorciem Unicode, ale správou standardů v Číně, kde je její podpora v aplikacích povinná. Historicky se jednalo o kódovanou znakovou sadu, která byla rozšířena o podporu celého repertoáru UCS pomocí algoritmické transformace vyplňující velkou tabulku korespondence mezi kódy.

Písma Unicode

Tvrdit, že Unicode kóduje znaky, se rovná tvrzení, že přiřazuje číslo abstraktním symbolům podle principu logického kódování. Unicode na druhé straně nekóduje grafické znázornění znaků, glyfů . Mezi vyobrazením postavy a jejím číslem tedy není žádná námitka , protože všechny grafické varianty stylu jsou jednotné.

Kromě toho na rozdíl od klasického písma ASCII nebo Latin-1 není výběr glyfů kódem jedinečný a je často kontextový a může také zobrazit stejný glyf pro různé kódy. Francouzský znak „é“ lze tedy popsat dvěma způsoby: buď přímým použitím čísla odpovídajícího „é“, nebo sledováním čísla „e“ číslem akutního přízvuku bez lovu. Ať zvolíte jakoukoli možnost, zobrazí se stejný glyf. O prvním znaku řekneme, že je předkomponovaný, o druhém, že jde o kompozici (dva znaky tvoří jeden glyf složený z obou). To je povoleno a dokonce velmi doporučeno, protože různé formy kódování jsou Unicode klasifikovány jako „kanonicky ekvivalentní“, což znamená, že se dvěma ekvivalentními formami kódování by se mělo zacházet stejně.

Mnoho složených znaků je v tomto případě a lze je kódovat těmito dvěma způsoby (nebo více, některé složené znaky lze rozložit více než jedním způsobem, zejména pokud mají několik diakritiky). Nejčastěji je předkomponovaný znak vhodnější pro kódování textu, pokud existuje (to je například polytonická řečtina , která, zakódovaná při rozkladu, nemusí být graficky uspokojivá: v závislosti na písmech, různých složky glyfů, které jsou někdy špatně uspořádané a obtížně čitelné). Ne všechny složené znaky však mají pro svůj předem vytvořený tvar jedinečný bod kódu.

Stejně tak některé psací systémy, jako je Devânagarî , perský nebo arabský , vyžadují komplexní zpracování ligatur  : grafémy mění tvar v závislosti na své poloze nebo sousedních zemích (viz Kontextová varianta a Společný dopis ). Výběr správného glyfu vyžaduje zpracování, aby se určilo, který kontextový tvar se má v písmu vybrat, přestože všechny kontextové tvary jsou v Unicode kódovány shodně.

Z těchto důvodů je třeba s písmem Unicode zacházet opatrně. Například písmo se všemi existujícími glyfy není dostačující. Je také nutné, aby zobrazovací systém ( vykreslovací modul ) disponoval mechanismy schopnými zpracovávat ligatury , kontextové varianty a společné formy specifické pro určité jazyky. Naopak písmo, které představuje pouze část znaků, ale ví, jak je správně zobrazit, si lépe zaslouží název „písmo Unicode“. A konečně, určitá technická omezení formátů písem jim mohou bránit v podpoře celého adresáře. V praxi je nemožné (v roce 2009) najít jediné písmo, které podporuje celý adresář.

Znakové písmo Unicode je tedy pouze písmo umožňující přímo zobrazit text zakódovaný ve všech formách autorizovaných Unicode a umožňující podporu soudržné podmnožiny přizpůsobené jednomu nebo více jazykům pro podporu jednoho nebo více skriptů. Žádné písmo Unicode nemůže „fungovat“ samo o sobě a plná podpora psaní vyžaduje jejich podporu ve vykreslovacím modulu , který je schopen detekovat ekvivalentní formy kódování, vyhledávat kontextové formy v textu a vybírat různé glyfy písma kódovaného Unicode, v případě potřeby pomocí korespondenčních tabulek obsažených v samotném písmu.

Technické údaje

Softwarové knihovny

ICU multiplatformní knihovna software vám umožní manipulovat data zakódovaná s Unicode. Podporu Unicode specifickou pro platformu integrují také moderní systémy ( Java , Microsoft Windows , GNU / Linux , standardní knihovny C / C ++ , Python atd.).

Typy, které se mají použít k ukládání proměnných Unicode, jsou:

1. v UTF-8
2. Všimněte si však, že typ wchar_tjazyka C ne vždy umožňuje kódování všech znaků Unicode, protože standard tohoto jazyka neposkytuje dostatečný minimální počet pro tento standardní typ. Mnoho překladačů jazyka však definuje wchar_t32 bitů (nebo dokonce 64 bitů v prostředích zpracovávajících standardní 64bitová celá čísla), což je dostatečné pro uložení jakéhokoli bodu standardizovaného kódu Unicode. Ale jiné kompilátory představují wchar_tna 16 bitech (zejména v systému Windows v prostředí 16 nebo 32 bitů), dokonce pouze na 8 bitech (zejména v integrovaných prostředích, která nemají obecný operační systém), protože wchar_tmohou používat stejnou reprezentaci jako typ, charkterý má minimálně 8 bitů.
3. Podobným způsobem jako v C a C ++ má jazyk Java typ jednotky, který umožňuje kódovat 16 bitů, ale neumožňuje kódovat jediný bod kódu jakékoli hodnoty (nativním typem charje pouze kladné 16bitové celé číslo) . Chcete-li manipulovat se standardizovanými znaky mimo popředí, musíte použít pár kódových bodů, z nichž každý obsahuje hodnotu rovnající se dvěma kódovým bodům definovaným formulářem UTF-16. Také typy objektů Stringnebo char[2]jsou nejvhodnější pro reprezentaci znaku Unicode. Od prostředí Java 1.4.1 poskytuje standardní knihovna plnou podporu Unicode díky nativnímu typu int(což je celé číslo definované na 32 bitech) a statickým metodám standardní třídy Character(instanční objekt tohoto typu Characterto však neumožňuje, stejně jako nativní typ char, pro uložení libovolného bodu kódu).
4. JavaScript má různé nestandardizované implementace, některé starší, které nepodporují více než 16 bitů na znak a někdy pouze 8 bitů. Standard ECMAScript tohoto jazyka však definuje třídu obsluhy Characterna 32 bitech (ve skutečnosti založenou na třídě Number), která musí podporovat všechny kódové body 17 standardizovaných plánů, zatímco řetězce znaků používají povinně kódované znaky na 16 bitech (ale bez omezení posilující párování kódových jednotek UTF-16, přičemž řetězce typu ECMAScript Stringnejsou omezeny na jediné kódování UTF-16, ale jsou vektory celočíselných konstant kódovaných na 16 bitech bez omezení, aby byla zajištěna (interoperabilita s Javou a dalšími jazyky, které také nevynucují omezení shody UTF-16 ve svých nativních datových typech). Tyto dva jazyky nepodporují explicitní zadávání proměnných, přičemž typ je dynamicky definován hodnotami, které jsou jim přiřazeny (je také možné několik interních reprezentací, jejichž rozdíly jsou pro programátora obvykle transparentní).

Unicode však stále trpí slabou podporou regulárních výrazů některým softwarem, ačkoli knihovny jako ICU a Java je mohou podporovat. Taková podpora dosud nebyla standardizována pro ECMAScript a je poskytována pouze pomocí knihoven vytvořených s jazykem nebo rozhraní pro interoperabilitu s jinými systémy (zejména s CORBA , COM ) nebo jazyky (zejména C ++ a Java ).

Rozdělení na oddíly

Aktuální rozdělení na oddíly najdete na oficiálním webu Unicode. Vzhledem k důležité roli Unicode dnes ( ISO / IEC 10646 ) zde však budou popsány bloky hlavních znaků. Francouzské názvy jsou oficiálními názvy ISO / IEC 10646 , mezinárodního dvojjazyčného standardu, který používá stejné znaky jako Unicode. Jsou stejně oficiální jako anglická jména.

Starý standard Unicode 1.0 je zastaralý a nekompatibilní s ISO / IEC 10646 a Unicode 1.1 a se všemi jeho novějšími verzemi; hlavní nekompatibilita spočívá v tom, že znakové bloky Hangul používané pro psaní korejského jazyka, které změnily pozici a jejichž staré body kódu byly od té doby přiřazeny jiným blokům. Níže uvedená tabulka je kompatibilní s ISO / IEC 10646 (všechny verze) a Unicode 1.1 (nebo novější).

Poznámka: Názvy bloků nejsou normativní. „Basic Latin“ je tedy ekvivalentní „BASIC LATIN“.

V následujících tabulkách jakýkoli název bloku s poznámkou týkající se oficiálního souboru PDF Unicode znamená, že stránka Wikipedia přidružená k tomuto bloku neexistuje nebo je nesprávná.