Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!

# Converting an decimal int to a hex without using Integer.toHexString

Darrin Smith
Ranch Hand
Posts: 276
I need to convert a decimal number to a hex number but using the Integer.toHexString() does not work.

The reason is that I need to store the number into two consecutive bytes in a stream.

For example, if you start with the number 27 and use Integer.toHexString(27) it will yield 31 62 not 1B as I want. The reason is that 31 hex is the letter 1 and 62 is the letter b each in their own character. Well, I need the actual number in hex, not the character representation of it as two chars.

So, how can I convert up to 255 into two consecutive bytes so I can store it into a byte array?

THANKS!

Vivekkk Singh
Greenhorn
Posts: 16

Output is 1b .

Paul Clapham
Sheriff
Posts: 21107
32
Darrin Smith wrote:Well, I need the actual number in hex, not the character representation of it!

Sorry, but you have fundamentally misunderstood how numbers are stored in computers. You can have a byte which contains the decimal value 27. This byte also contains the hexadecimal value 1B and it also contains the octal value 33, because those three things are the same thing. But it doesn't contain any representation of the number. The number is therefore just an abstraction, which you can choose to represent in many ways as a string.

So what was your original requirement which made you think that you needed "a number in hex" as opposed to the character representation in hex?

Jeff Verdegan
Bartender
Posts: 6109
6
Vivekk, please do not do the OP's work for him. This site is NotACodeMill(⇐click), and, as it says clearly at the top of the topics page: We're all here to learn, so when responding to others, please focus on helping them discover their own solutions, instead of simply providing answers.

Darrin Smith
Ranch Hand
Posts: 276
I didn't spell it out well. After 20+ years of it, starting out with a Tandy Model III and working on VAX, DEC, IBM 360 and everything since, I assure you I understand how things are stored internally.

I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

Thanks.

Paul Clapham wrote:
Darrin Smith wrote:Well, I need the actual number in hex, not the character representation of it!

Sorry, but you have fundamentally misunderstood how numbers are stored in computers. You can have a byte which contains the decimal value 27. This byte also contains the hexadecimal value 1B and it also contains the octal value 33, because those three things are the same thing. But it doesn't contain any representation of the number. The number is therefore just an abstraction, which you can choose to represent in many ways as a string.

So what was your original requirement which made you think that you needed "a number in hex" as opposed to the character representation in hex?

Darrin Smith
Ranch Hand
Posts: 276
Actually he didn't. He just did exactly what I said I already tried. Using Integer.toHexString().

Jeff Verdegan wrote:Vivekk, please do not do the OP's work for him. This site is NotACodeMill(⇐click), and, as it says clearly at the top of the topics page: We're all here to learn, so when responding to others, please focus on helping them discover their own solutions, instead of simply providing answers.

Winston Gutkowski
Bartender
Posts: 10417
63
Darrin Smith wrote:I didn't spell it out well. After 20+ years of it, starting out with a Tandy Model III and working on VAX, DEC, IBM 360 and everything since, I assure you I understand how things are stored internally.

I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

Are you sure you're not thinking of packed decimal? It's more than a decade since I've seen it, but it's the only standardized "hexadecimal" format I can think of. In the above case it would be stored as 0x255C (or 255F for unsigned), which does fit into 2 bytes.

Winston

Jeff Verdegan
Bartender
Posts: 6109
6
Darrin Smith wrote:
I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

So..

0x0000 = 0
0x0001 = 1
...
0x00FE = 254
0x00FF = 255

Yes?

You can use a short for that.

On the other hand if you don't care about your Java process interpreting the bytes as the int value 255, and you just care about the bit pattern 0xFF, then simply (byte)0xFF or (byte)255 will do. Your goal still isn't clear though, so it's hard to give concrete advice.

Jeff Verdegan
Bartender
Posts: 6109
6
Darrin Smith wrote:Actually he didn't. He just did exactly what I said I already tried. Using Integer.toHexString().

Jeff Verdegan wrote:Vivekk, please do not do the OP's work for him. This site is NotACodeMill(⇐click), and, as it says clearly at the top of the topics page: We're all here to learn, so when responding to others, please focus on helping them discover their own solutions, instead of simply providing answers.

I'm pretty sure he *thought* he was helping by providing you a canned solution to your problem. I'm also pretty sure he didn't read your post closely enough to realize what you were really asking.

Darrin Smith
Ranch Hand
Posts: 276
Here is the simple solution to my problem...and thank you for helping!

So in short (no pun intended) I just stuff the size into a char and append the char to a StringBuffer at the proper position.

char cLength = (char)size;
buff.append(cLength);

Jeff Verdegan wrote:
Darrin Smith wrote:
I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

So..

0x0000 = 0
0x0001 = 1
...
0x00FE = 254
0x00FF = 255

Yes?

You can use a short for that.

On the other hand if you don't care about your Java process interpreting the bytes as the int value 255, and you just care about the bit pattern 0xFF, then simply (byte)0xFF or (byte)255 will do. Your goal still isn't clear though, so it's hard to give concrete advice.

