开发者

byte[] to String in Java: What does the output mean?

开发者 https://www.devze.com 2023-03-11 05:13 出处:网络
So, I\'m having a little trouble trying to make a card reader work properly on a Multi-functional printer and I\'ve narrowed down my problem to the weird value a string outputs when a byte[] is passed

So, I'm having a little trouble trying to make a card reader work properly on a Multi-functional printer and I've narrowed down my problem to the weird value a string outputs when a byte[] is passed as a constructor argument. I can't really debug the application over the MFP and the logging tool simply doesn't work alongside the card-reading application (that's the embedded programming world for you, folks!), so my work debugging work is pretty much based on printing values on screen that, sometimes, doesn't quite behave as you'd like.

Ok, here we go: when I "swipe" the card on the reader, my Java program receives a byte[]. Now, there are two ways I can display it:

    //Supposing that bytes is the byte[] received
    BigInteger bi = new BigInteger(bytes); bi.toString(16); //I think it works fine
    String str = new String(bytes); //Suggested by the developer; sucks

Ok. The first one outputs "3538353536". Kinda weird for a hex value, but it is actually the right value; since I ran a test:

    byte[]开发者_JS百科 bytes = {0x35, 0x38, 0x35, 0x35, 0x36};
    BigInteger bi = new BigInteger(bytes);
    System.out.println(bi.toString(16));

Considering that it returns the same value (3538353536), I'll take it as the actual byte[] value. Now, when I try the second way:

    new String(bytes);

In this case, my return value is 58556. Even worse, things are not so happy every time, as passing as an argument something like

    {(byte)9F, (byte)0xA8, (byte)0xEE};

will output [tab - really a tab, not write tab] ¨î

I've read in a few places that new String (bytes) was the right way to go, even more so it is the card reader developer's example. But it doesn't work. Before I go about questioning the developer, I'd like to know what this output means compared to bi.toString(16), which seems the right way to go.

Sorry about the rather lenghty post about a question that could be summarized in two lines, but I'd like to make everything crystal clear for a straight, quick answer.

EDIT: Thanks for the input everyone, I got it. Now I'm confused whether I should consider the ASCII value (58556) or the hex ("0x3538353536") - that is, if it is actually supposed to be interpreted as hex - but that's a question I'll take to the developer.


As the javadocs say, String(bytes) "constructs a new String by decoding the specified array of bytes using the platform's default charset".

So what's happening is it's interpreting the data as being characters stored in byte format. If you look up an ASCII chart you'll see that 0x35 = '5', etc.

ToString on the other hand converts the data to a string representation, as you'd expect.


Your original byte array {0x35, 0x38, 0x35, 0x35, 0x36} when converted to decimal number is: {53, 56, 53, 53, 54} which if converted using ASCII values will become {'5', '8', '5', '5', '6'} hence you are getting string 58556 using default charset of your platform.

BigInteger constructor is NOT same as String constructor. As per the Javadoc:

public BigInteger(byte[] val)

Translates a byte array containing the two's-complement binary representation of a BigInteger into a BigInteger. The input array is assumed to be in big-endian byte-order: the most significant byte is in the zeroth element.

0

精彩评论

暂无评论...
验证码 换一张
取 消