もう 30 つのバイク: Unicode 文字列を UTF-60 よりも 8 ～ XNUMX% コンパクトに保存します

あなたが開発者で、エンコーディングを選択するという課題に直面している場合、ほとんどの場合、Unicode が適切なソリューションとなるでしょう。 具体的な表現方法はコンテキストによって異なりますが、ほとんどの場合、ここでも普遍的な答え、つまり UTF-8 が存在します。 これの良い点は、費用をかけずにすべての Unicode 文字を使用できることです。 あまりにも ほとんどの場合、バイト数が多くなります。 確かに、ラテン文字以上のものを使用する言語では、少なくとも「多すぎない」ということです。 XNUMX文字あたりXNUMXバイト。 使用できる文字数が 256 文字に制限されている先史時代のエンコーディングに戻らずに、もっとうまくできるでしょうか?

以下では、この質問に答えるための私の試みを理解し、UTF-8 のような冗長性を追加することなく、世界中のほとんどの言語で行を保存できる比較的単純なアルゴリズムを実装することを提案します。

免責事項。 すぐにいくつかの重要な予約をしておきます。 説明されているソリューションは、UTF-8 の汎用的な代替として提供されていません。、これは限られたケースのリストにのみ適しており (詳細は後述します)、いかなる場合でも、サードパーティ API (それについてさえ知らない) との対話に使用すべきではありません。 ほとんどの場合、汎用圧縮アルゴリズム (deflate など) は、大量のテキスト データをコンパクトに保存するのに適しています。 さらに、すでにソリューションを作成している途中で、同じ問題を解決する Unicode 自体の既存の標準を見つけました。これはやや複雑です (そして多くの場合、より悪いものです)。しかし、それでも受け入れられている標準であり、単なる定義ではありません。一緒に膝の上に。 彼のことについてもお話します。

Unicode と UTF-8 について

まず、それが何であるかについて少し説明します Unicode и UTF-8.

ご存知のとおり、かつては 8 ビット エンコーディングが一般的でした。 これらを使用すると、すべてが簡単になりました。256 文字に 0 から 255 までの数字を付けることができ、0 から 255 までの数字は明らかに 7 バイトとして表すことができます。 最初に戻ると、ASCII エンコードは完全に 8 ビットに制限されているため、バイト表現の最上位ビットはゼロであり、ほとんどの XNUMX ビット エンコードと互換性があります (「上位」のみが異なります)。の部分、最上位ビットは XNUMX です)。

Unicode はこれらのエンコーディングとどのように異なりますか?また、Unicode に非常に多くの特定の表現 (UTF-8、UTF-16 (BE および LE)、UTF-32) が関連付けられているのはなぜですか? 順番に整理してみましょう。

基本的な Unicode 標準では、文字 (場合によっては文字の個々のコンポーネント) とその数値の間の対応関係のみが記述されています。 そして、この標準には多くの可能な数値があります - 0x00 до 0x10FFFF (1 個)。 このような範囲の数値を変数に入れたい場合、114 バイトでも 112 バイトでも十分ではありません。 そして、私たちのプロセッサは 1 バイトの数値を扱うようにあまり設計されていないため、2 文字あたり最大 4 バイトを使用することになります。 これがUTF-32なのですが、この「無駄」があるからこそこの形式が普及しないのです。

幸いなことに、Unicode 内の文字の順序はランダムではありません。 セット全体は17インチに分かれています。飛行機"、それぞれに 65536 (0x10000）«コードポイント」 ここでの「コードポイント」の概念は簡単に言うと、 文字番号、Unicodeによって割り当てられます。 しかし、上で述べたように、Unicode では個々の文字だけでなく、そのコンポーネントやサービス マークにも番号が付けられます (そして、場合によっては番号にまったく対応しないこともあります。おそらく当面は、これは私たちにとってはそれほど重要ではありません)。記号ではなく、常に数字自体の数について具体的に話すのがより正確です。 ただし、以下では、簡潔にするために、「コード ポイント」という用語を暗示するために、「シンボル」という言葉を頻繁に使用します。

Unicode プレーン。 ご覧のとおり、そのほとんど (面 4 ～ 13) はまだ使用されていません。

