BOCU

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ů.[2] 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.[3] Obě znakové sady SCSU[4] a BOCU-1[5] jsou registrované u organizace IANA.

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í:

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ě:

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.

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.[6] 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.[7] 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.[8]

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