Контрольная сумма

← →
@!!ex © (2007-11-14 08:33) [0]

Как считать?
Смысл такой:
Есть два файла.
Нужно хнаить для них некоторое число, сравнив эти числа можно с некоторой достоверностью узнать одинаковые файлы или нет.
Как это вообщем делается?

← →
Думкин © (2007-11-14 08:38) [1]

Total Commander ->Инструменты-> Посчитаь CRC сумму. :)

← →
@!!ex © (2007-11-14 08:40) [2]

Так не катит... :(

← →
@!!ex © (2007-11-14 08:41) [3]

Собственно мне не нужен какой то сверх точный метод.

← →
@!!ex © (2007-11-14 08:45) [4]

Читаю вики по СРС и слабо понимаю.. эх. :(

← →
Riply © (2007-11-14 08:45) [5]

> [3] @!!ex © (14.11.07 08:41)
> Собственно мне не нужен какой то сверх точный метод.

GetFileSize ? :)

← →
@!!ex © (2007-11-14 08:47) [6]

> [5] Riply © (14.11.07 08:45)

Я думаю GetFileSize + какой нить элементарный хэш

← →
@!!ex © (2007-11-14 08:49) [7]

Вот че нашел:
http://www.soft32.ru/delphi.shtml?topic=syntax&title=md5

md5 - то что нужно?

← →
Skyle © (2007-11-14 09:08) [8]

> @!!ex © (14.11.07 08:49) [7]
> Вот че нашел:
> http://www.soft32.ru/delphi.shtml?topic=syntax&title=md5
>
> md5 - то что нужно?

Можно и так.

← →
Jeer © (2007-11-14 09:23) [9]

> @!!ex © (14.11.07 08:49) [7]

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

В тех же случаях, когда требования по криптостойкости не предъявляются
достаточно использования контрольных сумм или CRC.
Метод расчета последних весьма прост и основан на делении входной последовательности на неприводимый полином.
Степень полинома выбирается исходя из требуемой вероятности коллизий.

Широко применяемый CRC32 (Ethernet) имеет полином:
X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+1

Реализаций на Delphi в сети - масса.

← →
tesseract © (2007-11-14 10:21) [10]

> Широко применяемый CRC32 (Ethernet)

Он в Ethernet (наверно правильнее arp )из modbus и сотоварищи пришел.

← →
DVM © (2007-11-14 11:42) [11]

> @!!ex ©

Лучше использовать MD5 и CRC32 совместно.

← →
Jeer © (2007-11-14 12:00) [12]

> Лучше использовать MD5 и CRC32 совместно.

А зачем ?

Не хватает CRC32 никто не запрещает перейти на CRC40, CRC64.

← →
DVM © (2007-11-14 12:21) [13]

> Не хватает CRC32 никто не запрещает перейти на CRC40, CRC64.

Ну или да, действительно CRC64

← →
isasa © (2007-11-14 12:27) [14]

У меня только pdf, сейчас выложить некуда, можно поискать по ключевым

Ross N. Williams, Элементарное руководство по CRCалгоритмам обнаружения ошибок

← →
Anatoly Podgoretsky © (2007-11-14 12:37) [15]

http://podgoretsky.com/ftp/Docs/Internet/pdf/crcguide.pdf

← →
Сусл © (2007-11-14 14:32) [16]

по CRC много статей на королевстве. объяснено все идеально.

← →
Dimaxx © (2007-11-14 16:41) [17]

> Есть два файла.
> Нужно хнаить для них некоторое число, сравнив эти числа
> можно с некоторой достоверностью узнать одинаковые файлы
> или нет.
> Как это вообщем делается?

За глаза хватит CRC32! Она изменится, даже если изменишь 1 бит в любом байте файла.

← →
Dimaxx © (2007-11-14 16:43) [18]

http://www.torry.net/pages.php?id=1548

Выбираешь любой с исходниками и юзаешь...

← →
Германн © (2007-11-14 17:06) [19]

> За глаза хватит CRC32! Она изменится, даже если изменишь
> 1 бит в любом байте файла.
>

Угу. Изменится. А если изменишь ещё несколько битиков она опять станет прежней. Нужно только знать где и каких.

← →
Черный Шаман (2007-11-14 17:23) [20]

http://www.delphisources.ru/pages/faq/base/hash_crc64.html

← →
Jeer © (2007-11-14 17:34) [21]

> Германн © (14.11.07 17:06) [19]

> А если изменишь ещё несколько битиков она опять станет прежней.

Информационная стойкость CRC32 всего-то 4 байта.
Именно столько надо изменить или добавить к "защищенному" файлу, чтобы его CRC32 совпала с "модифицированным" файлом.

← →
@!!ex © (2007-11-14 18:37) [22]

Народ, хватит уже спорить! :)
Я сделал через md5, вроде все работает!

