我已经对其他问题进行了相当多的检查，但我仍然不确定这个问题。
这是我的使用案例：
我有一个在线购物车。有时，某些客户认为订购过程太繁琐，或者有些客户在线订单不会削减订单，他们需要实际的PDF估算（报价）才能购买产品。
所以我编写了一个采用购物车内容的模块，并作为PDF估算整齐地列出。
现在因为这个过程只使用购物车内容，而没有使用任何其他内容，甚至不使用数据库，我必须创建一个唯一的估算文档编号，这样如果客户支付报价，他们就会引用使用在他们的付款指示中。
购物车目前生成一个5位数的购物车ID，每个客户根据其会话独有。我已经拿走了这个5位数的购物车ID，然后我又添加了UNIX时间，这给了我一个很好的长号用作估算文件编号。
所以我最终得到这样的结果：363821482812537 [36382是购物车ID，1482812537是生成PDF估算时的unix时间]
这个问题是它太长了，因为银行付款参考有限，所以会成为一个问题。理想情况下，我希望将其保持在10个字符以内。
我决定查看CRC32以缩短生成的估算数字，并且似乎能够将估算数量缩短到可接受的字符数量。
但是，任何人都可以了解我可能会遇到什么样的碰撞？
很少有事情需要考虑：
购物车ID始终为5位数。
直到2286年，Unix时间总是10位数。
[所以我们总是会得到15个需要编码的数字，而不是更多]
有一个安全措施，如果有可能发生重复，则会抛出错误，并提供该选项以重试并生成估算值。这是通过估计保存到与估计数匹配的文件名（或者在这种情况下，估计数的CRC32散列）来完成的 - 然后首先检查是否存在带有散列的文件名。
由于对我的问题不重要的原因，客户目前不会被允许自己生成估算值。因此，只有管理员才能生成估算值。
我的担心很简单，我是否会发现自己经常与我的15位数到CRC32哈希编码发生冲突，或者碰到碰撞很少见？
答案 0 :(得分：4)
为什么不保持每次需要新增量时只需增加的估计数？您已经有效地维护了用于检查冲突的已使用数字列表，因此请将计数器放在那里。那么你只需要看一件事情而不是 n 事情。通过获取CRC，您将丢弃可能尝试从估计编号中提取的信息，因此首先从该信息中删除ID是没有意义的。你的方法似乎方式比它需要的更复杂。
个人碰撞的概率是2 -32 。数据内容无关紧要，只要它超过32位，在这种情况下，因为CRC在混合位方面做得非常好。但是，如果您之前已生成 n 估算值，那么您在碰撞时有 n 的机会。因此，当 n 增长时，碰撞的可能性也会相应增加。 （参见生日问题。）结果，在仅有77,164次估计之后，他们的两个哈希值相撞的可能性为50％。