最も注目すべきことは、すべての主要な「パルプ」がゼロ面にあることです。これは「」と呼ばれます。基本多言語プレーン"。行に現代言語 (中国語を含む) のテキストが含まれている場合、この平面を超えることはできません。ただし、Unicode の残りの部分を切り取ることもできません。たとえば、絵文字は主に行の最後にあります。次の飛行機ですよ」補足多言語面「（から伸びています） 0x10000 до 0x1FFFF）。 したがって、UTF-16 では次のようになります。すべての文字が以下の範囲に含まれます。 基本多言語プレーン、対応する XNUMX バイトの数値を使用して「そのまま」エンコードされます。 ただし、この範囲の数値の一部は特定の文字をまったく示していませんが、このバイトのペアの後に別のバイトを考慮する必要があることを示しています。これらの XNUMX バイトの値を組み合わせることで、以下の範囲をカバーする数値が得られます。有効な Unicode 範囲全体。 この考え方は「代理カップル」と呼ばれており、聞いたことがあるかもしれません。

したがって、UTF-16 では、「コード ポイント」ごとに 8 バイト、または (非常にまれなケースでは) XNUMX バイトが必要になります。 これは、常に XNUMX バイトを使用するよりは優れていますが、ラテン語 (および他の ASCII 文字) をこの方法でエンコードすると、ゼロのスペースの半分が無駄になります。 UTF-XNUMX はこれを修正するように設計されています。以前と同様に、その中の ASCII は XNUMX バイトのみを占めます。 からのコード 0x80 до 0x7FF - XNUMXバイト; から 0x800 до 0xFFFF - XNUMXつ、そしてから 0x10000 до 0x10FFFF - 四。 一方で、ラテン文字は良くなりました。ASCII との互換性が戻り、分布は 1 バイトから 4 バイトまでより均等に「分散」されました。 しかし、残念ながら、ラテン語以外のアルファベットには UTF-16 と比べて何のメリットもありません。多くのアルファベットでは 32 バイトではなく XNUMX バイトが必要になります。XNUMX バイトのレコードでカバーされる範囲は XNUMX 分の XNUMX に狭まっています。 0xFFFF до 0x7FF、中国語も、たとえばグルジア語も含まれていません。 キリル文字とその他の 2 つのアルファベット - 万歳 - 幸運、XNUMX 文字あたり XNUMX バイト。

なぜこのようなことが起こるのでしょうか? UTF-8 が文字コードをどのように表現するかを見てみましょう。

数値を直接表すために、ここでは記号の付いたビットが使用されます。 x。 11 バイトのレコードには、そのようなビットが (16 個中) 21 個しかないことがわかります。 ここの先頭ビットには補助的な機能しかありません。 32 バイトのレコードの場合、24 ビットのうち XNUMX ビットがコード ポイント番号に割り当てられます。XNUMX バイト (合計 XNUMX ビット) で十分であるように見えますが、サービス マーカーが多くを消費します。

これはダメですか？ あまり。 一方で、スペースを重視する場合は、余分なエントロピーと冗長性をすべて簡単に除去できる圧縮アルゴリズムがあります。 一方、Unicode の目標は、可能な限り最も汎用的なコーディングを提供することでした。 たとえば、UTF-8 でエンコードされた行を、以前は ASCII でのみ機能していたコードに委ねることができ、実際には存在しない ASCII 範囲の文字が表示されることを心配する必要はありません (結局のところ、UTF-8 ではすべてゼロビットから始まるバイト - これがまさに ASCII です)。 また、最初からデコードせずに、大きな文字列から小さな末尾を突然切り取りたい場合 (または、破損したセクションの後に情報の一部を復元したい場合)、文字が始まるオフセットを見つけるのは簡単です (これで十分です)ビットプレフィックスを持つバイトをスキップするには 10).

では、なぜ何か新しいものを発明するのでしょうか？

