我正在寻找一种有效的方法来判断自上次查看字符串(或文件)以来是否发生了变化。
因此,我们针对 1,000,000 个文件/字符串(每个文件/字符串小于 1000 字节)运行此函数,并存储每个文件/字符串的输出。
然后,我将等待几天并再次运行它。我需要找出每个文件是否已更改...
我应该为每个文件计算 CRC32 吗?MD5?还有什么更高效的吗?
CRC32 是否足以告诉我文件/字符串是否已更改?
编辑它必须同时工作文件和字符串,所以文件上的时间戳是不可能的。
对于文件,您可以使用时间戳。
对于字符串,您可以保留备份副本。
仅比较它们并重新编写备份可能与 CRC 或 MD5 一样快。
CRC32 或 CRC64 可以很好地完成这项工作。
您甚至可以将它用作某种哈希查找的基础。
你说数据应该是大约一百万个 1kB 的字符串/文件,你想每隔几天检查一次。如果这是真的你真的不必担心性能,因为处理 1GB 的数据不会花费那么长时间,你使用 crc32 还是 md5 都没关系。
我建议使用 md5,因为它比 crc32 更不容易发生碰撞。Crc32 可以完成这项工作,但您无需更多投资即可获得更好的结果。
编辑:正如其他人所说,将字符串与备份进行比较更快。(因为您可以在两个字符不同时立即中止)如果您必须从文件中读取字符串,这不是 100% 正确的。如果我们假设字符串来自文件并且您使用 md5,则您必须读取 32 个字节加上要比较的每个字符串的平均字符串长度。当您逐字节比较时,您必须读取最少 2 个字节,最多读取字符串长度的两倍。因此,如果您的许多字符串具有相同的开头(字符数超过 32 + 字符串长度的平均值相等),那么使用散列会更快。(如果我错了,请纠正我)因为这是一个理论案例,所以您可以坚持逐个字符比较。如果字符串长度的平均值大于 32 个字节,则
但正如我上面已经说过的;在处理大量数据时,性能不会成为您的问题。
字符串比较将比 crc32 或 md5 或任何其他建议的哈希算法更有效。
对于初学者,只要两个字符串不同,您就可以退出字符串比较,而使用散列算法,您必须先对文件的全部内容进行散列,然后才能进行比较。
更重要的是,散列算法具有生成散列必须执行的操作,而字符串比较是检查两个值之间的相等性。
我想象一个基于字符串的文件/字符串的比较,在第一次失败(每个文件/字符串)时短路会给你带来良好的性能。
对于文件,您必须查看内容吗?文件系统将跟踪修改后的时间戳。
在 Java 中,您可以执行以下操作:
File file = new File(filePath);
file.lastModified();
我用 MD5 做这种事情,似乎效果很好。如果您使用的是 .NET,请参阅 System.Security.Cryptography.MD5CryptoServiceProvider。
为了完整性:CRC32 和 MD5 可能会告诉一个字符串没有改变,而事实上它已经改变了(因为存在具有相同 CRC32 或 MD5 的唯一字符串)。