有谁有 C++ 中的 CRC128 和 CRC256 代码吗?和C#?
我正在学习,试图了解 CRC 背后的想法。我在任何地方都找不到 CRC128 和 CRC256 代码。如果你们中有人有 C++ 或 C# 代码,请与我分享。还提供网站的在线链接。我是一个新手,根本不会自己编码,也不能将理论和数学转化为编码。所以我请求你的帮助。如果您为我提供正确且简单的代码,那就太好了。如果有人向我提供这些代码,请同时提供 CRC 表生成器函数。谢谢。
I am learning, trying to get thoughts behind CRC. I can't find CRC128 and CRC256 code anywhere. If anyone of you have the C++ or C# Code for them, please share them with me. Also provide online links to the websites. I am a newbie and can't code it by myself at all, neither can convert theories and mathematics to the coding. So I ask for help from you. It will be so nice of you who provide me the proper and simple codes. If anyone provides me these codes, please do also provide CRC Table generator functions. Thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
尽管定义了 CRC-128 和 CRC-256,但我不知道有谁真正使用它们。
大多数时候,认为自己需要 CRC 的开发人员实际上应该使用加密哈希函数 ,它已经在许多应用中成功地实现了 CRC。在极少数情况下,CRC-128 或 CRC-256 甚至比损坏的 MD5 更优越,更不用说 SHA-2 系列了。
Though CRC-128 and CRC-256 were defined, I don't know of anyone who actually uses them.
Most of the time, developers who think they want a CRC should really be using a cryptographic hash function, which have succeeded CRCs for many applications. It would be a rare case indeed where CRC-128 or CRC-256 would be a superior choice to even the broken MD5, much less the SHA-2 family.
我同意你的观点,只是对于 32 位和 64 位 CRC,意外冲突率分别高于 2^32 分之一或 2^64 分之一。
我编写了一个应用程序,通过 CRC 值来跟踪事物,以跟踪项目。我们需要跟踪潜在的数百万个项目,我们从 CRC32 开始,在现实世界的实践中,其冲突率约为 2^16 中的 1,这是一个令人不快的意外。然后我们重新编码以使用 CRC64,其实际冲突率约为 2^23 中的 1。我们在对 32 位版本感到不愉快之后对此进行了测试,并接受了 64 位版本的较小错误率。
我无法真正解释预期冲突率背后的统计数据,但有道理的是,您会比位宽度更快地经历碰撞。就像哈希表一样...一些哈希桶是空的,而另一些哈希桶有多个条目...
即使对于 256 位 CRC,前 2 个 CRC 也可能是相同的...这几乎令人难以置信,但却是可能的。
I agree with you except that the accidental collision rate is higher than 1 in 2^32 or 1 in 2^64 for 32 bit and 64 bit CRCs respectively.
I wrote an app that kept track of things by their CRC values for tracking items. We needed to track potentially millions of items and we started with a CRC32 which in real world practice has a collision rate of around 1 in 2^16 which was an unpleasant surprise. We then re-coded to use a CRC64 which had a real world collision rate of about 1 in 2^23. We tested this after the unpleasant surprise of the 32 bit one we started with and accepted the small error rate of the 64 bit one.
I can't really explain the statistics behind the expected collision rate but it makes sense that you would experience a collision much sooner that the width of the bits. Just like a hashtable...some hash buckets are empty and others have more than one entry....
Even for a 256 bit CRC the first 2 CRC's could be the same...it would be almost incredible but possible.
这是我最近编写的一个用于处理 CRC 的 Java 类。请注意,更改位顺序仅适用于按位计算。
Here is a Java class I wrote recently for playing with CRCs. Beware that changing the bit order is implemented only for bitwise computation.
仅当以下三点为真时,CRC-128 和 CRC-256 才有意义:
2 和 3 可以同时成立的典型情况是,如果意外冲突会造成数据丢失,则只会影响数据发送者,而不影响平台。
CRC-128 and CRC-256 only make sense if the three following point are true :
A typical case where 2 and 3 can be true together is if an accidental collision would create a data loss that only affects the sender of the data, and not the platform.