次の正準ハフマン符号表があるとします。正準ハフマン符号器：符号化ビットストリームの内容
Symbol Code-length Codeword
A 2 00
B 2 01
C 2 10
D 2 11
ここで、入力ファイルからシンボルを読み取り、上の表を参照してそれをエンコードします。しかし、標準的なハフマンの場合、コードワードを送信すべきではないと多くのリソースが言います。代わりに、各シンボルのコード長で十分です。
テキストファイルにACCDBが含まれている場合、符号化ビットストリームとして00 01 10 11または10 10 10 10（対応するコード長の2進数）を送信する必要がありますか？私が間違っていれば私を訂正してください。何か説明がありがたいです。
また、正規のハフマンの場合は、元のシンボルACCDB（デコーダでハフマンツリーを使用しないで）を戻すために、そのビットストリームをどのようにデコードするのですか？
これは正規のハフマンコードテーブルでも、ハフマンコードでも、プレフィックスコードでもありません。コード長1,2,2,3は利用可能なビットをオーバーサブスクライブする。 1、2、2は完全なコードであり、それ以上シンボルをコード化することはできない。
1、2、3、3は完全で非オーバーサブスクライブコードです。この場合、コードの例は0,10,110,111になります。これらのコードは一意にデコードでき、左から右へ。
Markありがとうございます。さて、私はコードと利用可能なビットについて得た。しかし、別のスレッドでのあなたの以前の説明の1つでは、コードワードをデコーダに送信することは想定されていません。ですから、上記の例のようにエンコードされたビットストリームがどのように見えるか教えてください。通常のハフマンの場合、これはちょうど対応するコードワードになります。私のもう1つの質問は、デコーダでハフマンツリーを使用することを想定していない場合、デコーダがコードワード（またはコード長）〜シンボル情報をどのように推定するかということでした。ありがとう。 – beginner
これはもう2つの質問です.2つの新しい質問を投稿する必要があります。 –
さて、確かに。 – beginner
質問を編集した後でも、それはまだプレフィックスコードではありません。 AはCとDの接頭辞です。接頭辞コードでは、接頭辞として他のコードを使用することはできません。 –
これは不完全なコードです。 100および111は使用されません。これらの10と11を長さ2 2 2 2で完全なコードにするには、CとDの最後のビットを削除してください。有効な4シンボルのコード長は、2 2 2 2と1 2 3 3です。 –