Tag: crc

对于任何类型的文件，哪种数据类型更适合计算CRC16: 这里我使用两个不同的函数来计算任何类型文件(.txt,.tar,.tar.gz,.bin,.scr,.sh etc) CRC16，不同的大小也从1 KB to 5 GB不等。我想实现这一目标 `cross platform less time consuming Have to work proper for any type of file and any size` 我在两个函数中都获得了相同的CRC值。但任何人都可以告诉我哪个更好的计算任何类型的文件在不同的不同平台上的任何类型的文件CRC16。这里我们要考虑0到255所有类型的字符。任何人都可以建议我哪一个符合我的要求。两种function的代码：第一个在readChar有int数据类型的我在这里使用int readChar int CRC16_int(const char* filePath) { //Declare variable to store CRC result. unsigned short result; //Declare loop variables. int intInnerLoopIndex; result = 0xffff; //initialize […]

算法CRC-12: 我正在尝试为12位CRC和算法做crc_table，但总是得到错误的结果。你能帮助我吗？要创建crc表我尝试： void crcInit(void) { unsigned short remainder; int dividend; unsigned char bit; for (dividend = 0; dividend < 256; ++dividend) { remainder = dividend < 0; –bit) { if (remainder & 0x800) { remainder = (remainder << 1) ^ 0x180D; //Polynomio of CRC-12 } else { remainder = (remainder << 1); } } […]

如果只给出整个数据的CRC32，是否可以找到前缀的CRC32？: 我必须在表中进行查找，并且我有一个字符串标识符和字符串的CRC32。如果有未命中，我必须减小大小并查找标识符的前缀。因此，我需要计算前缀的校验和，并为每个前缀重复该过程。我的这个算法的C代码是这样的： find_prefix(char* string, uint16_t size, uint32_t crc, hash_table_t *hash_table){ do{ if(perform_lookup(string, size, crc, hash_table)==HIT){ return size; } size–; crc=calculate_crc(string, size, 0xFFFFFFFF); //Is there a better way? } while(size); } 我的问题是：在给定整个字符串的crc和字符串本身的情况下，我可以避免crc计算并派生前缀的crc吗？我在这里和这里找到了一些相关的问题，但是我有一个约束：当表格被普遍填充时，标识符的crc是用硬件计算的，所以我不能修改算法，并且这两个链接提供了不同的答案计算校验和的方法（基本上使用所有组件的XOR）。非常感谢你。

将Fletcher校验和从32位重新编码为8位: 这次转换是否正确？ uint8_t fletcher8( uint8_t *data, uint8_t len ) { uint8_t sum1 = 0xff, sum2 = 0xff; while (len) { unsigned tlen = len > 360 ? 360 : len; len -= tlen; do { sum1 += *data++; sum2 += sum1; tlen -= sizeof( uint8_t ); } while (tlen); sum1 = (sum1 & 0xff) + (sum1 […]

用于跨平台应用的CRC: 我希望在VB.NET或C＃应用程序以及C / Linux应用程序中使用通用CRC逻辑。我有一个与Web服务（用C＃编写）和Web应用程序（用VB.NET编写）交互的C / Linux应用程序。对于某些数据，我想从.NET端向数据本身（比如文件）添加CRC，并检查客户端上数据的完整性（检查CRC），反之亦然。有人可以指导我吗？

_mm_crc32_u8给出与参考代码不同的结果: 我一直在努力与内在论。特别是我使用标准CRC计算和所谓的等效intel内在函数得不到相同的结果。我想转向使用_mm_crc32_u16和_mm_crc32_u32但是如果我不能让8位操作工作就没有意义了。 static UINT32 g_ui32CRC32Table[256] = { 0x00000000L, 0x77073096L, 0xEE0E612CL, 0x990951BAL, 0x076DC419L, 0x706AF48FL, 0xE963A535L, 0x9E6495A3L, 0x0EDB8832L, 0x79DCB8A4L, 0xE0D5E91EL, 0x97D2D988L, …. // Your basic 32-bit CRC calculator // NOTE: this code cannot be changed UINT32 CalcCRC32(unsigned char *pucBuff, int iLen) { UINT32 crc = 0xFFFFFFFF; for (int x = 0; x > 8); } return […]

为什么使用xor和文字而不是反转（按位不是）: 我遇到过这个CRC32代码，很好奇为什么作者会选择使用它 crc = crc ^ ~0U; 代替 crc = ~crc; 据我所知，它们是等价的。我甚至在Visual Studio 2010中反汇编了这两个版本。未优化的构建： crc = crc ^ ~0U; 009D13F4 mov eax,dword ptr [crc] 009D13F7 xor eax,0FFFFFFFFh 009D13FA mov dword ptr [crc],eax crc = ~crc; 011C13F4 mov eax,dword ptr [crc] 011C13F7 not eax 011C13F9 mov dword ptr [crc],eax 我也无法通过考虑每条指令所需的周期数来certificate代码的合理性，因为两条指令都需要完成1个周期。事实上， xor可能因为必须从某个地方加载文字而受到惩罚，尽管我不确定这一点。所以我认为它可能只是描述算法的首选方式，而不是优化……这是正确的吗？编辑1： […]

快速CRC算法？: 我想用ASCII字符串创建一个32位数字。 CRC32算法正是我正在寻找的，但我无法使用它，因为它需要的表太大了（它适用于资源非常少的嵌入式系统）。那么：对快速而纤薄的CRC算法的任何建议？与原始CRC32相比，何时碰撞更可能无关紧要。谢谢！

_mm_crc32_u64定义不明确: 为什么世界上_mm_crc32_u64(…)定义是这样的？ unsigned int64 _mm_crc32_u64( unsigned __int64 crc, unsigned __int64 v ); “crc32”指令总是累加32位CRC，而不是 64位CRC（毕竟，CRC32不是CRC64）。如果机器指令CRC32 恰好具有64位目标操作数，则忽略高32位，并在完成时填充0，因此没有使用EVER具有64位目标。我理解为什么英特尔允许在指令上使用64位目标操作数（为了均匀性），但如果我想快速处理数据，我想要一个尽可能大的源操作数（即如果剩下那么多数据，则为64位，尾部较小）并且始终是32位目标操作数。但内在函数不允许使用64位源和32位目标。注意其他内在函数： unsigned int _mm_crc32_u8 ( unsigned int crc, unsigned char v ); “crc”的类型不是8位类型，也不是返回类型，它们是32位。为什么没有 unsigned int _mm_crc32_u64 ( unsigned int crc, unsigned __int64 v ); ？英特尔指令支持这一点，这是最有意义的内在因素。有没有人有可移植的代码（Visual Studio和GCC）来实现后者的内在？谢谢。我的猜测是这样的： #define CRC32(D32,S) __asm__(“crc32 %0, %1” : […]

C的确定CRC: 由于CRC被如此广泛地使用，我很惊讶在C中很难找到CRC实现。对于C，是否存在“确定的”CRC计算片段/算法，“每个人”都使用？或者：是否有一个很好的CRC实现，有人可以保证，并指向我？我正在寻找CRC8和CRC16实现。想想看，我的情况可能有点不同寻常。我正在为Linux编写C代码，代码最终应该移植到微控制器上。似乎有些微控制器API确实带有CRC实现; 无论如何，我正在寻找一个通用的软件实现（我读到CRC原本是硬件实现的）。