我正在将我从自己的类中定义的一些对象保存到文件中。 （保存流数据）。
这一切都很好，但我希望能够在文件中存储该文件的 CRC 校验和。
然后，每当我的应用程序尝试打开文件时，它都可以读取内部存储的 CRC 值。
然后对实际文件进行检查，如果文件的 CRC 与内部存储的 CRC 值匹配，我可以正常处理该文件，否则显示一条错误消息，表明该文件无效。
我需要一些关于如何做到这一点的建议，我想我可以做这样的事情：
- 从我的应用程序保存文件。
- 计算保存文件的 CRC。
- 编辑存储 CRC 值的已保存文件。
- 每当打开文件时，检查 CRC 是否与内部 CRC 值匹配。
问题是，一旦文件中的单个数据字节发生更改，就会导致 CRC 校验和与预期完全不同。
我通常更喜欢将 CRC 排除在检查之外的方法。但如果由于某种原因无法做到这一点，有一个解决方法：
需要预留8个字节，其中4个用于CRC，4个用于补偿数据。首先用某个虚拟值填充保留字节（例如0x00）。然后计算前 4 个字节的 CRC，最后更改其他 4 个字节，使文件的 CRC 保持不变。
有关如何执行此计算的详细信息：反转 CRC32 https://stackoverflow.com/questions/1514040/reversing-crc32
我实际上用过这个我的项目之一 https://github.com/CodesInChaos/Go-Audio-Lesson-Tool:
我正在设计一种基于 zip 的文件格式。存档中的第一个文件未压缩存储并用作头文件。这也意味着它存储在文件中的固定偏移量处。到目前为止相当标准，类似于 ePub。
现在我决定在标头中包含 sha1 哈希，为每个文件提供一个基于内容的唯一 ID 并进行完整性检查。由于标头和 sha1 哈希值位于文件中已知的偏移量，因此在哈希值很简单时将其屏蔽。因此，我输入一个虚拟哈希并创建 zip 文件，然后对文件进行哈希并填写真实哈希。
但现在有一个问题：Zip 存储了所有包含的文件的 CRC。不仅在 sha1 散列时很容易屏蔽的一个地方，而且在文件末尾附近具有可变偏移量的第二个地方。所以我决定使用 CRC 伪造，这样我就得到了强哈希，并且 zip 得到了有效的 CRC32。
由于我已经为最终文件伪造了 CRC，因此我决定为原始头文件伪造它也不会造成伤害。因此，这种格式的所有文件现在都以具有 CRC 的头文件开头0xD1CE0DD5.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