← →
Jeer © (2007-11-14 18:39) [23]

> @!!ex © (14.11.07 18:37) [22]

А при чем тут ты ?
Мы про тебя уже забыли:)

← →
Jeer © (2007-11-14 18:39) [24]

А MD5 считается раз в 10 медленнее CRC32:))

← →
@!!ex © (2007-11-14 18:52) [25]

> [24] Jeer © (14.11.07 18:39)

Скорость не критична ваще...

← →
oldman © (2007-11-14 18:59) [26]

> Германн © (14.11.07 17:06) [19]
> Угу. Изменится. А если изменишь ещё несколько битиков она
> опять станет прежней. Нужно только знать где и каких.

Даже если ничего не изменишь, а откроешь файл в редакторе и сохранишь она уже изменится...

← →
Dimaxx © (2007-11-15 02:03) [27]

> Именно столько надо изменить или добавить к "защищенному"
> файлу, чтобы его CRC32 совпала с "модифицированным" файлом.

Проиллюстрируй примером. Допустим, есть файл 16 байт длиной, заполнен байтами $00..$0F. CRC32 его равна $CECEE288. Что нужно изменить в нем или какие 4 байта добавить, чтобы контр. сумма стала равна исходной. Мне не удалось добиться совпадения контр. суммы ни при изменении содержимого, ни при добавлении.

← →
Riply © (2007-11-15 02:36) [28]

> [27] Dimaxx © (15.11.07 02:03)
Поищи по форуму.
Если не ошибаюсь, Rouse_ приводил три файла в пример.

← →
Riply © (2007-11-15 02:47) [29]

> [27] Dimaxx © (15.11.07 02:03)
> Проиллюстрируй примером. Допустим, есть файл 16 байт длиной, заполнен байтами $00..$0F. CRC32 его равна $CECEE288.
> Что нужно изменить в нем

Алгоритм очень простой:
Создаешь MAX_DWORD + 1 разных файлов 16 байт длиной.
Как минимум у двух из них CRC32 будет совпадать.
Сравниваешь эти два файла.

:))

← →
KilkennyCat © (2007-11-15 03:29) [30]

А я бы сравнивал файлы выборкой из нескольких мест. Скорость - офигительная будет. при 100% выборке 100% гарантия.

← →
Anatoly Podgoretsky © (2007-11-15 08:53) [31]

> Проиллюстрируй примером. Допустим, есть файл 16 байт длиной,
> заполнен байтами $00..$0F. CRC32 его равна $CECEE288. Что
> нужно изменить в нем или какие 4 байта добавить, чтобы контр.
> сумма стала равна исходной. Мне не удалось добиться совпадения
> контр. суммы ни при изменении содержимого, ни при добавлении.
>

Добавляешь 4 байта и в них перебираешь комбинации от 0000 до FFFF - как минимум одно совпадение гарантировано.
Только смысл в подобной подделке?
Если ты сравниваешь два файла, то первое значение по длине.
Далее если это одно сравнение, а не многократное, то и в CRC смысла нет, быстрее будет побайтовое сравнение файлов.

← →
Anatoly Podgoretsky © (2007-11-15 08:55) [32]

