我正在写一个简单的MP3编目器来记录我的各种设备上有哪些MP3。我计划使用MD5或SHA2键来识别匹配的文件,即使它们已被重命名/移动,等等。我不想匹配逻辑上等价的MP3(即:相同的歌曲,但编码不同)。我有大约8000个MP3,其中只有6700个生成了唯一的密钥。在
我的问题是,不管我选择什么哈希算法,我都会遇到冲突。在一个例子中,我在同一张专辑中有两个碰巧是曲目1和2的文件,它们的文件大小不同,但无论我使用MD5、SHA2-256、SHA2-512等,它们都会产生相同的哈希键。。。在
这是我第一次真正在文件上使用哈希键,这是一个意外的结果。从我对这些哈希算法所知甚少,我觉得这里有点可疑。这可能是MP3或Python实现的问题吗?在
下面是我使用的代码片段:
data = open(path, 'r').read()
m = hashlib.md5(data)
m.update(data)
md5String = m.hexdigest()
如果你能对为什么会发生这种情况给出任何答案或见解,我们将不胜感激。提前谢谢。在
--更新--:
我尝试在linux(使用Python2.6)执行这段代码,但没有产生冲突。如stat调用所示,这些文件是不同的。我还下载了WinMD5,但这没有产生冲突(8d327ef3937437e0e5abpf6485c24bb3和9b2c66781cbe8c1be7d6a1447994430c)。这是Windows上Python hashlib的一个bug吗?我在Python2.7.1和2.6.6下尝试了相同的方法,结果都是一样的。在
^{pr2}$
如果几个不同的哈希算法都返回相同的哈希结果,或者您的实现中存在错误,那么您遇到问题的文件几乎肯定是相同的。在
作为一个健全的测试,编写您自己的“hash”,它只返回整个文件的内容,并查看这个是否生成相同的“hash”。在
正如其他人所说,除非文件是相同的,否则单个哈希冲突不太可能,而多个哈希几乎不可能发生。我建议使用外部实用程序生成总和,作为一种健全性检查。例如,在Ubuntu(以及大多数/所有其他Linux发行版)中:
谷歌快速搜索显示,在Windows机器上也有类似的实用程序。如果看到与外部实用程序的冲突,则文件是相同的。如果没有碰撞,说明你做错了什么。我怀疑Python的实现是错误的,因为在Python中进行散列时得到的结果是相同的:
^{pr2}$我有一种感觉,你正在读一个比预期要小的数据块,而这两个文件恰好是相同的。我不知道为什么,但是试着用'rb'打开二进制文件。read()应该读取到文件末尾,但windows的行为不同。从文件中
相关问题 更多 >
编程相关推荐