C#中文件的唯一ID答案

【问题标题】：Unique id for a file in C#C#中文件的唯一ID
【发布时间】：2012-03-16 11:55:26
【问题描述】：

我需要为最大 200-300MB 的文件生成一个唯一 ID。条件是算法应该很快，不应该花费太多时间。我正在从桌面选择文件并计算哈希值：

HMACSHA256 myhmacsha256 = new HMACSHA256(key);
byte[] hashValue = myhmacsha256.ComputeHash(fileStream);

filestream 是文件的句柄，用于从中读取内容。由于显而易见的原因，此方法将花费大量时间。 Windows 是否为我可以直接使用的自己的簿记生成文件的密钥？有没有其他方法可以识别文件是否相同，而不是匹配文件名，这不是很简单。

【问题讨论】：

也许你应该散列而不是流，而只是文件大小？
为什么要重新发明轮子？为什么不直接使用md5？
@mtijn，可能是因为MD5 is broken 不应该用于新的实现？
@MichaelKjörling - 除非恶意用户制造，否则您不太可能发生碰撞；而且由于 OP 没有使用 MD5 来保证安全性，我不认为这是一个问题。
我在问题中看不到任何表明是否需要抗碰撞性的内容，只是这是关于确定“文件是否相同”。

标签： c# file-io desktop-application

【解决方案1】：

MD5.Create().ComputeHash(fileStream);

或者，我建议查看this 相当相似的问题。

【讨论】：

正如我在之前的评论中所说，MD5 is broken 和 不应使用。至少据我所知，OP 已经使用的 SHA256 没有已知的重大漏洞。
OP 说“条件是算法应该很快”，他没有说任何关于安全的事情，也没有说出于安全原因使用它。这只是一个校验和。
MD5 已损坏，因此不应将其用作安全上下文中的机制，作为对一般数据进行散列以进行摘要比较的一种方式，它很好，并且具有非常快的优势。

【解决方案2】：

如何从文件本身容易获得的信息生成哈希？即连接：

文件名
文件大小
创建日期
最后修改日期

并创建自己的？

【讨论】：

滚动您自己的密码学是一个非常非常糟糕的主意。人们在这些事情上花费了数年时间并把它们弄错了——OP 做得更好的可能性有多大？此外，您列出的信息（文件大小除外）很容易更改，而文件内容保持完全相同。
当然，如果它用于安全目的。如果仅用于识别文件（我认为这是意图），为什么不呢？

【解决方案3】：

当您计算哈希值并比较它们时，这需要两个文件都完全通过。我的建议是首先检查文件大小，如果它们相同，然后逐字节检查文件。

【讨论】：

+1 偏移 -1；包括大小是优化检查的好主意。

【解决方案4】：

如果您想要“快速而肮脏”的检查，我建议您查看 CRC-32。它非常快（该算法仅涉及对表查找进行 XOR），如果您不太关心抗碰撞性，则文件大小和文件数据上的 CRC-32 校验和的组合应该足够了。需要 28.5 位来表示文件大小（使您达到 379M 字节），这意味着您获得的校验和值实际上刚好超过 60 位。我会使用 64 位的数量来存储文件大小，以备将来打样，但 32 位也适用于您的场景。

如果防碰撞性是考虑因素，那么您几乎必须使用一种久经考验但未破的加密哈希算法。但是，我仍然同意Devils child wrote 的内容，并将文件大小作为散列的单独（易于访问）部分包括在内；如果大小不匹配，则文件内容不可能相同，因此可以跳过计算密集型哈希计算。

【讨论】：