同時に、deflate などの圧縮アルゴリズムはあまり適用できないが、文字列をコンパクトに保存したい場合もあります。 個人的には、構築を考えているときにこの問題に遭遇しました 圧縮されたプレフィックス ツリー 任意の言語の単語を含む大規模な辞書の場合。 一方で、各単語は非常に短いため、圧縮しても効果がありません。 一方、私が検討したツリー実装は、格納された文字列の各バイトが個別のツリー頂点を生成するように設計されていたため、頂点の数を最小限に抑えることが非常に役に立ちました。 私の図書館で Az.js (のように ピモーフィ2に基づいています) 同様の問題は簡単に解決できます - にパックされた文字列 DAWG-辞書、そこに保存されています 懐かしいCP1251。 しかし、容易に理解できるように、これは限られたアルファベットに対してのみうまく機能します。中国語の行をそのような辞書に追加することはできません。

これとは別に、このようなデータ構造で UTF-8 を使用するときに生じるもう XNUMX つの不快なニュアンスに注意したいと思います。 上の図は、文字が XNUMX バイトで書き込まれる場合、その番号に関連するビットが連続せず、XNUMX 対のビットで区切られていることを示しています。 10 真ん中に： 110xxxxx 10xxxxxx。 このため、文字コードの6バイト目の下位XNUMXビットがオーバーフローした場合（遷移が発生した場合）、 10111111 → 10000000)、最初のバイトも変更されます。 文字「p」はバイトで表されることがわかります 0xD0 0xBF、次の「r」はすでに 0xD1 0x80。 プレフィックス ツリーでは、これにより親ノードが XNUMX つに分割され、XNUMX つはプレフィックス用になります。 0xD0、もうXNUMXつは 0xD1 (ただし、キリル文字全体は XNUMX バイト目でのみエンコードできます)。

何を手に入れましたか

