Что делает значение & 0xff в Java?

Он устанавливает result в (беззнаковое) значение, полученное в результате ввода 8 бит value в наименьшие 8 бит result .

Причина, по которой это необходимо, заключается в том, что byte является подписанным типом в Java. Если вы только что написали:

 int result = value; 

то result будет иметь значение ff ff ff fe вместо 00 00 00 fe . Еще одна тонкость заключается в том, что значение & определено для работы только с значениями int ¹ , поэтому происходит следующее:

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 .}

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

Шестнадцатеричный литерал 0xFF является равным int (255). Java представляет int как 32 бита. В двоичном виде это выглядит так:

 00000000 00000000 00000000 11111111 

Когда вы делаете бит мудрый И с этим значением (255) на любом количестве, он будет маскировать (делать 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 и любое значение от 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; 

ReSet (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 

Вышеизложенное полезно заменить две переменные без темпа, как показано ниже

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

ИЛИ

 a ^= b ^= a ^= b; 

Это помогает сократить количество кодов. Он иногда используется в значениях RGB, которые состоят из 8 бит.

где 0xff означает 24 (0) и 8 (1), как 00000000 00000000 00000000 11111111

Он эффективно маскирует переменную, поэтому оставляет только значение в последних 8 битах и ​​игнорирует все остальные биты

Это чаще всего наблюдается в случаях, когда вы пытаетесь преобразовать значения цвета из специального формата в стандартные значения RGB (длиной 8 бит).

Великое объяснение См. Здесь

В 32-битной системе формат шестнадцатеричное значение 0xff представляет 00000000000000000000000011111111 что равно 255(15*16^1+15*16^0) в десятичной системе. и побитовый & оператор маскирует те же самые 8 правых битов, что и в первом операнде.