8

URL からいくつかの画像 (BufferedImage として) をダウンロードし、それを画像プロセッサに渡す画像処理コードを実行しています。

同じ画像を画像プロセッサに複数回渡すことを避けたい (画像処理操作は高コストであるため)。画像の URL エンドポイント (同じ画像の場合) は異なる場合があるため、URL によってこれを防ぐことができます。そのため、チェックサムまたはハッシュを実行して、コードが同じ画像に再び遭遇しているかどうかを特定することを計画していました.

md5の場合、私はFast MD5を試しましたが、画像 (いくつかのサンプル) に対して 20K+ 文字の長さの 16 進チェックサム値が生成されました。この 20,000 文字以上のハッシュを格納することは、データベース ストレージに関しては明らかに問題になります。したがって、CRC32（java.util.zip.CRC32から）を試しました。そして、ハッシュよりもかなり短い長さのチェックサムを生成しました。

チェックサムとハッシュが異なる目的であることは理解しています。上記で説明した目的のために、CRC32 をそのまま使用できますか? それは目的を解決しますか、それともこれら2つ以上のことを試さなければなりませんか?

ありがとう、アビ

4

2 に答える 2

5

CRC と、たとえば MD5 との違いは、ファイルを改ざんして「ターゲット」チェックサムに一致させるよりも、「ターゲット」MD5 に一致させる方が難しいことです。これはあなたのプログラムでは問題にならないようなので、どちらの方法を使用しても問題ありません。MD5 はもう少し CPU を集中的に使用するかもしれませんが、その違いが問題になるかどうかはわかりません。

主な問題は、ダイジェストのバイト数です。

整数でチェックサムを実行している場合、サイズが 2K のファイルの場合、2^2048 の組み合わせを 2^32 の組み合わせに適合させることを意味します --> すべての CRC 値に対して、一致する可能性のあるファイルは 2^64 になります。それ。128 ビットの MD5 を使用している場合、2^16 の衝突が発生する可能性があります。

計算するコードが大きいほど、衝突の可能性が少なくなり (計算されたコードが均等に分散されている場合)、比較がより安全になります。

とにかく、起こりうるエラーを最小限に抑えるために、最初の分類ではファイルサイズを使用する必要があると思います...最初にファイルサイズを比較し、一致する場合はチェックサム/ハッシュを比較します。

于 2011-06-17T06:52:50.193 に答える
1

チェックサムとハッシュは基本的に同じです。あらゆる種類のハッシュを計算できるはずです。通常は通常の MD5 で十分です。必要に応じて、サイズと md5 ハッシュ (16 バイトだと思います) を保存できます。

2 つのファイルのサイズが異なる場合、それらは異なるファイルです。データのハッシュを計算する必要さえありません。多くの重複ファイルが存在する可能性が低く、ファイルの種類が大きい場合 (カメラで撮影した JPG 画像など)、この最適化により多くの時間を節約できます。

2 つ以上のファイルが同じサイズの場合は、ハッシュを計算して比較できます。

2 つのハッシュが同じである場合、実際のデータを比較して、結局これが異なるかどうかを確認できます。これは非常にありそうもないことですが、理論的には可能です。ハッシュが大きいほど (md5 は 16 バイトですが、CR32 はわずか 4 バイトです)、2 つの異なるファイルが同じハッシュを持つ可能性は低くなります。ただし、この追加のチェックを実行するのに 10 分のプログラミングしかかからないので、申し訳ありませんが安全だと思います。:)

これをさらに最適化するには、正確に 2 つのファイルが同じサイズである場合、それらのデータを比較します。とにかくファイルを読み取ってハッシュを計算する必要があるため、特定のサイズのファイルが 2 つしかない場合は直接比較しないでください。

于 2011-06-17T06:52:35.567 に答える