Unicode の標準圧縮方式( SCSU) [ 1 ]は、 Unicode テキストを表現するために必要なバイト数を削減するためのUnicode技術標準です。特に、テキストが言語ごとに 1 つまたは少数の文字ブロックの文字を主に使用する場合に役立ちます。SCSU は、128 ~ 255 の範囲の値を 128 文字の特定のブロック内のオフセットに動的にマッピングすることでこれを実現します。エンコーダの初期条件により、 NULL、TAB、CR、LF 以外の C0 制御コードを含まないASCIIおよびISO-8859-1の既存の文字列は、SCSU 文字列として扱うことができます。ほとんどのアルファベットは連続した Unicode コードポイントのブロックに存在するため、小さなアルファベットと ASCII 句読点、またはメインアルファベットのウィンドウ内に収まる句読点を使用するテキストは、1 文字あたり 1 バイト (セットアップ オーバーヘッドも含む。一般的な言語の場合は、通常 1 バイトのみ) でエンコードできます。その他のほとんどの句読点は、非ロック シフトにより、1 シンボルあたり 2 バイトでエンコードできます。 SCSUは、非アルファベット言語を処理するために、内部的にUTF-16に切り替えることもできます。
ロイターは当初SCSUを開発し、その後RCSU(Reuters Compression Scheme for Unicode)という名称で開発しました。[ 2 ] [ 3 ] [ 4 ] [ 5 ]
当初、Unicode Consortium はこれを文字エンコーディングと考えていましたが、[ 6 ] 1999 年に考えを変えました。転送エンコーディング構文とみなされていましたが、同じテキストに対して異なる圧縮方式が異なる出力を生成する可能性があるため、しばらくの間は文字エンコーディングとはみなされなくなりました。[ 7 ]しかし、2004 年にこの決定は覆され、現在 SCSU は単純文字エンコーディング方式や複合文字エンコーディング方式とは対照的に、圧縮文字エンコーディング方式とみなされています。[ 8 ] [ 9 ]
Roman Czyborra ( GNU Unifontの) がデコンプレッサを作成しました。[ 10 ] IBM が提供したデコンプレッサは、Java で書かれたコンプレッサとともに、International Components for Unicodeに含まれています。 [ 11 ]よりシンプルな参照コーデックは、TR6 の添付ファイルとして利用できます。
携帯電話やその他のモバイルデバイス向けのオペレーティングシステムであるSymbian OSは、文字列をシリアル化するためにSCSUを使用します。
SQL Server 2008 R2は SCSU を使用して、nchar(n)およびnvarchar(n)列に格納されているUnicode 値 ( UCS-2エンコーディングの文字列の意味) を圧縮し、データの言語に応じて 15% ~ 50% のスペース削減を実現します ( UTF-8では Unicode のASCIIサブセットに対してのみ 50% の削減となります)。[ 12 ]
以下のセクションでは、圧縮されたSCSUストリームの構造について簡単に説明します。詳細な説明(デコンプレッサーの説明と一致するもの)については、UTS #6文書を参照してください。
SCSUはシングルバイトモードで起動し、圧縮されたWindowエンコーディングを使用します。UTF-16BE「Unicode」モードに切り替えるコマンド、およびそのモードからシングルバイトモードに切り替えるコマンドが用意されています。
SCSUの中核は、バイト0x80~0xffの意味が定義されているウィンドウにあります。シンプルな文字体系や句読点用の静的ウィンドウが8種類、より多くの文字を使用する文字体系用の動的ウィンドウが6種類(加えて「ハーフUnicodeブロック」ウィンドウと補助プレーン用のカスタムウィンドウ)あります。
単純ウィンドウと動的ウィンドウはどちらも、特殊なコマンド文字で選択できます。現在のブロックに収まらない個々の文字については、引用符で囲むためのコマンド文字が用意されています。
UTF-16 または UTF-8 テキストは、Unicode 以前のエンコーディングの同等のテキストよりも多くのスペースを占有する可能性があるため、この問題を軽減するために SCSU などの圧縮を使用したい場合があります。[ 13 ]汎用圧縮と比較すると、SCSU を使用することが必ずしも有利とは限りません。[ 5 ]また、テキスト エンコーディングとして使用できますが、アルゴリズムの状態依存性のため、基本的なテキスト操作が自明ではなくなるため、内部テキスト表現として使用すると困難が生じる可能性があります。
SCSUを純粋に圧縮アルゴリズムとして扱うと、数キロバイトを超えるテキストに対しては、一般的に使用されている汎用アルゴリズムのほとんどよりも劣る。
SCSUには、わずか数文字のテキストでも効果的に圧縮できるという利点があります。一方、ほとんどの本格的な圧縮ツールは、自身のオーバーヘッドに見合うだけの処理量を得るために数百バイトのデータを必要とします。Symbian OSでは、SCSUはクリップボード操作、例えば短い文字列の切り取り、コピー、貼り付けにも使用されています。
W3CおよびWHATWG のHTML 標準では、 HTML は非 ASCII 互換のエンコーディングを念頭に置いて設計されていないため、 HTMLドキュメントで SCSU (および BOCU-1、CESU-8、UTF-7、EBCDIC、UTF-32) をサポートすることを禁止しています[ 14 ] [ 15 ]。過去には、ブラウザがそのようなエンコーディングを適切に処理できないために、クロスサイトスクリプティングの脆弱性が実証されています。[ 16 ]
はコンパクトなエンコーディングを定義しており、これは時として有用です。しかし、Unicode テキストは、よりコンパクトではない ( ASCIIを除く)、はるかに単純で、セキュリティ上の問題も発生しないUTF-8で保存および送信されることがはるかに一般的です。長いテキストの場合、汎用圧縮が効果的で一般的です。