Binarna uporządkowana kompresja dla Unicode

„BOCU” przekierowuje tutaj. W przypadku innych zastosowań zobacz BOCU (ujednoznacznienie) .

Binary Ordered Compression for Unicode ( BOCU ) to schemat kompresji Unicode zgodny z MIME . BOCU-1 łączy szerokie zastosowanie UTF-8 ze zwartością standardowego schematu kompresji dla Unicode (SCSU). To kodowanie Unicode jest przeznaczone do kompresji krótkich ciągów i zachowuje kolejność punktów kodowych. BOCU-1 jest określony w nocie technicznej Unicode.

Dla porównania SCSU przyjęto jako standardowy schemat kompresji Unicode ze stosunkiem bajtów do punktów kodowych podobnym do stron kodowych specyficznych dla języka . SCSU nie został powszechnie przyjęty, ponieważ nie nadaje się do „tekstowych” typów mediów MIME. Na przykład SCSU nie można używać bezpośrednio w wiadomościach e-mail i podobnych protokołach. SCSU wymaga skomplikowanej konstrukcji enkodera dla dobrej wydajności. Zazwyczaj algorytmy zip , bzip2 i inne standardowe algorytmy branżowe skuteczniej kompaktują większe ilości tekstu Unicode.

Zarówno SCSU, jak i BOCU-1 są zestawami znaków zarejestrowanymi przez IANA .

Detale

Wszystkie liczby w tej sekcji są szesnastkowe , a wszystkie zakresy są włącznie.

Punkty kodowe od U+0000 do U+0020 są kodowane w BOCU-1 jako odpowiednia wartość bajtu. Wszystkie inne punkty kodowe (tj. U+0021 do U+D7FF i U+E000 do U+10FFFF ) są kodowane jako różnica między punktem kodowym a znormalizowaną wersją ostatnio zakodowanego punktu kodowego, który nie był spacją ASCII ( U+0020 ). Stan początkowy to U+0040 . Mapowanie normalizacji wygląda następująco:

Zakres kodu	Znormalizowany punkt kodowy	Notatki
U+3040 do U+309F	U+3070	Hiragana
U+4E00 do U+9FA5	U+7711	Unihan
U+AC00 do U+D7A3	U+C1D1	Hangul
U+0020	stan enkodera zachowany bez zmian	Przestrzeń
U+ hhhh 00 do U+ hhhh 7F (z wyłączeniem zakresów powyżej)	U+hhhh40	środek 128
U+ hhhh 80 do U+ hhhh FF (z wyłączeniem zakresów powyżej)	U+ hhhh C0	środek 128

Różnica między bieżącym punktem kodowym a znormalizowanym poprzednim punktem kodowym jest kodowana w następujący sposób:

Zakres różnicy	Zakres sekwencji bajtów (patrz poniżej)
-10FF9F do -2DD0D	21 F0 58 D9 do 21 FF FF FF
-2DD0C do -2912	22 01 01 do 24 FF FF
-2911 do -41	25 01 do 4F FF
-40 do 3F	50 do CF
40 do 2910	D0 01 do FA FF
2911 do 2DD0B	FB 01 01 do FD FF FF
2DD0C do 10FFBF	FE 01 01 01 do FE 19 B4 54

Każdy zakres bajtów jest uporządkowany leksykograficznie z wykluczeniem następujących trzynastu bajtów: 00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20 . Na przykład, po sekwencji bajtów FC 06 FF , kodującej różnicę 1156B , następuje bezpośrednio po sekwencji bajtów FC 10 01 , kodującej różnicę 1156C .

Każde wejście ASCII od U+0000 do U+007F z wyłączeniem spacji U+0020 resetuje koder do U+0040 . Ponieważ powyższe wartości obejmują punkty kodowe końca linii U+000D i U+000A w obecnej postaci ( 0D 0A ), koder jest w znanym stanie na początku każdej linii. Uszkodzenie pojedynczego bajtu wpływa zatem co najwyżej na jedną linię. Dla porównania, uszkodzenie pojedynczego bajtu w UTF-8 dotyczy co najwyżej jednego punktu kodowego, w przypadku SCSU może dotyczyć całego dokumentu.

BOCU-1 oferuje podobną solidność również dla tekstów wejściowych bez wyżej wymienionych wartości ze specjalnym kodem resetowania 0xFF . Kiedy dekoder znajdzie ten oktet, resetuje swój stan do U+0040 jak dla końca linii. Użycie 0xFF nie jest zalecane w specyfikacji BOCU-1, ponieważ jest to sprzeczne z innymi celami projektowymi BOCU-1, zwłaszcza z porządkiem binarnym .

Opcjonalne użycie podpisu U+FEFF na początku tekstów zakodowanych w BOCU-1, tj. sekwencji bajtów BOCU-1 FB EE 28 , zmienia stan początkowy U+0040 na U+FEC0 . Innymi słowy, podpisu nie można po prostu usunąć, jak w większości innych schematów kodowania Unicode. Dodanie bajtu resetowania po podpisie ( FB EE 28 FF ) mogłoby uniknąć tego efektu, ale specyfikacja BOCU-1 nie zaleca tej praktyki.

Teoretycznie UTF-1 i UTF-8 mogą kodować oryginalny zestaw UCS-4 z 31 bitami do 7FFFFFFF . BOCU-1 i UTF-16 mogą kodować nowoczesny zestaw Unicode od U+0000 do U+10FFFF . $.$ trzynaście chronionych punktów -1 może używać oktetów w wielobajtowym BOCU-1 potrzebuje co najwyżej czterech bajtów składających się z bajtu wiodącego i jednego do trzech bajtów końcowych. Bajty śladu kodują pozostałą różnicę „ moduł 243” (podstawa 243), bajt wiodący określa liczbę bajtów śladu i początkową różnicę. Należy zauważyć, że bajt resetowania 0xFF nie jest chroniony i może występować jako bajt końcowy.

Patent

Przed 16 listopada 2022 r. ogólny algorytm BOCU był objęty patentem Stanów Zjednoczonych nr 6 737 994, w którym wspomniano również o konkretnej implementacji BOCU-1. Ten patent już wygasł.

IBM , który zatrudniał obu wynalazców BOCU-1 w momencie jego tworzenia, stwierdził w nocie technicznej Unicode, że osoby wdrażające „w pełni zgodną wersję BOCU-1” musiały skontaktować się z IBM w celu uzyskania bezpłatnej licencji. BOCU-1 to jedyny schemat kompresji Unicode opisany w witrynie internetowej Unicode, o którym wiadomo, że jest obciążony ograniczeniami dotyczącymi własności intelektualnej .

Z kolei IBM złożył również wniosek o patent na UTF-EBCDIC , ale w tym przypadku zdecydował się udostępnić dokumentację i schemat kodowania „nieodpłatnie każdemu zainteresowanemu uczynieniem formatu transformacji jako części standardów UCS”, zamiast wymagać od wdrożeniowców poprosić o licencję.

Zobacz też

• UTF-1 zawiera porównanie projektów UTF-1, UTF-8 i BOCU-1
• International Components for Unicode Biblioteka, która może konwertować między BOCU-1 i innymi kodowaniami Unicode