JAVA 和字节数组

Question

I'm trying to use an API where there's a socket is used to communicate. A request is made up of different parts and one of them is the header which is stated as so:

Fixed header: 2 bytes, fixed at 0xffff

Generally I'm not good with bytes and streams, since I've never used it. So how should i create said byte array? I've tried the following

byte[] header = new byte[]{(byte)0xff, (byte)0xff};

But they bytes each become -1, which I believe is because 0xFF translates to 255 which is outside of the signed byte range (-128 to +127), but then how do I create a header like that?

Answer 1

You just did it.

In the end, computers just know about bits. The rest is what the code, and the humans looking at it, make of it. A bit is a 0 or a 1. If you bought a computer with 4GB RAM, then your computer can remember 34359738368 of those.

That's a bit unwieldy, so AMD, or intel, or TSMC, or whomever baked your chip, baked into the chip's design that the chip groups them in sets of 8 (and for certain jobs, in sets of 64 or even higher). But that's where it ends. It's just bits, really. Negative number? What's that? 2? What is this 2 you speak of. I know only 0 and 1.

So that's unwieldy too, so we humans don't wanna say: This byte holds value 00000101. We'll just say 'that holds 5'.

bits     = decimal
00000000 = 0
00000001 = 1
00000010 = 2
00000011 = 3
00000100 = 4
00000101 = 5
... and so on

That's great, but what about -1? We just have 0 and 1 . There's no - so how do we do this?

That's where it gets interesting. It's a convention, not something in the computer. There's this thing called two's complement: We all agree to check the first bit. If it is a 1, then we shall call this -X , where X is found by applying the following algorithm: Flip every bit (all zeroes become one, all ones become zeroes), and add 1 to it.

11111011 = -5.

Why? Well, flip every bit: 00000100
then add 1 to it         : 00000101

which is 5.

But that immediately eats half of what we can represent. After all, the biggest number we can now store in a byte is 127: 01111111 , which is 127. If we add 1 to this number, then we get to 10000000 , but hey that starts with a 1 bit, so assuming we are all in agreement that this means it is negative, that means 1000000 is -128 (bit of an exotic case).

And sometimes that's annoying or not worth it. So sometimes we all agree that the number cannot be negative at all , and 1000000 is just 128. and 11111111 is just 255.

The computer has no idea. 255 is 11111111 and so is -1. So what's 11111111 ? The computer doesn't know. It doesn't even know what 2 is. It just knows zeroes and ones, and as far as the computer is concerned, 11111111 is what it is. (the math works out that + and - 'just work' regardless of whether we decree these numbers are to be seen as two's complement signed or not, cool, huh? Try it! If 11111011 is both -5 as well as 251 depending on the opinion of the one reading off the number, what happens? -5 + 2 is -3. 251 + 2 is 253. -3 and 253 boil down to the same sequence of bits. Just an example. This is, incidentally, why we do the weirdo 'flip all bits and add 1' stuff. So that + and - just work and you don't need to pass along whether you consider the bits 'signed' or 'unsigned'.

In java, all numeric types except char (which is a numeric type. You'd think it represents a character, but it really doesn't) are signed. byte is 'signed 8-bit number' (so, can represent from -128 to +127 , inclusive). char is the only exception, that is an 'unsigned 16-bit number', so can hold from 0 to 65535 , inclusive. It's just if you eg call System.out.println((char) 65); , the println method will interpret that number as: "Look this up in the unicode table and print whatever you find there", so that prints 'A'. That's part of the source code of that particular println method, it's nothing inherent about the char type in java, which is just 'a number between 0 and 65535'.

So, when you print your byte array containing 0xFF, 0xFF in java, because java agreed that we consider it signed, it prints -1, -1. But that's just java-ese for 0xFF, 0xFF. Your byte array contains 0xFF, 0xFF because at the bit level -1 and 255 are the exact same number . For bytes anyway. Not so for all the other ones (char, short, int, long).

To recap:

byte x = (byte) 200;
byte x = (byte) 0xC8;
byte x = -56;

In all these cases, x ends up holding the bits 11001000 . There is no way to tell the difference . You can't ask the system: So, uh, is this x equal to 200, or 0xC8, or -56? What was used to set it? Because the computer does not know - the compiler translates all of the above code to the exact same end result, which is 11001000.

255 is -1.

Answer 2

Well, to start you must know that in Java all integer types are signed. This means that the most significant bit is reserved to represent the sign. That is why in Java the constant Byte.MAX_VALUE says it can go up to 127.

Now, this means you can store 8 bits in a byte, but if you happen to turn on the sign bit, whatever you store would be represented by Java as negative number.

Since 0xff turns on all the byte bits (ie 11111111 ) instead of getting 255 as you were expecting, what you're getting is -1, because that number represents -1 in Java.

Perhaps to understand it I can show you how the bits work in Java. Imagine a type called nimble of only 4 bits, where the most significant bit is reserved for sign.

This is how it would look in Java if it existed:

Imaginary Signed Type: Nimble (4 bits)

Dec. Bin.  Hex.
--------------------
+0   0000  0x0   
+1   0001  0x1
+2   0010  0x2
+3   0011  0x3
+4   0100  0x4
+5   0101  0x5
+6   0110  0x6
+7   0111  0x7
-8   1000  0x8
-7   1001  0x9
-6   1010  0xA
-5   1011  0xB
-4   1100  0xC
-3   1101  0xD
-2   1110  0xE
-1   1111  0xF

Notice how those numbers where the most significant bit is on become negative numbers. If this nimble was a unsigned type, then it wouldn't have negative numbers and it could reach 15.

That's why Java bytes go from -128 to 127, instead of up to 255 as you were expecting.

Now, when it comes to creating byte arrays to send to a stream, perhaps instead of creating the byte array yourself, you could wrap your socket output stream to a type-aware stream like a DataOuputStream , which allows you to send data of specific type.

For example:

try(DataOutputStream out = new DataOutpuStream(socket.getOutputStream())) {
   dOut.writeByte((byte)0xff);
   dOut.writeByte((byte)0xff);
}

That way you may avoid all the difficulties of having to create a header array.

But bottom line, you are array if fine.