1

これは、初心者からの 2 部構成の質問です。

まず、単純なテキスト (小文字/大文字の区別なし) のエンコーディングが必要で、ASCII よりもスペース効率が高い必要があります。そこで、32 文字 (アルファベットといくつかの句読点) の範囲を保持する独自の 5 ビット コードを作成することを考えました。私が理解している限り、最新のコンピューティングはすべてバイト単位で「考える」ため、実際に 8 ビット エンコーディングに頼らずに独自の 5 ビット エンコーディングを実際に定義することはできません。

私が考えているのは、独自の 5 ビット コードを定義し、テキストを 3 文字のブロックに保存し、各ブロックを 2 バイトとして保存することです。各ブロックは合計 15 ビットを占有し、2 バイト (16 ビットを保持) 内に格納されます。実際には必要ない場合でも、余分なビットをパリティ チェックに使用することがあります。このアプローチは理にかなっていますか？または、より良いアプローチはありますか？別の方法として、6 ビットのエンコーディングを定義し、テキストをそれぞれ 4 文字のブロックに保存し、各ブロックを 3 バイトで保存することもできます。

質問の 2 番目の部分は、次のとおりです。テキストが圧縮されると仮定すると (たとえば、zip などのテキストの標準的なロスレス アルゴリズムを使用して)、(上記で説明したように) 独自のエンコーディングを作成する手間をかける価値はありますか? それとも、圧縮アルゴリズムは 8 ビット エンコーディングのスペースの非効率性を処理し、元は 5 ビットまたは 6 ビット エンコーディングを使用してエンコードされた圧縮ファイルと同じくらい効率的に圧縮を行いますか? その場合、圧縮前のテキストに 5/6 ビット エンコーディングを使用するメリットがないため、この手順をスキップします。経験豊富なプログラマーから情報を得る必要があります。

みんな、ありがとう

4

2 に答える 2

1

圧縮アルゴリズムは、コーディングをより効率的に処理します。ハフマン、レンジ、または算術符号化を使用して、実際のデータの統計を利用して、文字ごとに可変数のビット、さらには小数ビットを使用します。これは、文字をそれぞれ 8 ビット未満に詰め込んでプリコーディングしようとしない場合に、はるかにうまく機能します。圧縮アルゴリズムは、各バイトで見つかったシンボルによって統計をカウントし、バイト内の繰り返しパターンを探します。

于 2013-03-23T19:20:31.170 に答える
1

  1. 「ブロック」について心配する必要はありません。5 ビットを 8 ビット バッファに追加するだけです。このバッファがいっぱいになったら、フラッシュして残りのビットをバッファにプッシュします。
    唯一のあいまいさは、メッセージの最後に来ます。まだ埋められていないビット数が 5 以上の部分的に満たされたバッファがある場合です
    。メッセージの長さ (n*5 ビット) または
    b を指定する必要があります。末尾のビットの長さのみを指定する必要があります (より効率的)

  2. 圧縮アルゴリズムは、カスタム パッキングによって実際に悪影響を受ける可能性があります (テキストなどの元のデータの種類によって異なります)。

于 2013-03-23T19:21:08.673 に答える