我通过散列包含所有这些信息的字符串并比较散列对象的十六进制摘要来比较个人的个人信息，特别是他们的姓名、生日、性别和种族。这将生成一个 32 位的十六进制数，我将其用作数据库中的主键。例如，使用我的识别字符串的工作方式如下：
>> import hashlib
>> id_string = "BrianPeterson08041993MW"
>> byte_string = id_string.encode('utf-8')
>> hash_id = hashlib.md5(bytesring).hexdigest()
>> print(hash_id)
'3b807ad8a8b3a3569f098a575091bc79'
在这一点上，我试图确定碰撞风险。我的理解是 MD5 没有显着的碰撞风险，至少对于相对较小的字符串，我的字符串（长度约为 20-40 个字符）。但是，我没有使用 128 位摘要对象，而是使用 32 位十六进制摘要。
现在，我相信 hexdigest 是摘要的压缩（也就是说，它存储在较少的字符中），所以在比较 hexdigest 时是否会增加碰撞风险？还是我不在基地？
现在，我相信 hexdigest 是摘要的压缩（也就是说，它存储在较少的字符中），所以在比较 hexdigest 时是否会增加碰撞风险？还是我不在基地？
[...]
我想我的问题是：根据它们用于表示的信息单元数量与原始消息编码所需的信息单元数量，不同的表示是否有不同的机会成为非唯一的？如果是这样，使用的最佳表示是什么？嗯，让我在你的下一个答案前加上：像我 10 岁一样跟我说话
老问题，但是，可以这么说，您有点偏离基础。
重要的是随机位的数量，而不是演示文稿的长度。
摘要只是一个数字，一个整数，可以使用不同数量的不同数字将其转换为字符串。例如，在一些不同的基数中显示的 128 位数字：
"340106575100070649932820283680426757569" (base 10)
"ffde24cb47ecbff8d6e461a67c930dc1" (base 16, hexadecimal)
"7vroicmhvcnvsddp31kpu963e1" (base 32)
更短更好更方便（在身份验证令牌等中），但每个表示都有完全相同的信息和碰撞机会。较短的表示较短，原因与“55”比“110111”短的原因相同，但仍然编码相同的内容。
这个答案也可能澄清事情，以及玩弄像这样的代码：
new BigInteger("340106575100070649932820283680426757569").toString(2)
...或其他语言中的等价物（上面的 Java/Scala）。
在更实际的层面上，
[...] 我在数据库中用作主键
我不明白为什么不通过使用正常的自动递增 id 列（在 MySQL 中，在 PostgreSQL 中）来消除任何冲突的可能性。BIGINT AUTO_INCREMENTBIGSERIAL