File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Converting an decimal int to a hex without using Integer.toHexString Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Converting an decimal int to a hex without using Integer.toHexString" Watch "Converting an decimal int to a hex without using Integer.toHexString" New topic
Author

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

Darrin Smith
Ranch Hand

Joined: Aug 04, 2003
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

Joined: Feb 20, 2009
Posts: 16


Output is 1b .
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18121
    
    8

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

Joined: Jan 03, 2004
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

Joined: Aug 04, 2003
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

Joined: Aug 04, 2003
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

Joined: Mar 17, 2011
Posts: 7032
    
  16

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


Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
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

Joined: Jan 03, 2004
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

Joined: Aug 04, 2003
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

Joined: Aug 04, 2003
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

Joined: Jan 03, 2004
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

Joined: Oct 13, 2005
Posts: 36478
    
  16
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

Joined: Oct 13, 2005
Posts: 36478
    
  16
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

Joined: Jan 03, 2004
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

Joined: Oct 13, 2005
Posts: 36478
    
  16
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

Joined: Jan 03, 2004
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

Joined: Oct 13, 2005
Posts: 36478
    
  16
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

Joined: Mar 17, 2011
Posts: 7032
    
  16

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.

Take off your 'horrible memory' blinkers for a moment, and think about this:
What would the receiver of this data want? Packed decimal, or "Darrin's hex-pack solution 'cause he doesn't like IBM"?

Winston
 
wood burning stoves
 
subject: Converting an decimal int to a hex without using Integer.toHexString
 
Similar Threads
Shift Operator Dought
Binar representation of octal & hexadecimal nos
Mock exam Q
convert image(.jpg) in to binary format using java
Hexadecimal and decimal convert code