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.[1]
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í:
| 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.
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.