为什么按位和0xFF负有符号整数将导致正有符号整数？[重复]

Question

我的目标是了解两者的互补性。

有符号整数中的10000111等于-121。但是，如果您使用十六进制的0xFF或十进制的11111111按位与它，它将等于135。

在我看来，这不应该发生，因为顶部字节10000111与结果字节10000111相同

    10000111
AND 11111111
------------
    10000111 = 135.

我的预期结果是该值不应该改变，它等于< code>-121。

我的实际结果是值发生变化。

我的猜测是，0xFF是一个无符号位。因此，顶部字节的有符号位1和下部字节的无符号位1将导致无符号位1。但是......那不可能是对的。

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class WebSocketWorkerThreadTest {
  @Test
  void SignedToUnsignedInteger() {
    byte signed = (byte) 0b10000111;
    // If java uses unsigned integer, it should be 135. however, java uses signed integer. Therefore, the outputs will be -121
    // 10000111
    // ^
    // the sign bit. If it exists then the value will be negative.
    Assertions.assertEquals(-121, signed);
    // 10000111
    // 11111111
    // --------
    // 10000111
    int unsigned = signed & 0xFF;
    Assertions.assertEquals(135, unsigned);
  }
}

Answer 1

匿名用户

Java 将整数（长整型和字节型）存储在两者的补码中。参见维基百科/维基/两s_complement

在这个表示中，任何负数都以一串1位开始，因为值< code>10000...0000是最小的可表示值，值< code>1111...111是-1。因此，当您剪切前导1位时，您会将该数字完全上移至正范围，因为新数字不再以1位开头。

在您的情况下，您使用byte，但byte的值没有您期望的形式。它是一个整数，当

Answer 2

当您应用时，签名的被提升为int

不是< code>10000111

这里的MSB为零，因此为正。

如果您将其转换回一个字节，这只需要8个LSB，则该字节将再次为负。