ハフマン符号化：なぜセパレーターが必要ないのですか？

17

Char        Code
====        ====
E           0000
i           0001
y           0010
l           0011
k           0100
.           0101
space       011
e           10
r           1100
s           1101
n           1110
a           1111

元のテキスト：

湖の近くで見られる不気味な目

エンコード済み：
0000101100000110011100010101101101001111101011111100011001111110100100101

ハフマンエンコーディングにセパレータが必要ないのはなぜですか？

coding-theory encoding-scheme huffman-coding

— BufBills
ソース

1

バイナリ値をデコードするとき、元のテキストの値と最初に一致するビットの「左から右へ」チャンクを取るためです。この場合のように、左端のチャンク（0000）がEに一致することがわかります。charコードに値が000のシンボルがある場合、000をそのシンボルに置き換えてから、残りのビットから再び検索を開始します。「左から右」の方法。そのため、分離は必要ありません。

— Syedアリハムザ

1

質問は、通常セパレーターが必要であることを意味します。区切り文字は不要であることは既に知っていますEerie eyes seen near lake（スペース文字を除く）。ただし、文字自体にはセパレータは必要ありません。なぜそうではないのですか？

— -MSalters

自分でデコードしてみてください。曖昧さはありません。

— njzk2

@MSalters：ただし、通常、可変長の単語ではセパレータが必要です：cat cheat for mice≠ catch eat form ice。あなたの類推には欠陥があります。各文字はアトミックです。文字は簡単に区別され、本質的に分離可能です。より良い類推は、「各単語が1本の長い、波打つ、自己交差する線であるときに筆記体（手書き）スクリプトを読むことができるのはなぜですか？」ハフマンでエンコードされた文字列は、先頭が見えない場合は意味がわからなくなります。

— G-マンは「元に戻すモニカ言う

@MSalters私はあなたが指しているのを見ない。固定幅のエンコードを使用しているため、文字に区切り文字は必要ありません。8ビットの連続する各ブロックは1文字に対応しています。しかし、ハフマンコーディングは固定幅ではないため、問題です。

— デビッドリチャービー

50

ハフマンコードはプレフィックスのないコードであるため、区切り記号は必要ありません（また、 "プレフィックスコード"とも呼ばれます）。つまり、コードワードは他のコードワードのプレフィックスではありません。たとえば、この例の「e」のコードワードは10であり、数字10で始まるコードワードは他にないことがわかります。

つまり、エンコードされた文字列を左から右に読み取り、コードワードを見たらすぐに文字を出力することにより、貪欲にデコードできます。たとえば、0、00、000は何もコード化しないため、ビットを読み続けます。「E」をエンコードする0000を読み取ると、コードには接頭辞がないため、他のコードワード0000xがないことがわかり、「E」を出力して次のコードワードの読み取りを開始できます。繰り返しますが、1は何もエンコードしませんが、10は「e」をエンコードします。「10」で始まるコードワードは他にないため、「e」を出力できます。等々。

— デビッド・リチャービー
ソース

1

プレフィックスコードは、一般的にインスタントコードとしても知られています（たとえば、Cover＆ThomasのElements of Information Theoryを参照）。プレフィックスコードという用語は、プレフィックスなしのコードよりもはるかに頻繁に登場すると思います。

— バットマン

3

また、連結されたハフマンコードのシーケンスをデコードするには、最初に正しいコードワード境界を指定する必要があります。間違ったコードワード境界でシーケンスをデコードしようとすると、デコードプロセスは出力シンボルの間違ったシーケンスを生成します。

— rwong

@rwong：ハフマンコードが誤って同期を開始すると、間違ったシンボルを無期限に出力し続ける可能性がありますが、シンボルの長さを誤って決定すると、誤った状態の数が減ります。

— -supercat

@supercat私はそれを別の方法で表現すると思います：ハフマンデコーダーが間違ったコードワード境界に最初に設定されて処理を開始した場合、可能性があります（ゼロまたは何かであり、辞書とビットストリームコンテンツ）が、有限時間の偶然の一致によって正しいコードワード境界に到達する可能性があり、それが発生すると、後続のシンボルの正しいデコード結果が生成されます。この再同期を保証するプロパティ（コードワードディクショナリおよびビットストリーム）の研究がいくつか行われています。

— -rwong

@rwong：元のデータが、ストリームのビットがそれぞれ1または0の独立した確率を持つような分布でランダムである場合、N個を超えるシンボルで同期が維持されない確率は、Nの増加とともに指数関数的に減衰します。実際のデータには、再同期を妨げる可能性のあるパターンが含まれている可能性が高くなりますが、実際には、100MBのテキストファイルの先頭でエラーが発生して100MBのテキストがすべて破損することはほとんどありません。

— -supercat

13

ツリーとして想像すると便利です。リーフノードに到達するまでツリーを単純に走査し、ルートから再起動します。ハフマンコーディングを行うアルゴリズムから、この種の構造がプロセスで作成されていることがわかります。

https://en.wikipedia.org/wiki/File:HuffmanCodeAlg.png

— quietContest
ソース

6

ここで重要な点は、すべての有効なコードワードがリーフであることです。内部ノードにもシンボルがある場合は、セパレーターが必要です。

— MvG

3

E以外のコードは0000で始まりません。i以外のコードは0001で始まりません。など。極端な例として、e以外のコードは01で始まりません。E= 0000、space = 000のようなものはありません。3つのゼロが見つかった場合、どうすればよいかわかりません。

エンコードされた文字列を見てください：0000101100000 ...

最初のゼロを読みます。コードは、E、i、y、l、k、コンマ、またはスペースのいずれかです。次のゼロは、k、コンマ、またはスペースではなく、E、i、y、またはlであることを意味します。次のゼロは、Eまたはiであることを意味します。次のゼロはEであることを意味します。どのコードであるかがわかると、そのコードのすべてのビットを解析したことがわかります。

次に、101100000があります... 1は、e、r、s、n、またはaがあることを意味します。次のビットは0なので、コードはeです。繰り返しますが、あなたはそのキャラクターで終わりました。

— gnasher729
ソース

-2

ハフマンエンコーディングでは区切り文字を使用できません。これは、すべての文字のバイナリ相当物が文字のプレフィックスコードと一致しないため、区切り文字を使用しなくても実行できるためです。

— サンディープ・ダス
ソース

3

多くのネストされた否定の混乱するレベルなしでのみ、私はすでに言っていませんでした。（ちなみに、セパレータを使用できないということではなく、単に必要なわけではありません。）

— デビッドリチャービー