Что состоит в том, чтобы проверить самый быстрый хеш-алгоритм, равны ли два файла?

Если вы не используете действительно сложный и / или медленный хэш, загрузка данных с диска займет гораздо больше времени, чем вычисление хеша (если вы не используете RAM-диски или верхний SSDs).

Итак, чтобы сравнить два файла, используйте следующий алгоритм:

• Сравнить размеры
• Сравнить даты (будьте осторожны: это может дать вам неправильный ответ; вы должны проверить, подходит ли это вам или нет)
• Сравнить хеши

Это позволяет быстро сбой (если размеры разные, вы знаете, что файлы разные).

Чтобы сделать работу еще быстрее, вы можете вычислить хеш один раз и сохранить это вместе с файлом. Также сохраните дату и размер файла в этом дополнительном файле, чтобы вы быстро знали, когда вам нужно пересчитать хэш или удалить хеш-файл при изменении основного файла.

Если это только один, то при условии, что вы ' Мне нужно будет прочитать оба файла, чтобы сгенерировать хэш для них обоих, почему бы просто не прочитать небольшое количество каждого из них за раз и сравнить?

В противном случае CRC является очень простым алгоритмом.

Для приложений этого типа Adler32 , вероятно, является самым быстрым алгоритмом с разумным уровнем безопасности. Для файлов большего размера вы можете вычислить несколько значений хеш-функции, например, по одному на блок из 5 МБ файла, что снижает вероятность ошибок (т.е. случаев, когда хеш-коды одинаковы, но содержимое файла различается). Кроме того, эта установка значений нескольких хешей может позволить вычисление хеша быть реализованным в многопоточном режиме.

Изменить : (Следуя замечанию Стивена Судита)
Предупреждение, если файлы маленькие !
"Криптографические" свойства Adler32, или, скорее, его недостатки хорошо известны, особенно для коротких сообщений. По этой причине предлагаемое решение следует избегать для файлов размером менее нескольких килобайт.
Тем не менее, в вопросе OP явно ищет быстрый алгоритм и не заботится о безопасности . Более того, стремление к скорости может правдоподобно означать, что вы имеете дело с «большими» файлами , а не с маленькими. В этом контексте Adler32, возможно, применяемый параллельно для фрагментов файлов размером, скажем, 5 МБ, остается очень верным ответом. Alder32 известен своей простотой и скоростью. Кроме того, его надежность, хотя и ниже, чем у CRC такой же длины, вполне приемлема для сообщений размером более 4000 байт.

Почему вы хотите его хешировать?

Если вы хотите убедиться, что два файла равны, то по определению вам придется прочитать весь файл (если только они не являются буквально одним и тем же файлом, и в этом случае вы можете сказать, посмотрев на метаданные в файловой системе ). В любом случае, нет причин для хеширования, просто прочтите их и посмотрите, совпадают ли они. Хеширование сделает его менее эффективным. И даже если хеши совпадают, вы все равно не уверены, действительно ли файлы равны.

Изменить: Этот ответ был опубликован до того, как в вопросе было указано что-либо о сети. Он просто спросил о сравнении двух файлов. Теперь, когда я знаю, что между файлами есть сетевой переход, я бы сказал, просто используйте хеш MD5 и покончите с ним.

Вы можете попробовать MurmurHash , который был специально разработан, чтобы быть быстрым, и который довольно просто кодировать. Вы можете захотеть и второй, более безопасный хеш, если MurmurHash вернет совпадение, на всякий случай.

вы можете проверить алгоритм, который используют разработчики samba / rsync. Я не рассматривал это подробно, но вижу, что об этом все время упоминают. видимо это неплохо.