この問題に直面して、私はビットを使ってゲームをプレイする練習をし、同時に Unicode 全体の構造をもう少しよく理解することにしました。 結果は UTF-C エンコード形式 (「C」は コンパクト）、コード ポイントごとに 3 バイト以下しか消費せず、多くの場合、使用できるのは XNUMX バイトのみです。 エンコードされた行全体に XNUMX バイト追加。 これは、多くの非 ASCII アルファベットでは、そのようなエンコーディングが次のようになるという事実につながります。 UTF-30 より 60 ～ 8% コンパクト.

エンコードおよびデコードアルゴリズムの実装例を次の形式で紹介しました。 JavaScript および Go ライブラリ、コード内で自由に使用できます。 ただし、この形式はある意味「自転車」のままであり、使用はお勧めしません。 なぜそれが必要なのかも知らずに。 これは、本格的な「UTF-8 の改良」というよりは、まだ実験にすぎません。 それにもかかわらず、コードはきちんと簡潔に書かれており、多数のコメントとテスト カバレッジが含まれています。

テスト結果とUTF-8との比較

私もそうしました デモページでは、アルゴリズムのパフォーマンスを評価できます。その後、その原理と開発プロセスについて詳しく説明します。

冗長ビットの削除

もちろん、私は UTF-8 をベースにしました。 この中で変更できる最初の最も明白な点は、各バイトのサービス ビット数を減らすことです。 たとえば、UTF-8 の最初のバイトは常に次のいずれかで始まります。 0、または 11 - 接頭辞 10 次のバイトのみがそれを持っています。 接頭辞を置き換えてみましょう 11 на 1、次のバイトではプレフィックスを完全に削除します。 何が起こるか？

0xxxxxxx — 1バイト
10xxxxxx xxxxxxxx - 2バイト
110xxxxx xxxxxxxx xxxxxxxx - 3バイト

待って、21 バイトのレコードはどこにあるのでしょうか? しかし、それはもう必要ありません。XNUMX バイトで書き込む場合、現在は XNUMX ビットが利用可能であり、これは最大のすべての数値に対して十分です。 0x10FFFF.

私たちはここで何を犠牲にしたのでしょうか？ 最も重要なことは、バッファ内の任意の位置から文字境界を検出することです。 任意のバイトをポイントして、そこから次の文字の先頭を見つけることはできません。 これは私たちの形式の制限ですが、実際にはこれが必要になることはほとんどありません。 通常、バッファを最初から実行できます (特に短い行の場合)。

2 バイトで言語をカバーする状況も改善されました。現在、14 バイト形式では XNUMX ビットの範囲が与えられ、これらは最大で XNUMX ビットのコードになります。 0x3FFF。 中国人は不運だ（中国人の性格は主に以下のようなものである） 0x4E00 до 0x9FFF）しかし、グルジア人や他の多くの人々はもっと楽しんでいます - 彼らの言語も2文字あたりXNUMXバイトに収まります。

エンコーダ状態に入る

次に、線自体の性質について考えてみましょう。 ほとんどの場合、辞書には同じアルファベットの文字で書かれた単語が含まれており、これは他の多くのテキストにも当てはまります。 このアルファベットを一度指定して、その中の文字の番号だけを指定すると良いでしょう。 Unicode テーブル内の文字の配置が役立つかどうかを見てみましょう。

前述したように、Unicode は次のように分類されます。 飛行機 それぞれ65536コード。 しかし、これはあまり有用な分割ではありません (すでに述べたように、ほとんどの場合、私たちはゼロ平面にいます)。 さらに興味深いのは、による除算です。 ブロック。 これらの範囲には固定長がなくなり、より意味のあるものになりました。原則として、それぞれが同じアルファベットの文字を組み合わせたものになります。

ベンガル語のアルファベットの文字を含むブロック。 残念ながら、歴史的な理由により、これはあまり高密度にパッケージ化されていない例です。96 文字が 128 のブロック コード ポイントに無秩序に分散されています。

ブロックの先頭とそのサイズは常に 16 の倍数です。これは単に便宜上行われているだけです。 さらに、多くのブロックは 128 または 256 の倍数の値で始まり、終わります。たとえば、基本的なキリル文字は 256 バイトを占めます。 0x0400 до 0x04FF。 これは非常に便利です。プレフィックスを一度保存​​すると、 0x04の場合、任意のキリル文字を XNUMX バイトで書くことができます。 確かに、この方法では ASCII (および一般に他の文字) に戻る機会を失うことになります。 したがって、次のようにします。

1. XNUMXバイト 10yyyyyy yxxxxxxx 記号を数字で表すだけではありません yyyyyy yxxxxxxx、しかしまた変化します 現在のアルファベット на yyyyyy y0000000 (つまり、最下位ビットを除くすべてのビットを覚えています 7ビット);
2. XNUMXバイト 0xxxxxxx これは現在のアルファベットの文字です。 手順 1 で記憶したオフセットに追加するだけです。アルファベットは変更しませんでしたが、オフセットはゼロなので、ASCII との互換性を維持しました。

3 バイトを必要とするコードの場合も同様です。

1. XNUMXバイト 110yyyyy yxxxxxxx xxxxxxxx 記号を数字で示す yyyyyy yxxxxxxx xxxxxxxx、 変化 現在のアルファベット на yyyyyy y0000000 00000000 (若い子以外は全部覚えてた) 15ビット)、現在のボックスにチェックを入れます 長さ モード (アルファベットを全角に戻すとき、このフラグをリセットします)。
2. XNUMXバイト 0xxxxxxx xxxxxxxx ロングモードでは、現在のアルファベットの文字になります。 同様に、ステップ 1 のオフセットを使用してそれを追加します。唯一の違いは、(このモードに切り替えたため) XNUMX バイトを読み取ることです。

いいですね。同じ 7 ビット Unicode 範囲の文字をエンコードする必要があるときに、先頭に 1 バイト余分に費やし、文字ごとに合計 XNUMX バイトを費やします。

以前のバージョンのいずれかを使用しています。 すでに UTF-8 を上回ることがよくありますが、まだ改善の余地があります。

何が悪いの？ まず、条件があります。 現在のアルファベットのオフセット とチェックボックス ロングモード。 これによりさらに制限が加えられ、同じ文字が異なるコンテキストで異なる方法でエンコードされる可能性があります。 たとえば、部分文字列の検索は、単にバイトを比較するだけではなく、これを考慮して行う必要があります。 第二に、アルファベットを変更するとすぐに、ASCII 文字のエンコードが悪くなりました (これはラテン文字だけでなく、スペースを含む基本的な句読点も同様です)。アルファベットを再度 0 に変更する必要があります。もう一度追加のバイトを追加します (そして、本題に戻るためにもう XNUMX バイトを追加します)。

アルファベットは XNUMX 文字が良い、XNUMX 文字が良い

上記の XNUMX つにさらに XNUMX つを加えて、ビット プレフィックスを少し変更してみましょう。

