Author |
Message
|
mitul |
Posted: Sun Dec 12, 2004 8:57 pm Post subject: writeUTF and writeString |
|
|
Apprentice
Joined: 13 Jun 2002 Posts: 33
|
1. Whats the difference between a writeUTF and a writeString?
2. If I am not wrong you can write normal ascii text using a writeUTF same way as you write it in writeString. So why need writeString in first place? Pls clarify.
3. Also is there any way by which a listener program at the receiving end can find out whether the message put on the Q is put using writeUTF or writeString? I mean, we have 1 Q on which client dump's messages using writeUTF and writeString format. But our receiving program should know in advance about the format in which to read the message.
I think we need to browse the msg first and read some fields and do a get accordingly. Pls clarify which fields and accordingly which method to invoke. Also clarify if any other approach is possible. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Dec 13, 2004 5:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
WriteUTF writes double byte characters.
WriteString writes single byte characters. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
slaupster |
Posted: Mon Dec 13, 2004 5:40 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004 Posts: 41
|
the difference is mainly in the codepage but also in the structure of the bytes put to the wire.
writeString will convert the string to the char set of the MQMessage in unstructured bytes and append these bytes to the message buffer. because the bytes have no structure, then the receiving application needs to know the length of the string and also both ends need to take into account the codepage.
writeUTF uses the first 2 bytes to specify the length of the string, and the rest is Java Unicode string bytes. the receiving application does not need to know the length of the String, and also, because we are using the java.ioDataInput/DataOuput interfaces (thats what the idea is, see java.io API doc), we don't need to worry about codepage because its Java and using these interface methods, we know its Unicode, not that we care.
So, use read/writeUTF if the other end is Java, and or if you don't have a specific structure to your message, that includes the sizes of each message field.
Otherwise, use read/writeString and make sure you set the encoding field appropriately. You would usually use this when sending messages to non-Java apps and you have a pre-defined structure to your message.
If you use writeUTF, then readString, the first 2 chars will be random, if you use writeString and readUTF then you may get random Strings or exceptions depending on the String.
I not aware of a way to determine what the sender used, but I doubt there is a way. The only way I can think of to achive this is add some structure to the String if its written using writeString. This way the receiving app, when it gets to the String part, can record the current data offset, read n chars of String using readString. If the structure of the String is like that of what was used to write the String, then parse out what you want, otherwise, reset the offset and readUTF. But this is really messy and unsafe. I reckon you should just choose one and stick with it.
Last edited by slaupster on Thu Dec 16, 2004 7:19 am; edited 1 time in total |
|
Back to top |
|
 |
mitul |
Posted: Mon Dec 13, 2004 8:38 pm Post subject: |
|
|
Apprentice
Joined: 13 Jun 2002 Posts: 33
|
Thanks for clearing the concept.
The client is sending messages on our Q remotely. They use C application to do this. So no Java at the sending side.
We at our end are retrieving the messages from the same Q using a Java application.
I have no idea abt MQ using C. But is there a way by which they can put the message in UTF rather than String? Does C also have something like write/readUTF ..??
Also throw some light on when to set the encoding field and also what value to set in which scenario. |
|
Back to top |
|
 |
slaupster |
Posted: Wed Dec 15, 2004 2:29 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004 Posts: 41
|
The putting C application can fake the Java UTF format by adhering to the rules of generating the bytes in the first place. For this you will need to read the Javadoc API for java.io.DataInput and java.io.DataOutput. These will tell you how to construct the bytes from a String that are what they call modified UTF representation. For most chars (ASCII), using the ASCII encoding will work fine, but its is probably safer to use UTF8 for the C app. The C developer should be able to cope with that.
Sorry - I used the word encoding very badly - usually it refers to byte order, ie big/ltittle endian. I meant character set, although encoding is also important for you depending on the sending application hardware. Any char data not accessed via readUTF is affected by the characterSet of the MQMessage, i.e. readString, readLine and writeString. The 2 ends of the application must agree on a characterSet to use. But obviously this is unnecessary if all char cata is sent in modified UTF and accessed with readUTF.
The encoding of numeric values could be different on the sending machine, meaning that the bytes serialised into the message to represent an int may not be big endian, which is what Java uses. Again this is dependent on the sending application hardware, if it is a PC, it will be little endian, so you will need to set the encoding appropriately. Again, C developers are more familiar with this than Java developers so your partner should be able to help with this.
You need to read over the MQMessage section of Chapter 9 in Using Java for encoding and character set information, as well as the Javadoc API for the interfaces I mentioned earlier - MQMessage implements these interfaces.
hope this helps
Last edited by slaupster on Thu Dec 16, 2004 7:19 am; edited 1 time in total |
|
Back to top |
|
 |
mitul |
Posted: Wed Dec 15, 2004 5:12 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2002 Posts: 33
|
Thanks.
I will read the specified docs and get back to you incase further help is required. |
|
Back to top |
|
 |
mitul |
Posted: Wed Dec 22, 2004 2:18 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2002 Posts: 33
|
Is this a valid one..
client writing the data in writeString()
and at the server side we trying to read it using a readUTF()
I think this is not allowed. It will throw an exception. But just wanna clarify. Incase if possible what will be impact?
The thing is I wanna make my code generic so as to readString as well as readUTF from the same Q in the same code. Is there any way to do so? |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 22, 2004 8:21 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Yes you can try readUTF and if this throws an exception try readString.
Enjoy  |
|
Back to top |
|
 |
tapak |
Posted: Wed Aug 16, 2006 7:13 am Post subject: |
|
|
 Centurion
Joined: 26 Oct 2005 Posts: 149 Location: Hartford,CT
|
Hi fjb_saper ,
Is it better to catch any exception or java.io.EOFException to decide on using readString
Thanks |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Aug 16, 2006 7:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It's better to use readString and interrogate the first few characters to determine if it's UTF.
Or just not even bother reading or writing UTF, since it's a very limited format.
Hint! Unicode!=UTF! _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
tapak |
Posted: Wed Aug 16, 2006 10:12 am Post subject: |
|
|
 Centurion
Joined: 26 Oct 2005 Posts: 149 Location: Hartford,CT
|
|
Back to top |
|
 |
|