Расчет CRC32 без использования внешних компонент
Расчет CRC32 без использования внешних компонент.
Алгоритм можно ускорить, но меня устраивает и так, как есть.
У меня используется для небольших объемов данных.
Легко переносится на 8-ку
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Подскажите для чего это можно применить? И каков принцип кодирования в crc32?
Алгоритм CRC32 устроен так, что небольшие изменения в ДАННЫХ вызывают большие изменения в подписи CRC32.
Я использую для сверки бумажных и электронных накладных, печатая CRC32 на накладной в виде штрихкода.
(2) Штрих-код — это конечно хорошо, а как происходит сверка штрих-кодов у вас?
Извиняюсь не правильно понял вопрос первый раз.
На накладной в виде ШК есть номер накладной и ШК CRC32 табличной части.
Сканируется ШК CRC32 потом Номер накладной повторно вычисляется CRC32 сравнивается.
ух ты!
А ты проверял возникновение коллизий?
Например если кодировать уид 20тыс. элементов, то сколько будет разных элементов с одинаковым CRC32?
Алгоритм предназначен для контроля ошибок, а не для кодирования, на сколько я понимаю.
Честно говоря мне не совсем ясно для чего каждый отельный УИД нужно кодировать CRC32.
Алгоритм CRC32 придуман не мной и мной не исследовался.
Возможно эта информация Вам поможет:
В частности там указано что, CRC32 используется в Ethernet, FDDI, iSCSI …
Если Вам нужна меньшая вероятность совпадений смотрите в сторону MD5 и т.п.
Спасибо за ссылку, я смотрел эту статью.
md5 однозначно не подходит.
Слишком большое выходное значение получается. Мне нужно получить максимум 10 символов.
Из найденного подходят методы Adler32 и CRC32.
Кстати первый работает очень быстро и просто программируется, но у него возможны коллизии.
Проверял на 20 тыс. элементов получилось около 900 ошибок (разных элементов с одним хешем).
С CRC32 я думаю меньше будет.
Зачем нужно кодировать каждый УИД отдельно?
Нужно для каждого элемента получить уникальный код который пользователь должен будет ввести вручную (поэтому и ограничение по длине кода). Он должен быть не по порядку, чтобы исключить подбор вручную. Кончено может совпасть так, что код будет по порядку, но вероятность меньше.
После проверки 18000 элементов
Adler32 выдал 652 коллизии
CRC32 выдал 4 коллизии
Выводы: метод не подходит для этой задачи. Он не обеспечивает необходимой уникальности.
Буду искать другие способы.
Кстати, для проверки сделал внешнюю компоненту.
18тыс элементов за 1 секунду закодировала.
Если нужна могу скинуть.
Adler32 выдал 652 коллизии
CRC32 выдал 4 коллизии
Выводы: метод не подходит для этой задачи. Он не обеспечивает необходимой уникальности.
Ну и в принципе если ты большую строку преобразуешь в меньшую и по одной нельзя воссоздать другую в точности, то ты неизбежно получишь коллизии.
Johny_v, да, кинь компоненту пожалуйста!!! Очень нужна! Спасибо
Автору спасибо!
Есть один нюанс:
Я скачал обработку и переписал код под 8-ку. Потом решил проверить, совпадет ли расчет с методом ХешированиеДанных() из платформы 8.3.
Результат не совпал.
Похоже, что в платформе используется алгоритм CRC32B (расчет из платформы совпал с расчетом онлайн-конвертера CRC32B . А какой алгоритм используется в этой обработке, я пока не успел выяснить — но, похоже, не CRC32B. С аналогичным онлайн-расчетом CRC32 он тоже не совпадает.
Так что не знаю, используйте на свой страх и риск. Хотя может, конечно, я криво код переписал под 8-ку…
(15) vvr908, Прошу прощения за поздний ответ, но у меня все под 7.7 совпадало со всеми генераторами. В 8.3 есть функция расчета CRC она не устраивает? Могу переписать код под 8 ку.