On 20/06/13 14:32, Laura Schmidt wrote:
On 06/20/2013 03:09 PM, rossum wrote:
This is a case of RTFM. The Javadocs for BigInteger(byte[]) tell you
that it expects the byte array in two's complement representation, so
a leading 1 bit is interpreted as a negative number. You need a
different constructor:
public BigInteger(int signum, byte[] magnitude)
You are right, sorry.
Now I get a hex string without sign. But now the decode method does not
return the original bytes anymore:
private byte [] hex_decode (String val)
{
BigInteger b = new BigInteger (val,16);
byte [] t = b.toByteArray();
return (t);
}
There is no other constructor for byte arrays.
And I don't really understand why it doesn't return the original byte
array.
I'm not sure what all this twos compliment stuff is about
twos compliment is just a number representation scheme
There should be no need to 'convert' anything
The following program works with the following observation
If the most significant byte is positive e.g >= 1 && <= 127 or 0x7F
the conversion works both ways
If the most significant byte is negative or 0 e.g <= 0 && >= -128 or
0x80 then the conversion works with one proviso
The contract for BigInteger#toByteArray() contains the following text
"The array will contain the minimum number of bytes required to
represent this BigInteger, including at least one sign bit"
so, if the MSB is negative there will be an additional byte in the MSG
position after calling toByteArray set to 0 which indicates that the
following is a positive number, if the MSB is positive there is no need
for an additional byte as the first bit in the MSB is 0 thereby marking
the following number as positive ... interesting, never seen this
before... apart from that it seems to work.