CRC-32 哈希的唯一性是否足以唯一标识包含文件名的字符串？答案

【问题标题】：Is the uniqueness of CRC-32-hashes sufficient to uniquely identify strings containing filenames?CRC-32 哈希的唯一性是否足以唯一标识包含文件名的字符串？
【发布时间】：2016-08-06 12:38:28
【问题描述】：

我已经对连接到字符串的文件名列表进行了排序，并希望通过唯一的校验和来识别每个这样的字符串。

这些字符串的大小最小为 100 字节，最大为 4000 字节，平均为 1000 字节。字符串的总数可以是任何东西，但更有可能在 ca 的范围内。 10000。

CRC-32 是否适合此目的？

例如我需要以下每个字符串具有不同的固定长度（最好是短）校验和：

"/some/path/to/something/some/other/path"
"/some/path/to/something/another/path"
"/some/path"
...
# these strings can get __very__ long (very long strings are the norm)

CRC-32 哈希的唯一性是否随着输入长度的增加而增加？

是否有更好的校验和可供选择？

【问题讨论】：

如果您已经有一个唯一的校验和，那么问题是什么？
最小 100 字节，最大 4000 字节，平均 1000 字节。问题是缩短这些字符串，重新计算它们，重新计算校验和，然后查看之前是否计算过校验和。我想确保 crc-32 适合这个，因为我不太了解哈希函数并尽量减少冲突概率。
您预计总共有多少个条目？猜测？ 1000、10000 (1e5)、一百万 (1e6) 还是更多？
您介意将 cmets 中的值添加到您的问题中吗？ imo，它将帮助其他人回答您的问题，因为他们知道“问题的大小”。感谢您提供的信息 - 它对我们有帮助。
imo，我会为您的应用程序查看“md5”哈希。快速且不太可能发生碰撞。它不能用于与安全有关的任何事情，imo，它将是文件名的快速查找。

标签： hash crc32 hash-code-uniqueness

【解决方案1】：

没有。

除非您的文件名全部为四个字符或更少，否则无法保证 CRC 是唯一的。对于 10,000 个名称，其中至少两个具有相同 CRC 的概率约为 1%。

这对于任何 32 位哈希值都是正确的。

为每个名称分配唯一代码的最佳方法是简单地将第一个名称的计数器从零开始，然后为每个名称递增，将计数器分配为该名称的代码。但是，这并不能帮助您计算仅给出名称的代码。

您可以使用散列，例如 CRC 或其他散列，但您需要处理冲突。文献中有几种常见的方法。您将保留一个分配了名称的哈希列表，如果发生冲突，您可以增加哈希，直到找到未使用的哈希并分配该哈希。然后在查找名称时，从计算的散列开始并对该名称进行线性搜索，直到找到它或未使用的插槽。

至于哈希，我推荐XXH64。这是一个非常快的 64 位散列。您不需要此应用程序的加密哈希，这会不必要地慢。

【讨论】：

必须相信阿德勒：D
谢谢！可悲的是，在这种情况下，我不能只使用计数器。那么......为了最大限度地减少碰撞并最大限度地提高速度，您会推荐哪种哈希函数？
您可以使用更长的哈希值尽可能减少冲突，但冲突的概率永远不会为零。除非您对仅可能有效的程序感到满意，否则您将需要处理冲突。
@MCH Git 在 160 位 SHA-1 上运行良好，但它仍然是 vulnerable to collisions。并不是说您可能会偶然遇到一个。
这真的让我思考。我的意思是哈希用于验证任意长度文件的文件完整性......当然我不想要一个“可能”工作的程序......但我在这里看不到哈希函数的方法:(@Antti哈帕拉：谢谢！