> А я бы сравнивал файлы выборкой из нескольких мест. Скорость
> - офигительная будет. при 100% выборке 100% гарантия.

Не понял твое предложение, ты предлагаешь сравнивать не все содержимое, тогда скорость конечно очень быстрая, но гарантия стремится к нулю.

← →
Jeer © (2007-11-15 09:33) [33]

> Dimaxx © (15.11.07 02:03) [27]

> Допустим, есть файл 16 байт длиной,

> Мне не удалось добиться совпадения контр. суммы

А это все от нежелания почитать теорию или невозможности пробиться сквозь ее дебри.
Ведь очевидно, что если длина входных данных меньше или равна длине контрольной суммы, то преобразование (деление) выполняется однозначно.
А вот если длина входной последовательности больше, то где-то мы что-то потеряем.
Простая логика подсказывает, что нельзя выполнить сжатие абстрактных двоичных данных без потерь, иначе мы могли бы экстраполировать эту процедуру до длины КС в 1 бит при бесконечной длине входной последовательности и получить самый лучший в мире архиватор.

← →
Dimaxx © (2007-11-15 10:50) [34]

> сжатие

А где ты видишь сжатие? Это скорее сворачивание (причем необратимое), а не сжатие. Это же не архиватор. Тогда можно про любой хэш это сказать.

← →
Dimaxx © (2007-11-15 11:19) [35]

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

При размере файла до 64кб проще сравнить его побайтно вместо вычисления CRC32.

← →
Anatoly Podgoretsky © (2007-11-15 11:26) [36]

Поскольку по условию задачи "есть два файла", то при любом размере лучше сравнивать побайтно.

← →
Jeer © (2007-11-15 11:53) [37]

> Dimaxx © (15.11.07 10:50) [34]

"Сжатие" в данном случае условный термин. Разумеется, математически эта операция называется свертка. Термин необратимое сжатие также применим, поскольку объективно мы получаем из большего меньшее. Термин сжатие был употреблен, поскольку ты не понимаешь очевидных вещей и пытался оперировать 16 байтной последовательностью при CRC32.

> При размере файла до 64кб проще сравнить

Голословные утверждения почему до 64k проще, а потом сложнее.

> Anatoly Podgoretsky © (15.11.07 11:26) [36]

Если действительно только два файла - разумеется.

← →
@!!ex © (2007-11-15 12:00) [38]

> [36] Anatoly Podgoretsky © (15.11.07 11:26)

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

← →
Jeer © (2007-11-15 12:10) [39]

> @!!ex © (15.11.07 12:00) [38]

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

← →
Anatoly Podgoretsky © (2007-11-15 12:12) [40]

> @!!ex (15.11.2007 12:00:38) [38]

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

← →
@!!ex © (2007-11-15 12:14) [41]

> [39] Jeer © (15.11.07 12:10)

Вопрос то уже решенный. :)
послать вычислятор КС и получить обратно результат его работы - не проблема.
Задача вся такова:
У человека есть бета версия игры.
Ему надо послать новую версию.
Слать всю версию как делали раньше - не рационально. Ибо 50 метров.
Нормальной системы обмена данными нет, ибо начальству на это по*.
Сделал прогу, которая смотрит список файлов в указанной папке и сохраняет его в текстовый документ, с результатом выполнения хэш функции.
Создаю для новой версии такое же файлик.
делаю копию новой версии.
Потом другая софтина просматривает оба файлика и файлы которые совпадают из указанной папки удаляет.
В итоге в папке остаются только файлики, которых нет в старой версии и файлы у которых не совпадает хэш.

> @!!ex © (15.11.07 12:15) [42]

> Я уже давно сказал, что все сделано

Ну как скажешь, а то мы можем тут еще немножко поговорить и даже без тебя:)

А по делу есть неплохой синхронизатор файлов ZSync (в том числе по FTP), так шта и обсуждать и писать ничего не надо было бы.

> @!!ex (15.11.2007 12:15:42) [42]

Зачем же тогда задаешь вопрос, при том неправильно.

