我遇到了一个非常恼人的问题，使用crc16哈希来管理我的一些信息。
在我的应用程序中，我将一些信息传递给url参数，一个巨大的编码上下文。该上下文允许用户恢复他们的旧搜索。在这种情况下，我有一些我喜欢的元素，以确保它不会占用太多的字符。
似乎有些元素返回相同的哈希值（crc16算法）。
我把has转换成字符串：crc.ToString（＆＃34; X4＆＃34;）; 例如，两个不同的元素给了我：5A8E。
我尝试使用crc32，但如果我这样做，那么旧的背景将无法识别。
你知道我怎么能找到解决方案吗？非常感谢
答案 0 :(得分：6)
即使CRC16是一个理想的散列函数（它不是），只有16位，Birthday Paradox意味着大约有50％的机会发生散列冲突。一组只有2 ^ 8 = 256项。你几乎肯定需要更多的位。
你不能让老哈希工作和让他们区分现有的冲突 - 这是一个矛盾。但是你可以实现一个新的，更好的散列方案，在URL参数中添加一个标志，表明你正在使用这个新方案，确保你的所有页面只生成这些新式URL，＆＃34;祖父在＆＃34;旧式URL（将继续产生与以前相同的冲突）。我建议每当您获得旧式网址时，都会向用户发送一条大而明亮的消息来更新其书签，并自动重定向页面。
答案 1 :(得分：0)
解释我想到的另一个解决方案，我正在实施。
我只是为我的元素准备了一个crc32和一个crc16哈希。我使用32作为我现在构建的新网址，但使用crc16哈希作为旧网址的后备。
所以，当我尝试比较哈希时，我从新哈希开始，如果我找不到任何元素，我会回到我的后备并将其与crc16哈希进行比较。
这允许我得到任何案件。