校验和中的“int &= 0xFF”有什么作用？答案

【问题标题】：What does "int &= 0xFF" in a checksum do?校验和中的“int &= 0xFF”有什么作用？
【发布时间】：2018-04-11 14:54:33
【问题描述】：

我实现了我发现的这个校验和算法，它工作正常，但我无法弄清楚这个“&= 0xFF”行实际上在做什么。

我查找了按位 & 运算符，维基百科声称它是 A 中所有位与 B 的逻辑与。我还读到 0xFF 等于 255——这应该意味着所有位都是 1。如果你取任何数字& 0xFF，那不就是数字的身份吗？所以 A & 0xFF 会产生 A，对吧？

然后我想，等一下，下面代码中的校验和是 32 位 Int，但 0xFF 是 8 位。这是否意味着校验和 &= 0xFF 的结果是 24 位最终为零，只保留剩余的 8 位？在这种情况下，校验和被截断为 8 位。这是怎么回事？

    private int CalculateChecksum(byte[] dataToCalculate)
    {
        int checksum = 0;

        for(int i = 0; i < dataToCalculate.Length; i++)
        {
            checksum += dataToCalculate[i];
        }

        //What does this line actually do?
        checksum &= 0xff;

        return checksum;
    }

另外，如果结果被截断为 8 位，是不是因为 32 位在校验和中毫无意义？是否有可能出现 32 位校验和在 8 位校验和没有捕获损坏数据的情况下？

【问题讨论】：

+= 运算符通常会产生一个大于 255 的值。但简单的校验和通常只占用协议中的一个字节。所以 &= 0xff 丢弃了高位。简单地将校验和变量声明为字节会更容易。
@HansPassant 使用int 性能更高一些（在调试模式下，在我的机器上的 500mb 缓冲区上大约 10%），对于小型数据集并不明显，但在你说话时可能会有所不同千兆字节范围内的东西或做很多操作。

标签： c# bitwise-operators

【解决方案1】：

它屏蔽了高字节，只留下低字节。

checksum &= 0xFF;

在语法上是：

checksum = checksum & 0xFF;

其中，由于它正在执行整数运算，0xFF 被扩展为 int：

checksum = checksum & 0x000000FF;

它屏蔽了高 3 个字节，并将低字节作为整数（不是字节）返回。

回答您的另一个问题：由于 32 位校验和比 8 位校验和宽得多，它可以捕获 8 位校验和无法捕获的错误，但双方需要为此使用相同的校验和计算去工作。

【讨论】：

这可能是我睡眠不足，但它不是掩盖了除了低字节之外的所有内容吗？

【解决方案2】：

看来你很了解情况。

这是否意味着校验和 &= 0xFF 的结果是 24 位最终为零，只保留剩余的 8 位？

是的。

是否有可能出现 32 位校验和捕获损坏数据而 8 位校验和没有捕获到损坏数据的情况？

是的。

【讨论】：

【解决方案3】：

这是对字节（8 位值）执行简单的校验和，方法是将它们相加并忽略任何溢出到更高位的位。正如您所怀疑的那样，最终的 &=0xFF 只是将值截断为 32 位的 8LSB（如果这是您的编译器对 int 的定义）值，从而导致 0 到 255 之间的无符号值。

截断到 8 位并丢弃高阶位只是为此校验和实现定义的算法。从历史上看，这种检查值用于提供一些信心，即一个字节块已通过简单的串行接口正确传输。

要回答您的最后一个问题，是的，32 位校验值将能够检测到 8 位校验值无法检测到的错误。

【讨论】：

【解决方案4】：

是的，校验和被截断为 8 位 &= 0xFF.保留最低8位，所有高位设置为0。

将校验和缩小到 8 位确实会降低可靠性。想想两个不同的 32 位校验和，但最低 8 位是相等的。在截断为 8 位的情况下，两者都相等，在 32 位的情况下则不然。

【讨论】：