John Doe wrote: ↑Sat 07 Mar, 2020 09:34
Всё зависит не от алгоритма хэширования, а от свойств исходных данных (а вам требуется уникальность и постоянство).
все зависит не от свойств исходных данных, а от их одного свойства которое называется "уровень энтропии" или просто "энтропия".
Да, CRC32 более чувствителен к низкой энтропии входных данных, чем специальные "противо-низко-энтропные" например SHA2 и MD5.
Но у нас CRC32 вычисляется по текстам диалогов, в которых много разных буков и цифр, т.е. обладающие высокой энтропией,
или можно сказать что непредсказуемостью, что дает больше уникальных значений для CRC32.
Если же взять CRC64 то думаю что коллизии будут исключены даже в теории.
Могу где-то ошибаться, точных вероятностей коллизий у меня нет, изложил свое понимание и оценку "плюс-минус лапоть"
citRix wrote:практика показывает что не меняется.
John Doe wrote: ↑Sat 07 Mar, 2020 09:34Практика показывает, что меняется.
Надеюсь не будем изз этого ссориться?
у меня не повтoряется, но @XeRoX чтобы исключить потенциальные сюрпризы в любом случае переводит на идентификацию по CRC32/64
Точнее так,
для сохранения состояния
МЕЖДУ СЕССИЯМИ (
прим.: ранее тут была опечатка) уже сейчас используется CRC32,
для внутрисессионной идентификации используется у него какая-то адская смесь из "ручек", ГУИДов (если есть), и того же CRC32.
в конечном итоге и для внутрисессионой идентификации будет CRC32.
CRC32 вычисляется по всем предполагаемо неменяемым элементам диалога и меню,
что дает и уникальность и много энтропии в кажется что большинстве случаев.
С другой стороны, это сейчас работает настолько гладко,
что может отсоветую ему переводить полностью на CRC32, а дождаться бахг-репортов каких.
опять же, если баг-репортов (=интереса) не будет, то пусть будет так как есть,
@XeRoX и так наизобретал много чего уже, чего еще не выкладывал из-за возни этой с размерятелем