質問

私はアルゴリズムを使用して変数の長さをエンコードしようとしていますが、非常に長いです XMLファイルから取得されたフィールドでは、そのエンコードされたデータをデータベースに持続する必要があります。

その後、2番目のファイルを受信すると、データベースからエンコードされたデータを取得し(以前に保存されています)、デコードして、複製の新しいデータを検証する必要があります。

私は試した org.apache.commons.codec.binary.Base64 クラス2つの方法があります:

  1. encodeBase64(Byte[] barray)
  2. decodeBase64(String str)

これは完全に正常に機能し、私の問題を解決します。ただし、55の文字列をわずか6文字列に変換します。

したがって、これらのアルゴリズムが非常に大きく、同じエンコードされたバイト配列に1つのcharミスマッチ(たとえば)しかない2つの文字列をエンコードする場合があるのだろうか。

私はについて知っていません Base64 クラスはたくさんありますが、誰かが私を助けてくれるなら、それは本当に役に立ちます。

固定長の大きな文字列を不足し、私の目的を解決する他のアルゴリズムを提案できれば、喜んで使用します。

前もって感謝します。

役に立ちましたか?

解決

あまり効率的ではありません。

また、使用します sun.misc クラスは、ポータブルではないアプリケーションを提供します。

次のパフォーマンスの比較をチェックしてください migbase64:

enter image description here


したがって、これらのアルゴリズムが非常に大きく、同じエンコードされたバイト配列に1つのcharミスマッチ(たとえば)しかない2つの文字列をエンコードする場合があるのだろうか。

base64はハッシュアルゴリズムではないため、エンコードであるため、双方向でなければなりません。必然的に衝突は許可できません - それ以外の場合、デコードは非決定的です。 Base64は、ASCII文字列の任意のバイナリデータを表すように設計されています。 Unicode文字列をbase64としてエンコードすると、頻繁に行われます 増加 の数 コードポイント Unicode文字セットには複数のバイトが必要なため、必要です。 Unicode文字列のbase64表現は、使用されるエンコード(UTF-8、UTF-16)によって異なります。例えば:

Base64( UTF8( "test" ) ) => "dGVzdA=="
Base64( UTF16( "test" ) ) => "/v8AdABlAHMAdA=="

解決策1

ロスレス圧縮を使用します

GZip( UTF8( "test" ) )

ここでは、文字列をバイト配列に変換し、ロスレス圧縮を使用して保存する必要があるバイト数を減らします。 CHARエンコードおよび圧縮アルゴリズムを変化させて、保存する文字列に応じてバイト数を減らすことができます(つまり、ほとんどがASCIIである場合、UTF-8がおそらく最適です。

プロ: :衝突なし、元の文字列を回復する能力
短所: :値を保存するために必要なバイトは可変です。値を保存するために必要なバイトは大きいです

解決策2

ハッシュアルゴリズムを使用します

SHA256( UTF8( "test" ) )

ここでは、ハッシュ機能を備えたバイトの固定長セットに文字列を変換します。ハッシュは一方向であり、その性質によるものです 衝突が可能です. 。ただし、処理することを期待する文字列のプロファイルと数に基づいて、ハッシュ関数を選択して衝突の可能性を最小限に抑えることができます

プロ: :値を保存するために必要なバイトが固定されています。価値を保存するために必要なバイトは小さいです
短所: :衝突可能性、元の文字列を回復する能力はありません

他のヒント

私はあなたのコメントを見ました - 私が最初に思ったように、ハッシュするのではなく、実際に圧縮を探しているようです。その場合、あなたは しない 任意の入力の固定長の出力を取得できるようにします(それについて考えてください、無限の数の入力は有限数の出力に生物的にマップすることはできません)ので、それが強力な要件ではなかったことを願っています。

いずれにせよ、選択した圧縮アルゴリズムのパフォーマンスは、入力テキストの特性によって異なります。さらなる情報がない場合、デフレート圧縮(ZIP入力ストリームで使用されるIIRCで使用)は、開始するのに適した汎用アルゴリズムであり、少なくとも比較の基礎として使用されます。ただし、実装を容易にするために、 デフレーター Zlib圧縮を使用するJDKに組み込まれたクラス。

入力文字列に特定のパターンがある場合、異なる圧縮アルゴリズムが多かれ少なかれ効率的である可能性があります。ある点では、どちらを使用するかは関係ありません。他のプロセスで圧縮データを読み取ることを意図していない場合 - 自分自身を圧縮して解凍できる限り、クライアントに対して透明になります。

これらの他の質問は興味深いかもしれません:

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top