Recabamos por el mundo online para así tener para ti la solución a tu duda, si continúas con dudas puedes dejar la duda y te contestamos porque estamos para ayudarte.
Solución:
Establece result al valor (sin firmar) resultante de poner los 8 bits de value en los 8 bits más bajos de result.
La razón por la que algo como esto es necesario es que byte es un tipo firmado en Java. Si acaba de escribir:
int result = value;
entonces result terminaría con el valor ff ff ff fe en vez de 00 00 00 fe. Otra sutileza es que el & está definido para operar solo en int valores1, entonces lo que pasa es:
valuees ascendido aint(ff ff ff fe).0xffes unintliteral00 00 00 ff).- El
&se aplica para producir el valor deseado pararesult.
(El punto es que la conversión a int sucede antes de el & se aplica el operador.)
1Bueno, no del todo. El & el operador trabaja en long valores también, si cualquiera de los operandos es un long. Pero no en byte. Consulte la Especificación del lenguaje Java, secciones 15.22.1 y 5.6.2.
De http://www.coderanch.com/t/236675/java-programmer-SCJP/certification/xff
El literal hexadecimal 0xFF es un int (255) igual. Java representa int como 32 bits. Se ve así en binario:
00000000 00000000 00000000 11111111
Cuando lo hace un poco Y con este valor (255) en cualquier número, va a enmascarar (hacer CERO) todos menos los 8 bits más bajos del número (será como está).
... 01100100 00000101 & ...00000000 11111111 = 00000000 00000101
& es algo así como% pero no realmente.
¿Y por qué 0xff? esto en ((potencia de 2) – 1). Todos ((potencia de 2) – 1) (por ejemplo, 7, 255 …) se comportarán de forma similar al operador%.
Entonces
En binario, 0 es, todo ceros y 255 se ve así:
00000000 00000000 00000000 11111111
Y -1 se ve así
11111111 11111111 11111111 11111111
Cuando hace un AND bit a bit de 0xFF y cualquier valor de 0 a 255, el resultado es exactamente el mismo que el valor. Y si todavía hay algún valor superior a 255, el resultado estará entre 0-255.
Sin embargo, si lo hace:
-1 & 0xFF
usted obtiene
00000000 00000000 00000000 11111111, que NO es igual al valor original de -1 (11111111 es 255 en decimal).
Pocas manipulaciones de bits más: (No relacionado con la pregunta)
X >> 1 = X/2
X << 1 = 2X
Verifique que cualquier bit en particular esté establecido (1) o no (0) y luego
int thirdBitTobeChecked = 1 << 2 (...0000100)
int onWhichThisHasTobeTested = 5 (.......101)
int isBitSet = onWhichThisHasTobeTested & thirdBitTobeChecked;
if(isBitSet > 0)
//Third Bit is set to 1
Establecer (1) un bit en particular
int thirdBitTobeSet = 1 << 2 (...0000100)
int onWhichThisHasTobeSet = 2 (.......010)
onWhichThisHasTobeSet |= thirdBitTobeSet;
Restablecer (0) un bit en particular
int thirdBitTobeReSet = ~(1 << 2) ; //(...1111011)
int onWhichThisHasTobeReSet = 6 ;//(.....000110)
onWhichThisHasTobeReSet &= thirdBitTobeReSet;
XOR
Solo tenga en cuenta que si realiza la operación XOR dos veces, obtendrá el mismo valor.
byte toBeEncrypted = 0010 0110
byte salt = 0100 1011
byte encryptedVal = toBeEncrypted ^ salt == 0110 1101
byte decryptedVal = encryptedVal ^ salt == 0010 0110 == toBeEncrypted :)
Una lógica más con XOR es
if A (XOR) B == C (salt)
then C (XOR) B == A
C (XOR) A == B
Lo anterior es útil para intercambiar dos variables sin temperatura como a continuación
a = a ^ b; b = a ^ b; a = a ^ b;
O
a ^= b ^= a ^= b;
Ayuda a reducir muchos códigos. Ocasionalmente se usa en valores RGB que constan de 8 bits.
donde 0xff significa 24 (0) y 8 (1) me gusta 00000000 00000000 00000000 11111111
Enmascara efectivamente la variable, por lo que deja solo el valor en los últimos 8 bits e ignora el resto de los bits.
Se ve más en casos como cuando se intenta transformar los valores de color de un formato especial a valores RGB estándar (que tiene una longitud de 8 bits).
Gran Explicación Ver aquí
Si tienes alguna duda o forma de progresar nuestro reseña te recordamos escribir una explicación y con mucho gusto lo ojearemos.