Java 中的 value & 0xff 有什么作用？

Question

我有以下 Java 代码：

byte value = 0xfe; // corresponds to -2 (signed) and 254 (unsigned)
int result = value & 0xff;

打印时的结果是 254，但我不知道这段代码是如何工作的。 如果&运算符只是按位的，那么为什么它不会产生一个字节，而是一个 integer？

Answer 1

它设置result到从推杆的8位而产生的（无符号）值value中的最低8位result 。

这样的事情是必要的，因为byte是Java中的签名类型。 如果你刚才写道：

int result = value;

然后result将以ff ff ff fe而不是00 00 00 fe 。 另一个细微之处在于&被定义为仅在int值^1上运行 ，所以会发生什么：

1. value被提升为int （ ff ff ff fe ）。
2. 0xff是一个int literal（ 00 00 00 ff ）。
3. &用于产生期望的result值。

（重点是在应用&运算符之前转换为int 。）

1 _{嗯，不太好。 如果任一操作数为long ，则&运算符也适用于long值。 但不是byte 。 请参阅Java语言规范，第15.22.1节和第5.6.2节。}

Answer 2

来自http://www.coderanch.com/t/236675/java-programmer-SCJP/certification/xff

十六进制文字0xFF是一个等于int（255）。 Java将int表示为32位。 二进制看起来像这样：

00000000 00000000 00000000 11111111

当你对任何数字的这个值（255）进行一点点明智的AND时，它将屏蔽（生成ZERO）除了数字的最低8位（将是原样）。

... 01100100 00000101 & ...00000000 11111111 = 00000000 00000101

＆是像％，但不是真的 。

为什么是0xff？ 这个（（2的幂） - 1）。 全部（（2的幂） - 1）（例如7,255 ......）将表现得像％运算符。

然后
在二进制中，0是全零，255是这样的：

00000000 00000000 00000000 11111111

-1看起来像这样

11111111 11111111 11111111 11111111

当您执行0xFF的按位AND和0到255之间的任何值时，结果与值完全相同。 如果任何高于255的值仍然结果将在0-255之内。

但是，如果你这样做：

-1 & 0xFF

你得到

00000000 00000000 00000000 11111111 ，它不等于原始值-1（ 11111111是十进制的255）。

几点操作:(与问题无关）

X >> 1 = X/2
X << 1 = 2X

检查任何特定位是否设置（1）或不设置（0）

 int thirdBitTobeChecked =   1 << 2   (...0000100)
 int onWhichThisHasTobeTested = 5     (.......101)

 int isBitSet = onWhichThisHasTobeTested  & thirdBitTobeChecked;
 if(isBitSet > 0) {
  //Third Bit is set to 1 
 } 

设置（1）特定位

 int thirdBitTobeSet =   1 << 2    (...0000100)
 int onWhichThisHasTobeSet = 2     (.......010)
 onWhichThisHasTobeSet |= thirdBitTobeSet;

重新设置（0）特定位

int thirdBitTobeReSet =   ~(1 << 2)  ; //(...1111011)
int onWhichThisHasTobeReSet = 6      ;//(.....000110)
onWhichThisHasTobeReSet &= thirdBitTobeReSet;

XOR

请注意，如果执行两次XOR运算，将产生相同的值。

byte toBeEncrypted = 0010 0110
byte salt          = 0100 1011

byte encryptedVal  =  toBeEncrypted ^ salt == 0110 1101
byte decryptedVal  =  encryptedVal  ^ salt == 0010 0110 == toBeEncrypted :)

XOR的另一个逻辑是

if     A (XOR) B == C (salt)
then   C (XOR) B == A
       C (XOR) A == B

以上内容对于交换两个没有temp的变量非常有用，如下所示

a = a ^ b; b = a ^ b; a = a ^ b;

要么

a ^= b ^= a ^= b;

Answer 3

它有助于减少许多代码。 它偶尔用于由8位组成的RGB值。

其中0xff表示24（0）和8（1）表示 00000000 00000000 00000000 11111111

它有效地屏蔽变量，因此它只留下最后8位的值，并忽略所有其余的位

在尝试将颜色值从特殊格式转换为标准RGB值（8位长）时，大多数情况下都会出现这种情况。

很好的解释见这里

Answer 4

在32位格式系统中，十六进制值0xff表示以十进制表示的255(15*16^1+15*16^0) 00000000000000000000000011111111 。 并且按位＆运算符屏蔽与第一个操作数中相同的8个最右位。