BOCU

BOCU (anglicky Binary Ordered Compression for Unicode, volně přeloženo jako binární komprese pro unicode) je v informatice název obecného kompresního formátu pro Unicode, který je kompatibilní s formáty MIME. Hlavní používanou formou BOCU je ve většině případů BOCU-1, která kombinuje širokou použitelnost UTF-8 s kompaktností SCSU (Standardního kompresního schéma pro Unicode). Toto kódování Unicode je navrženo tak, aby bylo vhodné pro kompresi krátkých řetězců se zachováním posloupnosti kódu. BOCU-1 je také specifikováno v technické poznámce Unicode.

Srovnání BOCU s UTF-8 a SCSU

Srovnání s UTF-8: BOCU zabírá pro Latinku přibližně stejnou velikost paměti jako UTF-8. Pro kódování malých abeced zabírá UTF-8 mnohem méně paměti, víc než jeden bajt na znak a při kódování větších abeced (jako například CJK nebo Hangul) zabírá okolo dvou třetin paměti, víc než dva bajty na znak.

Srovnání se SCSU: Binární uspořádání BOCU je stejné jako v Unicode, SCSU má v podstatě náhodné binární uspořádání. Kód pro kompresi nebo dekompresi BOCU je mnohem jednodušší než u SCSU. Na rozdíl od SCSU, kde mohou být stejné kódové body komprimované do mnoha odlišných bajtových sekvencí, je BOCU neměnný a výsledky mají vždy stejné pořadí bajtů. SCSU byl přijat jako standard kompresního schéma Unicode s podobným poměrem bajt/kód jaký mají národní znakové sady. SCSU nebyl široce přijat, protože není vhodný pro textové formáty definované v MIME. Například SCSU nemůže být přímo použit při kódování e-mailů ani v jiných podobných protokolech. SCSU vyžaduje pro dosažení dobrého výkonu složitější návrh enkodéru. Komprimační nástroje jako je zip, bzip2 nebo jiné, jsou obvykle efektivnější než SCSU. Obě znakové sady SCSU a BOCU-1 jsou registrované u organizace IANA.

Podrobnosti

Všechna čísla v této sekci jsou hexadecimální včetně všech rozsahů. Kódové body od U+0000 do U+0020 jsou zakódovány s odpovídající hodnotou bajtu v BOCU-1. Všechny ostatní kódové body (jsou to: U+0021 až U+D7FF a U+E000 až U+10FFFF) jsou kódovány jako rozdíl mezi bodem kódu a normalizovanou verzí z posledního kódového bodu Unicode, který nebyl v ASCII tabulce (U+0020). Počáteční stav je U+0040. Normalizace mapování je následující:

Kódový rozsah	Normalizovaný kód bodu	Poznámka
U+3040 až U+309F	U+3070	Hiragana
U+4E00 až U+9FA5	U+7711	Unihan
U+AC00 až U+D7A3	U+C1D1	Hangul
U+0020	Stav enkodéru	Umístění
U+xxxx00 až U+xxxx7F (S výjimkou rozsahu uvedeném výše)	U+xxxx40	mezi 128
U+xxxx80 až U+xxxxFF (S výjimkou rozsahu uvedeném výše)	U+xxxxC0	mezi 128

Rozdíl mezi aktuálním kódovým bodem a předchozím normalizovaným kódovým bodem je zakódován následovně:

Rozsah	Rozsah bajtové posloupnosti (viz níže)
-10FF9F až -2DD0D	21 F0 58 D9 až 21 FF FF FF
-2DD0C až -2912	22 01 01 až 24 FF FF
-2911 až -41	25 01 až 4F FF
-40 až 3F	50 až CF
40 až 2910	D0 01 až FA FF
2911 až 2DD0B	FB 01 01 až FD FF FF
2DD0C až 10FFBF	FE 01 01 01 až FE 19 B4 54

Každý bajtový rozsah je lexikograficky seřazen s následujícími třinácti vyřazenými bajtovými hodnotami: 00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20. Například bajtová sekvence FC 06 FF, šifrovaná s rozdílem 1156B, je okamžitě následována bajtovou sekvencí FC 10 01, šifrovanou s rozdílem 1156C.

Jakýkoli vstup ASCII U+0000 až U+007F s výjimkou U+0020 resetuje enkodér na U+0040, protože výše uvedené hodnoty se vztahují na konec řádku kódových bodů U+000D a U+000A jako je (0D 0A), enkodér je ve známém stavu na začátku každého řádku. Poškození jednotlivého bajtu tedy postihuje nanejvýš jeden řádek. Pro srovnání: při poškození jednoho bajtu, při kódování UTF-8, je poškozen nanejvýš jeden bit kódu, v SCSU může mít poškození vliv na celý dokument.

BOCU-1 nabízí podobnou odolnost pro vstupní texty bez výše uvedených hodnot se zvláštním kódem resetu 0xFF. Pokud dekodér najde tento oktet (osmici) resetuje jeho stav na U+0040 (jako konec řádku). Použití bajtu resetu 0xFF se v BOCU-1 nedoporučuje, protože je v rozporu s ostatními návrhy BOCU-1, zejména v binárním pořadí.

Možnost použití podpisu U+FEFF na začátku zakódovaných textů BOCU-1, to je bajtová sekvence FB EE 28, umožňuje změnu počátečního stavu U+0040 na U+FE80. Jinými slovy znak nemůže být odstraněn jako v mnoha jiných kódových tabulkách Unicodu. Přidáním bajtu resetu po podpisu (FB EE 28 FF) by se tomuto efektu dalo vyhnout, ale specifikace BOCU-1 to nedoporučuje.

Teoreticky může UTF-1 a UTF-8 kódovat původní UCS-4 sadou s 31 bajty až do 7FFFFFFF. BOCU-1 a UTF-16 je možné zašifrovat moderními sadami Unicode od U+0000 do U+10FFFF. S vyloučením třinácti chráněnými kódovými body, zakódovaných jako jediný oktet, může BOCU-1 použít 256 − 13 = 243 v multibajtovém kódování. BOCU-1 potřebuje maximálně čtyři bajty skládající se z řídícího bajtu a jednoho až třech doprovodných bajtů. Zbývající rozdíl doprovodných bajtů kóduje „modulo 243“ (základ 243), vedoucí bajt určuje počet doprovodných bajtů a výchozí rozdíl. Všimněte si že bajt resetu 0xFF není chráněn a může se z něj stát doprovodný bajt.

Patent

Obecný algoritmus BOCU se vztahuje k patentovému právu Spojených států amerických #6737994, který rovněž zmiňuje konkrétní provedení BOCU-1. Firma IBM, která v době, kdy byl vytvořen formát BOCU-1, zaměstnávala oba jeho tvůrce, uvedla v technických poznámkách Unicodu že realizátoři „plně kompatibilní verze BOCU-1“ musí kontaktovat IBM s žádostí o royalty-free licenci. BOCU-1 je pouze kompresní schéma Unicodu popsané na webových stránkách Unicode, kde je známo že je zatížen omezením duševního vlastnictví.

Například v IBM také žádali o patent na UTF-EBCDIC, ale nakonec uvolnily dokumentaci a kódování znaků „volně k dispozici všem zúčastněným za účelem výroby transformačního formátu jako součást UCS standardů“, místo aby požádali o licenci.

Reference

V tomto článku byl použit překlad textu z článku Binary Ordered Compression for Unicode na anglické Wikipedii.