This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I'm trying to use - Byte.parseByte(hexString, 16) When using values below 127, I'm ok. If the value goes above that I get a number format exception. I am familiar with java's signed byte value, but I thought I understood this static call to return a signed conversion. I would expect 0xFA for example to be valid. Is there a simple way to get my string converted without having to do a bunch of if checks? As a side note, the big picture is that I have read in a file as a byte array. I have a text box which allows a user to type in a hex string such as - 03 CD 1A FF (etc). The string is split into an array of hex tokens and then converted to a byte array. As noted above, its all fine until I use values outside the signed byte. Regards - Dr. A>
When using values below 127, I'm ok. If the value goes above that I get a number format exception. I am familiar with java's signed byte value, but I thought I understood this static call to return a signed conversion. I would expect 0xFA for example to be valid. When you say "signed conversion", what do you mean exactly? I'm assuming you mean you would essentially expect an input range of 0 to 255 to be shifted by -128 resulting in a number from -128 to 127. But I don't see anything in the Byte class documentation to indicate such a conversion would occur. In fact, I understand the parseByte method documentation to say that it will throw a NumberFormatException if the String argument is not a value of type byte, which would include values greater than Byte.MAX_VALUE, which is 127. Is there a simple way to get my string converted without having to do a bunch of if checks? Unless I misunderstood your earlier meaning of "signed conversion", couldn't you just subtract 128 from each input value, effectively creating the conversion you'd expected? [ October 27, 2003: Message edited by: Dirk Schreckmann ]
You are correct. The problem is I can't subtract 128 from a string which exists as a hex value. For example I have a string of FF, which represents -1 in signed form. Since its a string I can't test it for being greater than 127. If I understand the javadoc, then I could put a -FF as a string, but that of course would be illegal, as it would be interpreted as -255, which is also out range. Regards, Aaron R>
So you're feeding them in as strings? Without doing any testing myself, I would imagine that you could feed it anything from "00" to "FF" and it should handle it, signed or not. Is the parseByte throwing the exception? What value are you passing it when it throws the exception?
Joined: Dec 10, 2001
I still think the simple solution would be to first parse each value into a data type actually big enough to hold the value. Then, apply the desired transition (subtract 128) and cast it to a byte or create Byte objects as wanted. As best as I can tell, that's a very simple beginner's solution to this situation.
Joined: Sep 10, 2002
Here is one way of doing it - tempInt = (byte)Integer.parseInt(hexString, 16); I think its silly to have to use an int value. I think the parseByte and parseInt methods should, by default convert the hex string to its binary pattern and just return the value. IE - 0xFF is 0b11111111, regardless if you consider it signed or unsigned notation. Just for fun here is a quick way of interpretting a signed byte as unsigned.
Regards, Aaron R> [ October 28, 2003: Message edited by: Aaron Roberts ]
Joined: Dec 10, 2001
I think the parseByte and parseInt methods should, by default convert the hex string to its binary pattern and just return the value. IE - 0xFF is 0b11111111, regardless if you consider it signed or unsigned notation. I see, now. You're one of those weird people that like doing bit manipulations. Well, I think the designer(s) of the wrapper classes decided that we programmers wouldn't have to worry about bit patterns and twos complementing this and that when interpreting any number, even if it were in binary. (I would agree that this isn't consistent with those funny Integer.toBinaryString, Integer.toOctalString and Integer.toHexString methods.) So, if we want to specify a negative number, we need just prefix the value with a minus sign - "-". Otherwise, the number is positive. So, you want hex values to be interpreted as bit patterns. Should octal numbers be interpreted as bit patterns, as well? I'd guess you wouldn't think that if the value were specified in decimal as 255, it should be interpreted as the bit pattern 11111111 and actually considered to be -1. Or do you think that? What about radix 3 values? My obvious point is that Strings to be parsed are parsed for integral values, not bit patterns. All of them, no matter the radix. Such consistency seems smart to me. Now, hopefully you won't be too upset when you run accross java.io.ByteArrayInputStream and discover it reads in a byte of data as an int from 0 to 255. :roll: [ October 29, 2003: Message edited by: Dirk Schreckmann ]