統一碼二進制有序壓縮：修订间差异

'''統一碼二進制有序壓縮'''（{{Lang-en|Binary Ordered Compression for Unicode}}，縮寫：'''BOCU'''） 是統一碼技術注解文件所定義的規範<ref name=":0" />，可以兼容[[多用途互聯網郵件擴展|MIME]]的統一碼压缩方案。

雖然[[UTF-8]]適合廣泛使用，但對於非拉丁文和[[中日韓統一表意文字]]的文字，相較於[[代码页]]技術，它佔用了更多的空間（較高的 "字節 / 碼位" 之比）。另一方面，SCSU 佔用的空間與代碼頁差不多，但卻不相容於MIME。二進制有序壓縮則结合了[[UTF-8]]的廣泛適用性和[[統一碼標準壓縮方案]]（SCSU）的紧凑性。<ref name=":0">{{Cite web|title=UTN #6: BOCU-1: MIME-COMPATIBLE UNICODE COMPRESSION|url=https://www.unicode.org/notes/tn6/|access-date=2008-05-18|author=Markus Scherer, [[Mark Davis (Unicode)|Mark Davis]]|date=2006-02-04}}</ref>

BOCU-1 是[[互联网号码分配局|IANA]]注册的字符集<ref>[https://www.iana.org/assignments/charset-reg/BOCU-1 IANA 中 BOCU-1 的註冊記錄]</ref>。

本章節中使用的數字都是[[十六進制]]，且使用的範圍都是包含在内。

統一碼二進位有序壓縮的核心概念在於：同一種語言的字符，通常被放在鄰近位置（同一區段內），所以文件中的一個字符與前一個字符碼值的差值是小的，可以用較少的字節來編碼。

而實際作法上，不是直接使用前一個字符的碼值，而是前一固字符歸一化的碼值，即所在區段的中間值。其對應如下：

! style="width: auto;" |編碼范围

! style="width: auto;" |歸一化碼值

|[[中日韓統一表意文字]]

此壓縮法的規則為，<code>U+0000</code>到<code>U+002的</code>的码位使用其原本的值。其他码位（即<code>U+0021</code>到<code>U+D7FF</code>和<code>U+E000</code>到<code>U+10FFFF</code> ），則計算其與前一個字符的歸一化版本的碼值差值，並對此差值編碼。

差值的編碼規則如下：

! style="width: auto;" |差值範圍

每个位元范围按[[字典序|字典顺序]]排序，但不包括以下十三个字节值： <code>00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20</code> 。例如，差值為 <code>1156B</code> 的編碼，其字節序列 <code>FC 06 FF</code> 。紧接着差值為 <code>1156C</code> 的編碼，是字节序列<code>FC 10 01</code> （第三個字節，從 <code>FF</code> 跳過了 <code>00</code> 到 <code>01</code> ，而第二個字節，從 <code>06</code> 跳過了 <code>07 08 09 0A 0B 0C 0D 0E 0F</code> 到 <code>10</code>）。

除了空格<code>U+0020</code>為例外，對所有 ASCII 字符<code>U+0000</code>到<code>U+007F</code>，编码器會重置为<code>U+0040</code> 。由於上述的'''按原样'''包含了行尾码位<code>U+000D</code>和<code>U+000A</code> (<code>0D 0A</code> )，因此编码器在每行的开头处于已知状态。因此，单个字节的损坏最多影响一行。相比之下，[[UTF-8]]单个字节的损坏最多影响一个字符，对于SCSU来说，則可能會影响整个文档。

對於没有上述值的文本，BOCU-1 亦提供了类似的穩健性，带有特殊的重置代码<code>0xFF</code> 。当解码器找到这个八位字节时，它会将其状态重置为<code>U+0040</code>就像行尾一样。 BOCU-1 规范中不推荐使用<code>0xFF</code>复位字节，因为它与其他 BOCU-1 设计目标相冲突，尤其是''二进制顺序''。

在BOCU-1编码文本的开始处，可選擇地使用签名[[位元組順序記號|<code>U+FEFF</code>]]，其字節串列為 <code>FB EE 28 ，</code>會将初始状态由<code>U+0040改</code>为<code>U+FEC0</code> 。换句话说，無法像其他大多數的統一碼编码方案一样简单地剥离簽名。若額外添加一個復位字節，使之成為字節順序 <code>FB EE 28 FF</code> ，則可以避免这种影响，但 BOCU-1 规范不推荐这种做法。

理论上，[[UTF-1]]和[[UTF-8]]可以為原始[[通用字符集|UCS-4]]集（使用 31 位元、上到<code>7FFFFFFF）</code>編碼。 BOCU-1 和[[UTF-16]]可以為現代[[統一碼]]集（<code>U+0000</code>到<code>U+10FFFF）</code>。排除 13 個受保護碼位外， BOCU-1 单个位元組可以為 <math>256 - 13 = 243</math>多字节编码。 BOCU-1 最多需要四个位元組，包括一个前导字元和一到三个尾端位元組。尾字节编码剩余的“[[模除|模]]243”（基数 243）差，前导字节确定尾字节数和初始差。请注意，复位字节<code>0xFF</code>不受''保护''，可以作为尾字节出现。

在美国专利#6,737,994 中，涵盖了通用 BOCU 算法，同時还提到了特定的 BOCU-1 实现。 <ref>{{Cite web|title=United States Patent #6,737,994, "Binary-ordered compression for unicode"|url=http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6737994.PN.&OS=PN/6737994&RS=PN/6737994|access-date=2008-11-16|author=Davis|date=2004-05-18|authorlink=Mark Davis (Unicode)|subscription=etal}}</ref>[[IBM]]當時雇用了 BOCU-1 的两位发明者，在統一碼技术说明中指出「完全兼容的 BOCU-1 版本」的实现者必须联系 IBM 以申请免版税许可。 <ref>{{Cite web|title=UTN #6: BOCU-1|url=https://www.unicode.org/notes/tn6/#Intellectual_Property|access-date=2014-02-05|author=Markus Scherer, [[Mark Davis (Unicode)|Mark Davis]]|date=2006-02-04}}</ref>BOCU-1 是統一碼网站上，目前唯一已知的受到[[知识产权]]限制的統一碼压缩方案。

相比之下，IBM 也為UTF-EBCDIC申請专利，但它选择使文档和[[字符编码|编码方案]]不要求對實施者申請許可證，而是「任何将轉換格式成为 UCS 标准的一部分，將對他們們免费提供」。 <ref>{{Cite web|title=UTR #16: UTF-EBCDIC|url=https://www.unicode.org/reports/tr16/#Bibliography|access-date=2008-11-16|author=V.S. Umamaheswaran|date=2002-04-16}}</ref>

== 另見 ==

[[Category:Unicode轉換格式]]