После чтения в байтах из файла, большинство верны, кроме 1 неправильного и отрицательного

Question

В Java я просто читаю файл в ByteBuffer. Когда я начал проверять, чтобы убедиться, что ByteBuffer содержал правильные байты, я заметил, что он имеет в основном правильные начальный и конечный байты, за исключением 3-го байта, он имеет -117 вместо того, что, как говорит emacs, должно быть 139 (8b в hexl -Режим). Что дает? Это как-то связано с Big / Little Endian ..?

Для ясности, согласно emacs, первые четыре байта должны быть:

1f: 8b: 08: 00, что равно 31 139 8 0

и ява получает:

31 -117 8 0

Есть идеи?

Answer 1

Java byte подписано, и поэтому его диапазон равен -128..127, а не 0..255. Учитывая это, ваши байты верны. Если значение беззнака байта равно X, то значение со знаком равно (X - 256) - таким образом, для 139 значение со знаком равно 139 - 256 = -117.

Answer 2

Интегральные типы Java (включая byte) подписаны : они варьируются от -128 до 127, а не от 0 до 255, как вы могли ожидать. Любое число с старшим битом 1 (1 ### ####) будет отрицательным.

Множество людей написали об этом.

Answer 3

Это немного касательно, но если вы пытаетесь работать со знаковыми байтами, следующее может оказаться полезным.

Поскольку большинство операций будут продвигать Java byte до int - с сохранением знака и величины & ndash; очень часто маскируют старшие биты, например:

/* Convert two bytes from an array to a 16-bit, unsigned value. */
int val = (b[idx] & 0xFF) << 8 | (b[idx + 1] & 0xFF);

Перед применением оператора & (и большинства других операторов) byte расширяется до int (или даже long, в зависимости от контекста). Таким образом, значение байта со знаком 0xFF преобразуется в целочисленное значение со знаком 0xFFFFFF.

Но обычно при выполнении побитовых операций намерение обрабатывать каждый байт как значение без знака, поэтому byte 0xFF (-1) должно быть просто int 0xFF (255). Маскирование с помощью 0xFF выполняет это.