Loading article…
バイナリ順序圧縮（BOCU）は、MIME互換のUnicode圧縮方式です。BOCU-1は、UTF-8の幅広い適用性と、 Unicode標準圧縮方式（SCSU）のコンパクトさを兼ね備えています。このUnicodeエンコーディングは、短い文字列の圧縮に役立ち、コードポイントの順序を維持するように設計されています。BOCU-1は、Unicodeテクニカルノートで規定されています。[ 1 ]
比較のために、SCSU は、言語固有のコードページと同様のバイト対コードポイント比を持つ標準 Unicode 圧縮方式として採用されました。SCSU は、MIME の「テキスト」メディアタイプには適していないため、広く採用されていません。たとえば、SCSU は電子メールや同様のプロトコルで直接使用することはできません。SCSU は、良好なパフォーマンスを得るために複雑なエンコーダ設計を必要とします。通常、zip、bzip2、およびその他の業界標準アルゴリズムは、より多くの Unicode テキストをより効率的に圧縮します。[ 2 ]
SCSU [ 3 ]と BOCU-1 [ 4 ]はどちらもIANA に登録された文字セットです。
このセクションの数値はすべて16進数であり、すべての範囲は両端を含みます。
U+0000からまでのコードポイントはU+0020、BOCU-1 では対応するバイト値としてエンコードされます。その他のすべてのコードポイント (つまり、U+0021からまで、U+D7FFおよびU+E000からまでU+10FFFF) は、コードポイントと、ASCII スペース ( ) ではなかった直近にエンコードされたコードポイントの正規化バージョンとの差分としてエンコードされますU+0020。初期状態は ですU+0040。正規化マッピングは次のとおりです。
現在のコードポイントと正規化された前のコードポイントとの差は、次のようにエンコードされます。
各バイト範囲は、次の 13 バイト値を除外して辞書式順序で並べられます00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20。たとえば、FC 06 FFの差を表すバイトシーケンス の直後には、 の差を表す1156Bバイトシーケンス が続きます。FC 10 011156C
スペースを除くU+0000ASCII入力はすべてエンコーダを にリセットします。上記の値は行末コードポイントとをカバーしているため（ ）、エンコーダは各行の先頭で既知の状態になります。したがって、1バイトの破損は最大で1行に影響します。比較のために、 UTF-8では1バイトの破損は最大で1つのコードポイントに影響しますが、SCSUではドキュメント全体に影響を与える可能性があります。U+007FU+0020U+0040U+000DU+000A0D 0A
BOCU-1 は、特別なリセット コードを使用することで、上記の値を含まない入力テキストに対しても同様の堅牢性を提供します。デコーダがこのオクテットを見つけると、行末の場合と同様0xFFに状態をリセットします。リセット バイトの使用は、BOCU-1 の他の設計目標、特にバイナリ順序と矛盾するため、BOCU-1 仕様では推奨されていません。U+00400xFF
U+FEFFBOCU-1 エンコードされたテキストの先頭にシグネチャ（BOCU-1 バイトシーケンス）をオプションで使用するとFB EE 28、初期状態U+0040が に変更されますU+FEC0。つまり、他のほとんどの Unicode エンコード方式のように、シグネチャを単純に削除することはできません。シグネチャの後にリセットバイト（FB EE 28 FF）を追加することでこの影響を回避できますが、BOCU-1 仕様ではこの方法は推奨されていません。
理論上、UTF-1とUTF-8は、最大31ビットのオリジナルのUCS-4セットをエンコードできます7FFFFFFF。BOCU-1とUTF-16は、からまでの最新のUnicodeセットをエンコードできます。単一のオクテットとしてエンコードされた13個の保護されたコードポイントを除くと、BOCU-1はを使用できます。U+0000U+10FFFFマルチバイトエンコーディングではオクテットを使用します。BOCU-1では、先頭バイト1つと末尾バイト1～3つからなる最大4バイトが必要です。末尾バイトは残りの「モジュロ243」（基数243）差をエンコードし、先頭バイトは末尾バイトの数と初期差を決定します。リセットバイトは保護され0xFFておらず、末尾バイトとして使用できます。
2022年11月16日以前は、一般的なBOCUアルゴリズムは米国特許第6,737,994号でカバーされており、この特許には特定のBOCU-1実装についても記載されています。[ 5 ]この特許は現在失効しています。
BOCU-1が作成された当時、その発明者2名を雇用していたIBMは、Unicodeテクニカルノートの中で、「BOCU-1の完全準拠バージョン」の実装者は、ロイヤリティフリーのライセンスを要求するためにIBMに連絡する必要があると述べている。 [ 6 ] BOCU-1は、知的財産権の制限を受けていることが知られているUnicode Webサイトで説明されている唯一のUnicode圧縮方式である。
対照的に、IBMもUTF-EBCDICの特許を出願したが、その場合は実装者にライセンスを要求するのではなく、「変換フォーマットをUCS標準の一部として作成することに関心のあるすべての人に自由に利用できるように」ドキュメントとエンコーディング方式を提供することを選択した。 [ 7 ]
W3CおよびWHATWG のHTML 標準では、 HTML文書で BOCU-1 (および SCSU、CESU-8、UTF-7、EBCDIC、UTF-32) をサポートすることを禁止しています[ 8 ] [ 9 ]。これは、HTML が非 ASCII 互換のエンコーディングを念頭に置いて設計されていないためです。過去には、ブラウザがそのようなエンコーディングを適切に処理できないために、クロスサイトスクリプティングの脆弱性が実証されています。[ 10 ]
