使用Boost计算ECMA-128 64位CRC
使用下面的程序，我正在尝试计算一个64bit CRC as per the ECMA-128 standard。
测试数据是"123456789“，我正在尝试匹配here提供的相同数据，这表明CRC-64/ECMA-182的结果应该是62ec59e3f1a4f00a。不幸的是，我得到了9d13a61c0e5b0ff5，这是CRC-64/WE的结果。
我从here提供的示例代码开始。我使用ECMA-12864位循环冗余码的0x42F0E1EBA9EA3693的正常多项式表示创建了64位散列。
我得到以下VS警告: C4293：'<<'：移位计数为负或太大，未定义的行为。它适用于此宏：
BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits )) );据我所知，0被移位了64位的全范围，这是未定义的行为。我很惊讶我没有看到32位crc的这个警告。
如何更正此程序以正确计算ECMA-128 64位crc，而不会有未定义的行为？
// from https://www.boost.org/doc/libs/1_67_0/libs/crc/crc.html#usage
#include <boost/crc.hpp> // for boost::crc_basic, boost::crc_optimal
#include <boost/cstdint.hpp> // for boost::uint16_t
#include <algorithm> // for std::for_each
#include <cassert> // for assert
#include <cstddef> // for std::size_t
#include <iostream> // for std::cout
#include <ostream> // for std::endl
//#define SHOW_ERROR
#if defined( SHOW_ERROR )
#define CRC ecma_crc // expected
#else
#define CRC other_crc // actually received
#endif
int main()
{
// This is "123456789" in ASCII
unsigned char const data[] = {0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39};
std::size_t const data_len = sizeof(data) / sizeof(data[0]);
// The expected CRC for the given data
boost::uint16_t const expected = 0x29B1;
// Expected CRCs for "123456789" as per https://www.nitrxgen.net/hashgen/
long long const other_crc = 0x9D13A61C0E5B0FF5; // Wolfgang Ehrhardt http://www.wolfgang-ehrhardt.de/crchash_en.html
long long const ecma_crc = 0x62EC59E3F1A4F00A; // CRC-64-ECMA-128 https://en.wikipedia.org/wiki/Cyclic_redundancy_check
// Simulate CRC-CCITT
boost::crc_basic<16> crc_ccitt1(0x1021, 0xFFFF, 0, false, false);
crc_ccitt1.process_bytes(data, data_len);
assert(crc_ccitt1.checksum() == expected);
// Repeat with the optimal version (assuming a 16-bit type exists)
boost::crc_optimal<16, 0x1021, 0xFFFF, 0, false, false> crc_ccitt2;
crc_ccitt2 = std::for_each(data, data + data_len, crc_ccitt2);
assert(crc_ccitt2() == expected);
// Attempt 64 bit CRC
boost::crc_basic<64> crc_64_ecma1(0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false);
crc_64_ecma1.process_bytes(data, data_len);
assert(crc_64_ecma1.checksum() == CRC);
boost::crc_optimal<64, 0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false> crc_64_ecma2;
crc_64_ecma2 = std::for_each(data, data + data_len, crc_64_ecma2);
assert(crc_64_ecma2() == CRC);
std::cout << "All tests passed." << std::endl;
return 0;
}回答 1
Stack Overflow用户
发布于 2018-06-09 12:19:17
请逐位仔细查看62ec59e3f1a4f00a和9d13a61c0e5b0ff5。你看到这两者之间的关系了吗？
更新：
好的!你也看到了。(我讨厌剥夺别人发现的乐趣。)至于原因，您可以在Greg Cook's CRC catalog中查找ECMA-182CRC的定义，在那里简称为CRC64：
width=64 poly=0x42f0e1eba9ea3693 init=0x0000000000000000 refin=false refout=false xorout=0x0000000000000000 check=0x6c40df5f0b497347 residue=0x0000000000000000 name="CRC-64"这定义了CRC的初始值为零，以及最终异或为零，即不改变。这对于CRC来说并不常见，因为它会导致任意长度的零的字符串具有相同的CRC，等于零。
这里还定义了CRC-64/WE，它提供：
width=64 poly=0x42f0e1eba9ea3693 init=0xffffffffffffffff refin=false refout=false xorout=0xffffffffffffffff check=0x62ec59e3f1a4f00a residue=0xfcacbebd5931a992 name="CRC-64/WE"这更常见，对于初始化和异或两者都是1，因为0字符串的CRC将取决于字符串的长度，而零长度消息的CRC是0。
然而，这与您提供的链接处的计算结果不一致。您提供的链接计算的初始值为0，而Greg的目录中的定义将CRC初始化为全1。他们中只有一个是正确的。
更新2：
格雷格的目录是正确的。链接的在线哈希计算器错误。我通过查看CRC -64/WE中的"WE“source code (a zip file)验证了CRC的定义。链接计算器是双重错误的，因为它给出了CRC-64/WE校验值62ec...作为CRC-64/ECMA-182的结果，并且它给出的CRC-64/WE的结果既不匹配CRC-64。当心你在互联网上找到的东西。
https://stackoverflow.com/questions/50765230
复制相似问题