побитовое AND с 0xff важно?

Разве побитовое AND с 0xff по сути не означает возвращение того же значения в этом коде?

byte[] packet = reader.readPacket();
short sh;
sh = packet[1];
sh &= 0xFF;
System.out.print(sh+" ");

Странно, я получаю -1, если этот ANDing не включен, но 255, когда включен. Может ли кто-нибудь объяснить причину?

На мой взгляд, 0xff - это всего лишь 1111 1111. Не так ли?

12 голосов | спросил Shashank Sabniveesu 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 28 Sep 2013 03:23:07 +0400 2013, 03:23:07

3 ответа


0

Да, 0xff - это просто 1111 1111. Но он пытается отобразить значение байта без знака, даже если в Java byte подписаны. Значение 0xff равно -1 для подписанного byte, но это 255 в ---- +: = 7 =:. + ----

Когда значение short для byte читается, печать значения приведет к 0xff. Поэтому он присваивается -1, который имеет больший диапазон и может хранить short значения, которые обычно переполняются, чтобы быть отрицательным числом как byte как положительное целое число, например 144 как byte является byte, или -112, но его можно правильно сохранить как 0x90 как 144

Итак, значение short для byte назначается -1. Но что это делает? Происходит расширение примитивного расширения, а отрицательные значения расширяются знаком. Так что short становится 1111 1111, все еще 11111111 11111111, но на этот раз как -1.

Тогда битовая маска short (0xff) используется, чтобы снова получить последние 8 битов:

00000000 11111111

Это просто способ получить беззнаковое значение -1: 11111111 1111111 0xFF: 00000000 1111111 ====================== 255: 00000000 1111111 , преобразовав его в byte, а затем маскируя исходные биты из short, чтобы отобразить его как значение без знака .

ответил rgettman 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 28 Sep 2013 03:30:18 +0400 2013, 03:30:18
0

A byte имеет диапазон от -128 до 127. Это означает, что некоторые значения являются отрицательными. Это все значения, где установлен верхний бит. Итак, (byte) 0xFF равно -1. Когда вы используете расширение знака, чтобы сделать его коротким со знаком, оно становится (short) 0xFFFF, что равно -1 как короткое. Когда вы маскируете его, он отсекает расширенные биты, и вы обрабатываете байт, как если бы он был беззнаковым.


Вы не получите -1, если ваш код отличается от того, что у вас есть в вопросе.

for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) {
    short s = b;
    s &= 0xff;
    System.out.println(b + " & 0xFF = " + s);
}

печатает

-128 & 0xFF = 128
-127 & 0xFF = 129
....
-2 & 0xFF = 254
-1 & 0xFF = 255
0 & 0xFF = 0
1 & 0xFF = 1
...
125 & 0xFF = 125
126 & 0xFF = 126
ответил Peter Lawrey 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 28 Sep 2013 03:31:17 +0400 2013, 03:31:17
0

(Предполагая, что два дополняют друг друга) Две вещи:

  1. Байты подписаны, поэтому 0xff в байте равно -1.
  2. При переходе от меньшего типа данных к большему типу данных (в данном случае от byte к short), значение сохраняется. Таким образом, sh = packet[1] установит для sh значение ---- +: = 5 =: + ----, то есть -1.

С точкой # 2 дело в том, что «дополнительные» биты дополняются единицами, чтобы сохранить значение всякий раз, когда исходное значение является отрицательным. Идея, лежащая в основе ANDing с 0xffff, заключается в том, что 0xff теперь содержит sh, и эти «лишние» единицы теперь удалены.

ответил Dennis Meng 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 28 Sep 2013 03:30:11 +0400 2013, 03:30:11

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132