Darrin Smith
Ranch Hand
Posts: 276
Yes Winston, but now I have horrible memories from IBM Assembler class back in 1985 to deal with. Thanks! LOL

Winston Gutkowski wrote:
Darrin Smith wrote:I didn't spell it out well. After 20+ years of it, starting out with a Tandy Model III and working on VAX, DEC, IBM 360 and everything since, I assure you I understand how things are stored internally.

I was just looking for a way to stuff a number up to 255 into two consecutive bytes in a stream. I'll just write a little routine for this.

Are you sure you're not thinking of packed decimal? It's more than a decade since I've seen it, but it's the only standardized "hexadecimal" format I can think of. In the above case it would be stored as 0x255C (or 255F for unsigned), which does fit into 2 bytes.

Winston

Jeff Verdegan
Bartender
Posts: 6109
6
Darrin Smith wrote:
So in short (no pun intended) I just stuff the size into a char and append the char to a StringBuffer at the proper position.

This is a brittle solution, and, more to the point, using a StringBuffer for what appear to be bytes is a bad idea. Not every byte or combination of bytes is a valid char. If you have bytes rather than actual characters, don't use Stings or StringBuffers or StringBuilders at all. And if you want 2 bytes, use a short, not a char.

Campbell Ritchie
Sheriff
Posts: 48968
60
Jeff Verdegan wrote:Vivekk, please do not do the OP's work for him. . . .
Agree. In this case I shall let it stand unchanged because he was using toHexString and the thread title says without toHexString.

Campbell Ritchie
Sheriff
Posts: 48968
60
I thought at first you would use the % and / operators, though & and >> would work too, and might be more appropriate to the present situation. But it is obvious you want something more complicated, so I shall move this discussion.

But surely you can fit up to 255 into a single byte. All right, bytes work in two’s complement, but you can use an integer literal. Remember integer literals are implicitly unsigned, but you must cast 255 to a byte, and it can be displayed as -1.You doubtless already know about right-shift by 8 places, bitwise “and” with 0xff and a cast to byte already.

Jeff Verdegan
Bartender
Posts: 6109
6
Campbell Ritchie wrote:
But surely you can fit up to 255 into a single byte.
All right, bytes work in two’s complement, but you can use an integer literal.

No, we can't store 255 in a byte. If we want to interpret it as 255, we have to do some work, just as if we wanted a byte's 256 possible values to represent 1001-1256.

We can, of course, store the bit pattern 0xFF in a byte (which byte has a value of -1 in Java).

Remember integer literals are implicitly unsigned

Eh?

, but you must cast 255 to a byte, and it can be displayed as -1.You doubtless already know about right-shift by 8 places, bitwise “and” with 0xff and a cast to byte already.

Note that in 2rd and 3rd cases, we are printing ints. It's only in the first case that we're printing a byte.

Campbell Ritchie
Sheriff
Posts: 48968
60
Java™ does not recognise negative integer literals. If you find the JLS, you find it can be 0 or start with NonZeroDigits. It cannot start with a -. If you write “-123”, that parses as two tokens, the integer literal 123 and the sign-change operator (uminus) -. You are allowed 0 to 2147483648 inclusive for decimal numbers and 0x0 to 0xffffffff in hex (for an int). So you can represent a negative number by its hex representation, eg 0x87654321I presume you can print a byte in unsigned 0xf0 notation similarly, but haven’t tried.
Unfortunately my excursion into hex arithmetic has probably done little to help and has simply confused things in this thread.

Sorry.>

Jeff Verdegan
Bartender
Posts: 6109
6
Campbell Ritchie wrote:Java™ does not recognise negative integer literals. If you find the JLS, you find it can be 0 or start with NonZeroDigits. It cannot start with a -. If you write “-123”, that parses as two tokens, the integer literal 123 and the sign-change operator (uminus) -.

How about that. I never noticed that before.

You are allowed 0 to 2147483648 inclusive for decimal numbers

For decimal ints, you mean, right? And in that case, the decimal int literal 2147483648 is only valid if preceded by the uminus.

Campbell Ritchie
Sheriff
Posts: 48968
60
I first found out about that from a book, I think Java™ Puzzlers by Bloch and Gafter. As you say, 2147483648 must be preceded immediately by uminus. It’s in the same JLS section if you scroll down a page or two. I hadn’t noticed (or had forgotten) that the %x tag prints out the number unsigned, but it says unsigned in the Formatter documentation, if you scroll down far enough. So you can probably get a positive output from
System.out.printf("0x%08x%n", 2_000_000_000 + 1_000_000_000);
The underscores are only permitted in Java7

Winston Gutkowski
Bartender
Posts: 10417
63
Darrin Smith wrote:Yes Winston, but now I have horrible memories from IBM Assembler class back in 1985 to deal with...

That has nothing to do with it. I've given you a solution; and furthermore its internationally recognized, standardized, and accredited.