[Java] Incorrect Buffer Output

[Lance]

I have a Java application that connects to a server.
Upon a successful connection, it sends data.

For some reason, values in the character buffer like 0x9c will be turned into 3f (as seen in wireshark) and the result will be a buffer with incorrect data. I am using PrintWriter.write so there is no encoding. Anyone know what's causing this or how to fix this? Thanks.

[Joe]

I'm guessing you're seeing the TCP header. Thats first 0x36 bytes of the packet, IIRC. If you start reading from WireShark at offset 0x37, that might be it.

[Lance]

It's 324 bytes of data, and no, it's not the header :p

[warz]

Anyone know what's causing this or how to fix this? Thanks.

Well, without any example code, I'm going to have to say you're either looking at the tcp header, as joe pointed out, or the obvious - your buffer is messed up. You could also be putting data into the buffer incorrectly. Sounds like you've got a coding error. grats.

[Camel]

You can't use a Writer for binary data. Writers are to Streams as Strings are to byte arrays. You need to use byte arrays for binary data; if you Strings, you can be guaranteed that your code will work inconsistently in different environments.

Even if you use a Stream, Print* is still inappropriate for sockets (but not because it won't work). You should use a packet buffer to construct your packets and convert them to a byte[], and then write() that directly to the socket's OutputStream, thus making the write operation atomic, fault-resistant, and thread-safe.

[Lance]

This is a char[] array

Here it is:

Code: [Select]

char[] data = new char[] { 0x7d, 0x00 };


[Camel]

Fine, don't take my word for it.

Also, a String is just a wrapper for a char[], like a Byte is a wrapper for a byte.

[Lance]

So this is going to be converted from hex to dec then put into a byte array and I'll be using a byte stream instead of Writer.
Sounds pretty easy

Sorry I completely misunderstood your first post

and Thanks

[MyndFyre]

This is a char[] array

Here it is:

Code: [Select]

char[] data = new char[] { 0x7d, 0x00 };


Note that chars in Java are Unicode and always 16-bit values.

[Camel]

Note that chars in Java are Unicode and always 16-bit values.

That's not untrue, but is sort of misleading: Unicode *codepoints* are 32-bits, or ints in Java. This thinking was added to the Unicode standard after Java published String.class, so there are various encodings (almost always UTF-16) that can happen behind the scenes, and the encoding may change based on platform/environment. That's part of the reason for why Writers even exist in the first place; to abstract away the confusing encoding stuff.

In any event, I don't understand why you are using 16-bit values to store 8-bit numbers. Is that intentional? It seems like you should be using a byte[] instead of a char[] for your data.