是否可以有效使用更改音频 (mp3) 文件的哈希值

Question

我要创建一个音乐库程序，很简单。存储信息，很简单。

我之前看过另一个用c#制作的音乐库，那个家伙声称即使你移动了文件，重新发现它也会知道从数据库（xml，sql）中检索到的关于该文件的所有信息。

关于重新发现的更多信息：当您移动文件时，您必须让音乐库重新发现，因为它的当前信息是错误的，例如文件路径，重新发现时它会找到文件，在数据库中检查它，然后更新任何信息

我认为这是不可能的，直到现在。如果您散列一个文件并将该散列用作密钥，那么您可以使用它来始终检查文件以确保它是那个文件。

如果我错了，请纠正我并确认我所说的是真的（这是问题）。

• 文件路径未用于散列文件。 （我不知道如何散列）
• 每次写入 ID3 标签后重新散列（更改文件会更改散列？）
• 使用 Hash 作为 Key/Id 意味着如果文件被移动，它仍然可以被引用到存储的关于它的信息
• 从 xml（如果我们将 xml 用作数据库）文件中读取信息后，将其存储在字典中是将内容存储在内存中的最快和最好的方法

这是一个问题，它需要一个答案，它是关于 c# 的。我正在使用 c#，这就是为什么它是特定的，我正在做背景研究，我只是想对我所说的内容发表一些专家意见

Answer 1

回答您的问题

• 计算哈希时不应使用文件路径。既不是文件名也不是扩展名。

• 如果所有更改都发生在您的应用程序中，则每次写入 ID3 标记后重新散列将解决您的问题

• 哈希可以安全地用作您的密钥（见下文）

• 如果我理解正确的话，可能是的

重复哈希值的可能性

根据您选择的哈希函数，如果您搜索，您将在年、千年、十亿年找到/生成具有相同哈希值的另一个文件，或者直到世界末日您都不会这样做。

这都是概率问题。检查details of each hashing function，了解找到另一个具有相同哈希值的文件的概率有多低。

mp3文件中标签改变的问题

虽然这可能是个问题，但您需要做的只是散列文件中不是 ID3 标记的部分。它们通常位于文件的末尾，只占文件大小的很小百分比。

您可以做的是在不会更改的文件部分使用散列函数。 散列时只需跳过文件的最后 N 个字节。

Answer 2

是的，如果你散列 文件内容，那么即使文件移动到其他地方，当你再次执行它时，它仍然会产生相同的散列。所以是的，您可以完全根据文件内容的哈希值识别文件（例如，这就是 Git 所做的）。至于创建文件的哈希，有几个问题会告诉你如何做，例如this one。

请注意，由于 ID3 标记和其他内容，您的文件不是不可变的，因此对文件内容进行散列处理可能不是最好的主意。如果你改变一个文件的标签，它的哈希值会改变，产生一个 new 文件（至少对于你的应用来说）。当然，如果您更改应用程序中的标签，那么您可以轻松跟踪这些更改并更新旧记录以使用新哈希。同样的想法也可以应用于根据文件的路径来识别文件（如果你在应用程序中移动它，你也可以在数据库中更新它的路径）。但问题是这两种操作都可能发生在您的应用程序之外。

因此这两种识别方法（文件内容的散列或文件路径）都存在一些缺陷，但没有真正的替代方法来识别文件。

Answer 3

散列对你有用。它基本上根据文件中的所有字节创建校验和。使用良好的哈希将为您提供每个文件的唯一签名（如果找到两个具有相同哈希的不同文件，则连续五次中奖的机会更大）。

问题是您需要读取整个文件来计算哈希。这可能会稍微损害性能。

所以在重新发现时，您可能需要先检查文件大小是否相同。如果没有，则无需读取整个文件并计算哈希。但是您需要为此存储文件大小和哈希。

关于散列的一些信息（使用 MD5 方法）

http://www.fastsum.com/support/md5-checksum-utility-faq/md5-hash.php