Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];

Вниз

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

 
@!!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]

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



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.54 MB
Время: 0.037 c
11-1174226435
D[u]fa
2007-03-18 17:00
2007.12.16
Пара вопросов о PControl


5-1164472597
Rav
2006-11-25 19:36
2007.12.16
Редактор свойств компонента


2-1195354236
Тип
2007-11-18 05:50
2007.12.16
смена директории


3-1186917248
kirik
2007-08-12 15:14
2007.12.16
проблема с dbf (dbase4) при чтении текстовых полей.


15-1195240751
Bombaster
2007-11-16 22:19
2007.12.16
Чтение содержимого файла в массив





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский