我实现了我发现的这个校验和算法，它工作正常，但我无法弄清楚这个"&= 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 位校验和没有的情况？
它屏蔽了较高的字节，只留下较低的字节。
checksum &= 0xFF;
在语法上是以下项的缩写：
checksum = checksum & 0xFF;
由于它正在执行整数运算，因此0xFF被扩展为int：
checksum = checksum & 0x000000FF;
它屏蔽了上面的 3 个字节，并将下部字节作为整数(而不是字节)返回。
回答您的另一个问题：由于 32 位校验和比 8 位校验和宽得多，因此它可以捕获 8 位校验和无法捕获的错误，但双方需要使用相同的校验和计算才能正常工作。
看来你对情况有很好的了解。
这是否意味着校验和 &= 0xFF 的结果是 24 位最终为零，只保留剩余的 8 位？
是的。
是否有可能出现 32 位校验和捕获损坏数据而 8 位校验和没有的情况？
是的。
这是通过添加字节(8 位值)并忽略任何溢出到高阶位来对字节(8 位值)执行简单的校验和。 正如您所怀疑的那样，最终的 &=0xFF 只是将值截断为 32 位值的 8LSB(如果这是编译器对 int 的定义)，从而导致 0 到 255 之间的无符号值。
截断为 8 位并丢弃高阶位只是为此校验和实现定义的算法。 过去，这种检查值用于提供一些信心，即字节块已通过简单的串行接口正确传输。
要回答您的最后一个问题，那么是的，32 位检查值将能够检测到 8 位检查值无法检测到的错误。
是的，校验和被截断为 8 位&= 0xFF.保留最低的 8 位，所有较高的位设置为 0。
将校验和缩小到 8 位确实会降低可靠性。想想两个不同的 32 位校验和，但最低的 8 位相等。在截断为 8 位的情况下，两者将相等，在 32 位情况下它们不是。