0

シンボルのシーケンスでRLEを使用する方法に問題があります。

たとえば、次のような文字列でRLEエンコーディングを実行できます。

"ASSSAAAEERRRRRRRR"

これは次のように変換されます。

"A1S3A3E2R8".

しかし、私は次のような文字列に対してRLEを実行したいと思います

"XXXYYYYY(1ADEFC)(EDCADD)(1ADEFC)(1ADEFC)(1ADEFC)"

これは次のように変換されます。

"X3Y5(1ADEFC)1(EDCADD)1(1ADEFC)3"

それに到達する方法はありますか？長い文字列は常に角かっこで囲まれるため、この作業は少し簡単になります。C ++でこれを行うためのアドバイスを与えることができますか？
角かっこを使用するよりも値を格納するためのより良い方法がある場合は、私をお勧めした場合にも役立ちます。

4

2 に答える 2

4

この問題をより小さな部分に分解する必要があります。まず、ストリームをトークン化し、個々の部分を返す関数が必要です。この例の入力ストリームの場合:

"XXXYYYYY(1ADEFC)(EDCADD)(1ADEFC)(1ADEFC)(1ADEFC)"

この関数は、次の要素を呼び出しごとに 1 つずつ返します。

X
X
X
Y
Y
Y
Y
Y
(1ADEFC)
(EDCADD)
(1ADEFC)
(1ADEFC)
(1ADEFC)
<eof>

この関数を正しく実装すれば、単一文字用に既に実装した RLE アルゴリズムを、より長い文字列をサポートするように簡単に適応させることができます。

于 2011-10-09T17:46:09.780 に答える
0

あなたの意図は、後でgzip圧縮を使用してより良い圧縮を実現するためにデータをRLEエンコードすることであると述べているので、私の答えは最初にそれをエンコードしないことです。gzip 圧縮では、連続した文字列を利用できるランレングス エンコーディングの一般化である DEFLATE を使用します。同じアルゴリズムを 2 回適用しても圧縮率が向上することはなく、実際には圧縮率が少し低下することさえあります。

独自の RLE を実行することを主張する場合は、括弧を使用する代わりに設定された長さを保存する方がよい場合があります。つまり、代わり(1ADEFC)3に61ADEFC3. また、バイト値の全範囲を使用するピクセルを圧縮しようとしていることにも注意してください。文字列で動作するように作成されたアルゴリズムは、null が埋め込まれていて印刷できない文字があちこちにある生データには適していないため、この点に注意してください。

于 2011-10-09T17:26:55.713 に答える