> [44] Anatoly Podgoretsky © (15.11.07 12:27)

Когда вопрос задавал - еще не сделал.
А как надо было?
Мне тупо надо было узнать как считать хэш(при том, что это хэшем называется я тогда не знал).

> тупо надо было узнать

Может быть это ключевая фраза ?

> [46] Jeer © (15.11.07 12:43)

Ну так вроде и написано:
Как посчитать контрольную сумму, чтобы можно было сравнить файлы.

> А как надо было?

Так как в [41]

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

> Голословные утверждения почему до 64k проще, а потом сложнее.

Глупая фраза. Ты изначально не знаешь какой размер файла сравнивает автор ветки (он не сказал размер). Может это файл данных в 25 мегов, а может просто контрольный файл размером 100 байт. Я же сказал обобщенно, что до 64кб (ничто не мешает использовать 128, 256 или более кб) файл проще загрузить в буфер и сравнить побайтно с "эталонным", чем заморачиваться вычислением CRC32 и уж тем более хэша. К тому же вероятность, что в 2-х разных файлах объемом в 1мб появятся одинаковые CRC ничтожно мала. В 1-байтном файле повторений много (они идут сериями). Проверю для себя есть ли совпадения в 4-байтном файле с содержимым от $0000 до $FFFF.

> Dimaxx © (15.11.07 13:24) [49]

Поток незамутненного сознания ?

На мой взгляд, за слова надо отвечать.
Так вот и ответь, почему до 64к проще, а потом сложнее.

Также интересно > ничто не мешает использовать 128, 256 или более кб)
- насколько более.

> файлах объемом в 1мб

Нам никто не ограничивал воображение, а законы обобщения настаивают на своем. Или 1 мб это такая критическая величина ?

> В 1-байтном файле повторений много

С эти вообще трудно спорить, т.к. логика заходит в тупик.

Разберись уж со своим потоком незамутненного сознания.

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

> Так вот и ответь, почему до 64к проще, а потом сложнее.

Взято для примера. Например, 11,5кб устраивает?

> Или 1 мб это такая критическая величина?

Опять же взято для примера.

> эти вообще трудно спорить, т.к. логика заходит в тупик.

Я вообще не занимаюсь использованием CRC32 и не вдавался в его тонкости, поэтому проверил для себя. Мне уже самому просто интересно...

> Ты придираешься к каждому слову, к каждой фразе.

Ну а кто виноват что ты столь часто порешь чепуху?

> Dimaxx © (15.11.07 15:07) [51].. [52]

> Ты придираешься к каждому слову, к каждой фразе.

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

> зято для примера. Например, 11,5кб устраивает?
1 мб ..Опять же взято для примера.

Конечно нет, не устраивает. Пример он хорош тогда, когда подкреплен теорией или практикой. А с потолка называть какие-то цифры и утверждать при этом не доказанное - есть голословие.

Мы можем предположить, что какой-то метод может быть лучше другого, а другой лучше первого, но при определенных условиях.
Вот пример из другой оперы:
Многим известен алгоритм сортировки qucksort как один из самых быстрых,
но все ли знают что при определенных условиях он таковым не является ?

> не занимаюсь использованием CRC32 и не вдавался в его тонкости,

Верю, тем более не мешало бы залезть в его теорию, а не фантазировать.

> Dimaxx (15.11.2007 15:04:51) [51]

А ты за свои слова отвечаешь, зуб даешь, мамой клянешься?

> Jeer (15.11.2007 15:34:54) [54]

> Многим известен алгоритм сортировки qucksort как один из самых быстрых,
но все ли знают что при определенных условиях он таковым не является ?

Подтвердждаю, в этих условиях пузырек самый быстрый.

> Ну а кто виноват что ты столь часто порешь чепуху?

Покажи... Пока бездоказательно. Твою чепуху я не считал, но уверен (если поискать) ее тоже немало наберется.

За пузырь обидно.

Разбить? Поллитра - да я тебя
(С) недавно показывали

Контрольная сумма Найти похожие ветки