是否可以有效地使用更改音频(mp3)文件的哈希值
本文关键字：mp3 文件 哈希值 音频 有效地 是否 | 更新日期: 2023-09-27 18:09:17
我要创建一个音乐库程序，很简单。存储信息，简单。
我之前看过另一个用c#制作的音乐库，那个家伙声称即使你移动了文件，在重新发现时它也会知道从数据库(xml, sql)检索到的关于该文件的所有信息。
关于重新发现的更多信息:当你移动文件时，你必须让音乐库重新发现，因为它当前的信息是错误的，比如文件路径，在重新发现它会找到文件，在数据库中检查它，并更新任何信息
我认为这是不可能的，直到现在。如果你散列一个文件，并使用该散列作为密钥，那么你就可以用它来检查文件，以确保它是正确的。如果我说错了，请纠正我，并确认我说的是真的(这就是问题所在)。
- 文件路径不用于散列文件。(我不知道怎么散列)
- 每次写入ID3标签后重新散列(更改文件会更改散列?)
- 使用Hash作为Key/Id将意味着如果文件被移动，它仍然可以引用存储的关于它的信息
- 一旦从xml(如果我们使用xml作为数据库)文件中读取信息，将其存储在字典中是将内容存储在内存中的最快和最好的方法
这是一个问题，它需要一个答案，是关于c#的。我正在使用c#，这就是为什么它是特定的，我正在做背景研究，我只是想要一些专家的意见对于我所说的
回答您的问题
- 在计算哈希值时不应使用
文件路径。
每次ID3标签写入后重新散列将解决您的问题，前提是所有更改都发生在您的应用程序中
散列可以安全地用作您的目的的密钥(见下文)
可能是的，如果我没理解错的话
哈希值重复的可能性
根据你选择的哈希函数，如果你搜索，你会发现/生成另一个具有相同哈希值的文件，在年，千年，十亿年，或者你不会做，直到世界末日。
这都是概率的问题。检查每个哈希函数的详细信息，以了解找到具有相同哈希值的另一个文件的概率有多低。
mp3文件中标签改变的问题
虽然这可能是一个问题，但您需要做的是只对文件中不是ID3标记的部分进行散列。它们通常位于文件的末尾，只占文件大小的很小一部分。
你能做的是对文件中不需要修改的部分使用哈希函数。在散列时，只需跳过文件的最后N个字节。
是的，如果您散列文件内容，那么即使文件移动到其他地方，当您再次执行该操作时，它仍然会产生相同的散列。所以，是的，您完全可以根据内容的哈希值来识别文件(例如，Git就是这样做的)。至于创建文件的散列，有几个问题可以告诉您如何做，例如下面这个。
请注意，由于ID3标记和其他东西，您的文件不是不可变的，因此对文件内容进行哈希可能终究不是最好的主意。如果更改一个文件的标记，它的哈希值也会改变，从而产生一个新的文件(至少对您的应用程序来说是这样)。当然，如果您更改了应用程序中的标签，那么您可以很容易地跟踪这些更改并更新旧记录以使用新的散列。同样的思想也可以应用于基于路径来识别文件(如果您在应用程序中移动它，您也可以更新它在数据库中的路径)。但问题是，这两个操作都可能发生在应用程序之外。
所以这两种识别方法(文件内容的散列，或文件路径)都有些缺陷，但是没有真正的替代方法来识别文件。
哈希将为您工作。它基本上基于文件中的所有字节创建一个校验和。使用一个好的哈希会给你每个文件一个唯一的签名(连续五次中彩票的机会比用相同的哈希找到两个不同的文件的机会大)。
问题是你需要读取整个文件来计算哈希值。这可能会影响性能。
因此，在重新发现时，您可能需要首先检查文件大小是否相同。如果不是，则不需要读取整个文件并计算哈希值。但是你需要存储文件大小和哈希值。
关于散列的一些信息(使用MD5方法)
http://www.fastsum.com/support/md5-checksum-utility-faq/md5-hash.php