0xxxxxxx — 通常モードでは 1 バイト、ロングモードでは 2 バイト
11xxxxxx — 1バイト
100xxxxx xxxxxxxx - 2バイト
101xxxxx xxxxxxxx xxxxxxxx - 3バイト

XNUMX バイトのレコードでは、利用可能なビットが XNUMX つ減りました。コード ポイントは最大 XNUMX バイトです。 0x1FFFとしない 0x3FFF。 ただし、依然として 8 バイトの UTF-XNUMX コードよりも著しく大きく、ほとんどの一般的な言語はまだ収まりますが、最も顕著な損失は抜け落ちています。 ひらがな и カタカナ、日本人は悲しいです。

この新しいコードは何ですか? 11xxxxxx? これは 64 文字の小さな「隠し場所」であり、メインのアルファベットを補完するものであるため、これを補助と呼びました (補助） アルファベット。 現在のアルファベットを切り替えると、古いアルファベットの一部が補助になります。 たとえば、ASCII からキリル文字に切り替えました。スタッシュには、次の内容を含む 64 文字が含まれるようになりました。 ラテン文字、数字、スペース、カンマ (非 ASCII テキストへの最も頻繁な挿入)。 ASCII に戻すと、キリル文字の主要部分が補助文字になります。

XNUMX つのアルファベットにアクセスできるため、アルファベットを切り替えるコストを最小限に抑えながら、大量のテキストを処理できます (句読点を使用すると、ほとんどの場合 ASCII に戻りますが、その後、追加のアルファベットから多くの非 ASCII 文字が取得されます。再度切り替えます）。

ボーナス: サブアルファベットの接頭辞 11xxxxxx そしてその初期オフセットを次のように選択します 0xC0、CP1252と部分的な互換性が得られます。 つまり、CP1252 でエンコードされた西ヨーロッパのテキストの多く (すべてではありません) は、UTF-C では同じように見えます。

しかし、ここで問題が発生します。メインのアルファベットから補助文字をどのように取得するかです。 同じオフセットをそのままにすることもできますが、残念なことに、ここでは Unicode 構造がすでに不利になっています。 多くの場合、アルファベットの主要部分はブロックの先頭にありません (たとえば、ロシアの大文字「A」には次のコードがあります) 0x0410ただし、キリル文字ブロックは次で始まります。 0x0400）。 したがって、最初の 64 文字を隠し場所に取り込むと、アルファベットの末尾の部分にアクセスできなくなる可能性があります。

この問題を解決するために、さまざまな言語に対応するいくつかのブロックを手動で調べ、それらのメイン アルファベット内の補助アルファベットのオフセットを指定しました。 例外として、ラテン文字は通常、base64 のように並べ替えられました。

最後の仕上げ

最後に、他に改善できる点を考えてみましょう。

形式に注意してください 101xxxxx xxxxxxxx xxxxxxxx までの数値をエンコードできます 0x1FFFFF、Unicode はより早く終了します。 0x10FFFF。 つまり、最後のコードポイントは次のように表されます。 10110000 11111111 11111111。 したがって、最初のバイトが次の形式である場合、次のように言えます。 1011xxxx （どこ xxxx 0 より大きい場合）、それは別の意味になります。 たとえば、そこにさらに 15 文字を追加して、常に XNUMX バイトのエンコードに利用できるようにすることもできますが、私は別の方法で行うことにしました。

21 バイトを必要とする Unicode ブロックを見てみましょう。 基本的に、すでに述べたように、これらは漢字ですが、XNUMX もの文字があるため、それを使って何かをするのは困難です。 しかし、ひらがなとカタカナもそこに飛んできました - そしてそれらの数はもうそれほど多くはなく、XNUMX未満です。 そして、日本語を覚えたので、絵文字もあります（実際、絵文字はUnicodeのさまざまな場所に散在していますが、主要なブロックは範囲内にあります） 0x1F300 – 0x1FBFF）。 現在、複数のコードポイントから一度に組み立てられた絵文字があるという事実を考えてみてください (たとえば、絵文字 ‍‍‍ 7 個ものコードで構成されている場合、それぞれに 7 バイトを費やすのはまったくの恥ずべきことになります (3 つのアイコンのために 21×XNUMX = XNUMX バイト、まさに悪夢です)。

したがって、絵文字、ひらがな、カタカナに対応する範囲をいくつか選択し、番号を付け直して XNUMX つの連続リストにし、XNUMX バイトではなく XNUMX バイトとしてエンコードします。

1011xxxx xxxxxxxx

素晴らしい: 前述の ‍‍‍ 絵文字は 7 つのコード ポイントで構成され、UTF-8 では 25 バイトを必要とし、次のように収まります。 14 (各コード ポイントに正確に XNUMX バイト)。 ちなみに、Habr は (古いエディタでも新しいエディタでも) ダイジェストすることを拒否したため、画像を挿入する必要がありました。

もう XNUMX つ問題を解決してみましょう。 私たちが覚えているように、基本的なアルファベットは本質的には 上位6ビットこれを念頭に置き、次にデコードされた各シンボルのコードに貼り付けます。 ブロック内の漢字の場合 0x4E00 – 0x9FFF、これはビット 0 または 1 のいずれかです。これはあまり便利ではありません。これら 10240 つの値の間でアルファベットを常に切り替える必要があります (つまり、XNUMX バイトを費やします)。 ただし、ロング モードでは、コード自体から、ショート モードを使用してエンコードした文字数を差し引くことができることに注意してください (上記のトリックをすべて実行すると、これは XNUMX になります)。そうすると、象形文字の範囲が にシフトします。 0x2600 – 0x77FFこの場合、この範囲全体を通じて、(6 のうちの) 最上位 21 ビットは 0 に等しくなります。したがって、象形文字のシーケンスは、象形文字ごとに XNUMX バイトを使用します (これは、このような広い範囲には最適です)。アルファベットが切り替わる原因となります。

代替ソリューション: SCSU、BOCU-1

Unicode の専門家は、この記事のタイトルを読んだだけで、Unicode 標準の中に次のものがあることをすぐに思い出されるでしょう。 Unicode の標準圧縮スキーム (SCSU)、この記事で説明されているものと非常によく似たエンコード方法が説明されています。

正直に認めます。私がその存在を知ったのは、自分の決定を書くことに深く没頭した後でした。 最初からそのことを知っていたら、おそらく独自のアプローチを考え出すのではなく、実装を書こうとしたでしょう。

興味深いことに、SCSU は私が自分で考え出したアイデアと非常によく似たアイデアを使用しています (「アルファベット」の概念の代わりに、SCSU では「ウィンドウ」が使用されており、私が持っているものよりも多くのアイデアが利用可能です)。 同時に、この形式には欠点もあります。エンコードアルゴリズムよりも圧縮アルゴリズムに少し近いということです。 特に、この規格では多くの表現方法が提供されていますが、最適な表現方法を選択する方法については規定されていません。このために、エンコーダはある種のヒューリスティックを使用する必要があります。 したがって、適切なパッケージングを生成する SCSU エンコーダは、私のアルゴリズムよりも複雑で扱いにくいものになります。

比較のために、SCSU の比較的単純な実装を JavaScript に転送しました。コード量の点では、UTF-C と同等であることがわかりましたが、場合によっては結果が数十パーセント悪かったこともあります (場合によってはそれを超える場合もありますが、それほど多くはありません）。 たとえば、ヘブライ語とギリシャ語のテキストは UTF-C でエンコードされました。 SCSUより60%優れています (おそらくアルファベットがコンパクトなため)。

これとは別に、SCSU 以外にも Unicode をコンパクトに表現する別の方法があることを付け加えておきます。 BOCU-1ですが、これは MIME 互換性 (私には必要ありませんでした) を目的としており、エンコードに対して少し異なるアプローチを採用しています。 有効性については評価していませんが、SCSU よりも高い可能性は低いと思われます。

考えられる改善点

私が提示したアルゴリズムは、設計上普遍的なものではありません (おそらく、これが私の目標が Unicode コンソーシアムの目標と最も異なる点です)。 これは主に XNUMX つのタスク (プレフィックス ツリーに多言語辞書を保存する) のために開発されたものであり、その機能の一部は他のタスクにはあまり適していない可能性があることはすでに述べました。 しかし、それが標準ではないという事実はプラスになる可能性があります - ニーズに合わせて簡単に変更できます.

たとえば、明らかな方法として、状態の存在を取り除き、ステートレスなコーディングを作成できます。変数を更新しないだけです。 offs, auxOffs и is21Bit エンコーダとデコーダで。 この場合、同じアルファベットの文字のシーケンスを効果的にパックすることはできませんが、コンテキストに関係なく、同じ文字が常に同じバイトでエンコードされることが保証されます。

さらに、デフォルトの状態を変更することで、エンコーダーを特定の言語に合わせて調整できます。たとえば、ロシア語のテキストに焦点を当て、最初にエンコーダーとデコーダーを設定します。 offs = 0x0400 и auxOffs = 0。 これは、ステートレス モードの場合に特に意味があります。 一般に、これは古い XNUMX ビット エンコーディングの使用に似ていますが、必要に応じてすべての Unicode から文字を挿入する機能は削除されません。

前述したもう 100 つの欠点は、UTF-C でエンコードされた大きなテキストでは、任意のバイトに最も近い文字境界を簡単に見つける方法がないことです。 エンコードされたバッファーから最後の、たとえば XNUMX バイトを切り取ると、何もできないゴミが発生する危険があります。 エンコードは、数ギガバイトのログを保存するように設計されていませんが、一般的には修正できます。 バイト 0xBF 決して最初のバイトとして出現してはなりません (ただし、XNUMX 番目または XNUMX 番目のバイトである場合もあります)。 したがって、エンコード時にシーケンスを挿入できます。 0xBF 0xBF 0xBF たとえば 10 KB ごと - 境界を見つける必要がある場合は、同様のマーカーが見つかるまで選択した部分をスキャンするだけで十分です。 最後に続いて 0xBF 文字の始まりであることが保証されています。 (デコード時には、この XNUMX バイトのシーケンスは当然無視する必要があります。)

要約

ここまで読んでくださった方、おめでとうございます! あなたも私と同じように、Unicode の構造について何か新しいことを学んだ (または記憶を新たにした) ことを願っています。

デモページ。 ヘブライ語の例は、UTF-8 と SCSU の両方に対する利点を示しています。

上記の研究は、規格への侵害とみなされるべきではありません。 しかし、仕事の結果には概ね満足しているので、満足しています。 シェアする: たとえば、縮小された JS ライブラリの重さはわずか 1710 バイトです (もちろん依存関係はありません)。 上で述べたように、彼女の作品は次の場所で見つけることができます。 デモページ (UTF-8 および SCSU と比較できるテキストのセットもあります)。

最後に、UTF-C が使用されるケースについてもう一度注意してください。 それほど価値がない:

• 行が十分に長い場合 (100 ～ 200 文字)。 この場合、deflate などの圧縮アルゴリズムの使用を検討する必要があります。
• 必要な場合は ASCII の透過性つまり、エンコードされたシーケンスには、元の文字列に含まれていない ASCII コードが含まれていないことが重要です。 サードパーティ API と対話するとき (たとえば、データベースを操作するとき)、エンコード結果を文字列としてではなく抽象的なバイトのセットとして渡す場合、この必要性を回避できます。 そうしないと、予期しない脆弱性が発生する危険があります。
• 任意のオフセットで文字の境界をすばやく見つけたい場合 (たとえば、行の一部が破損している場合)。 これは行を最初からスキャンする (または前のセクションで説明した変更を適用する) ことによってのみ実行できます。
• 文字列の内容に対して操作をすばやく実行する必要がある場合 (文字列の並べ替え、文字列内の部分文字列の検索、連結)。 これには、最初に文字列をデコードする必要があるため、このような場合、UTF-C は UTF-8 よりも遅くなります (ただし、圧縮アルゴリズムよりは高速です)。 同じ文字列は常に同じ方法でエンコードされるため、デコードの正確な比較は必要なく、バイトごとに行うことができます。

アップデート： ユーザー チョミッチ 以下のコメントで UTF-C の適用制限を強調するグラフを投稿しました。 これは、パックされた文字列が短い限り、UTF-C が汎用圧縮アルゴリズム (LZW のバリエーション) よりも効率的であることを示しています。 ~140 文字 (ただし、比較は XNUMX つのテキストに対して行われたことに注意してください。他の言語では結果が異なる場合があります)。


出所： habr.com