除了 md5 有没有比较短的哈希算法
平时都是使用 md5 做哈希,但是有时候感觉 32 位太长了,有点浪费,想问下大家除了 md5 ,还有没有其他优秀的哈希算法?比较短的
fnv
substr(md5(""), 8, 16);
ps md5 是 128 位的
%2
crc32 ?
越短越容易碰撞
额,是的,可能我用的单位表述不是很专业,我想说的就是看到它的是长度为 32 的字符串形式,明白就好
想问下截取中间的是什么依据,靠谱吗
嗯嗯,明白,短的话碰撞概率就高,但是有某些简单的场景,不需要那么高的抗碰撞率
crc32 ,我们是做 url 二级索引的,url 多了一级索引查的很郁闷,所以先 hash 一次然后二次查询
CRC32 FNV1a-32 CityHash32 等,一般一些简单用途我会选 FNV1a-32 ,因为它非常简单。
再补充一个 MurmurHash
看起来不需要防碰撞,那就 CRC
或者 en.wikipedia.org/wiki/List_of_hash_functions 里面挑一个
CRC3 CRC4 CRC8 CRC16 CRC32 CRC64
substr 解君忧
md5 默认是 hex 格式输出,你可以输出成 base64 ,这样去掉占位的 = 号,就只有 22 位字符了
續 15 樓
md5 編碼成 base94 ?
xxhash 家族
直接所有 ascill 相加成 16 进制😁
防碰撞哈希算法就没短的,感觉你要的是快速哈希算法,比如 Murmur 或者 CRC ,快且短,但是容易发生冲突。
把 MD5 断尾没问题,你可以自己做碰撞概率测试,每个 bit 概率是一样的。
非标准 base64 算法。把数字,小写字母,大写字母和一些特殊字符都用上,变成 N 进制,重新再编码这样就短了。一个 uuid 都可以编码到 22 个字符以下,只是字符看你能不能接受
哈希截断挺常见的,很多标准库都会有这种操作
md2 ,md4
可以试试 blake2/3 ?
www.blake2.net/
SipHash 不是专门设计来解决你这个问题的嘛?
CRC32 ,短到你用一个 int 就能存
security.stackexchange.com/a/72685
直接截前面一段就行,要多长截多长
但是 md5 本来就是比较差的算法,再截一下就更差了,如果需要防碰撞就换个 sha256 之类的吧
jhash 算法。 计算字符串的哈希,得到 4 字节哈希值。 github.com/ysmood/jhash
wyhash ,输出字符串长度 16 位,而且是目前最快且安全的算法
而且 wyhash is the default hashing algorithm of the great great Zig, V, Nim and Go (since 1.17) language
xxhash
cityhash murmurhash
xxhash 挺好的,非密码安全的哈希,速度也快。
公司是传统企业,一个十几年的系统,使用 SQLServer 存储数据。累积到现在已有 1W+ DB ,每个 DB 下 100+表。想全部迁移至 MySQL 。SQLServer…
不少技术文章都直接引用了这个观点,但没说为什么?有大佬解释下这个理论依据吗? 听说 MySQL 单表超过 1000 万行性能会急剧下降。 这应该是个经验数字,不一定绝对对。…
一、项目背景 自 2019 年以来,ipv6.ddnspod.com 已经稳定运行 5 年整了,本来是自用的一个小项目,主要用来获取联网设备外网 ipv6 地址,功能非常简单,…