| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How charset coversion takes place within JMS |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Fri Apr 26, 2013 10:14 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| AmitN wrote: |
HI fjb_saper,
These messages are sent by DB2 Event publisher ,
Message format set to xml.
Message codepage set to 1208
Are these MQMD parameters set by MQ or by application? |
The parameters are set by the application.
By the way XML is a "physical" format. It is not an MQ format.
You need to give us the specific value of the MQMD-FORMAT and MQMD-CCSID fields.
In order to be able to convert the message should have the MQFMT-STRING value ("STRING ") in the MQMD-FORMAT field. The sending party sets this field.
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Sat Apr 27, 2013 4:38 pm Post subject: Re: How charset coversion takes place within JMS |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| AmitN wrote: |
| Do you mean casting to text message does not do the conversion? |
The TextMessage instance is already a TextMessage. Casting the Message reference doesn't change the underlying object.
In this case, "conversion" means to either map bytes to characters, or to map characters to bytes, and requires a ccsid/charset/etc. to describe the physical representation of the bytes in question. For TextMessages, there are no bytes in question, only characters. There's no need to convert characters to characters, because characters are already characters.
Any conversion from bytes to characters would have taken place long before the posted code, when setting the text of the TextMessage object.
| AmitN wrote: |
| These messages are sent by DB2 Event publisher |
DB2 Event Publisher puts messages on a queue, and the user application gets messages off the queue. First make sure that the DB2 Event Publisher is behaving as expected. Stop the user application. Use rfhutil, amqsbcg, or similar browsing utility which can display the message headers and message content as (hex) bytes. Examine the message headers (particularly the Format, CodedCharSetId, and maybe Encoding too), and verify that they correctly describe the message content. If the message is already corrupt at this point, then look more closely at the put application (DB2 Event Publisher) for problems.
| AmitN wrote: |
| Am getting junk character for eg - C5E4F0F340404040 |
Is that the entire character string, or just one of the XML element values in the string? Some database columns can contain non-character data, so is it possible that the DB2 Event Publisher is converting such binary data to a hex-encoded character string before adding it to the XML message?
| AmitN wrote: |
I have tried using this too -
| Code: |
byte[] by = ((TextMessage) message).getText().getBytes("ISO-8859-1");
String sChangeMessage = new String(by,"UTF-8"); |
|
No, that wouldn't work. The getBytes() method converts characters to ISO-8859-1 bytes, and then the String() constructor pretends these ISO-8859-1 bytes are UTF-8 bytes instead, and attempts to convert them to character again. The proper way to convert bytes from one charset to another is bytes->char->bytes, not char->bytes->char. |
|
| Back to top |
|
|
| AmitN |
| Posted: Fri May 03, 2013 6:35 pm Post subject: |
|
|
Novice
Joined: 04 Apr 2013
Posts: 10
|
thanks rekarm01 for clarifying.
I got the below response from amqsbcg -
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 785 CodedCharSetId : 1208
Format : 'MQSTR '
It also showed the whole xml message which has column data like -
</col><col name="INACT_FLG"><bitchar>40</bitchar></col>
I think which still in EBCDIC not converted in ASCII.
The below is the xml header -
<?xml version="1.0" encoding="UTF-8" ?><msg xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="mqcap.xsd" version="1.0.0" dbName="US_DBP2"><trans authID="E311 " correlationID="POOLE3110008" planName="MECICS " isLast="1" segmentNum="1" cmitLSN="0000:cb4d:d62f:506d:0001" cmitTime="2013-05-03T09:37:21.525200"><insertRow subName="RSLR_EU0004" srcOwner="Z4"
But when the actual column data starts all the column values are not in correct format (like the one above I mentioned).
This was checked at Target MQ, we will check at source MQ too which is Mainframe MQ. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun May 05, 2013 5:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| AmitN wrote: |
| But when the actual column data starts all the column values are not in correct format (like the one above I mentioned). |
Do you mean by this the column names (or tag names) are readable and it looks like a normal XML document but the values between the tag names are "junk" or apparently unconverted EBCDIC?
If so, there's a problem at the sending end because the header, document and code page all clearly show UTF-8 (1208). So the structure of the document is in one code page, but the values (if you're right) are in another.
There's no way WMQ will sort that out for you automatically.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun May 05, 2013 11:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| AmitN wrote: |
It also showed the whole xml message which has column data like -
| Code: |
| <col name="INACT_FLG"><bitchar>40</bitchar></col> |
I think which still in EBCDIC not converted in ASCII. |
Not exactly. DB2 Event publisher first converts bitchar to HexBinary, before adding the column to the xml transaction message. The characters in the HexBinary string itself ('0'-'9','A'-'F') are ASCII (or UTF-8), even if the underlying bytes they represent are not.
It may or may not be possible to change the way that DB2 Event Publisher writes the column, but this is probably not the best forum to look for help with that. Regardless, there are Java methods available to convert a HexBinary string to a byte array, such as the J2EE parseHexBinary() method. Assuming that the resulting byte array is EBCDIC, the J2SE String() constructor can then convert it to a character string. |
|
| Back to top |
|
|
| AmitN |
| Posted: Wed May 08, 2013 7:06 pm Post subject: |
|
|
Novice
Joined: 04 Apr 2013
Posts: 10
|
Yes rekarm01, that worked...!!!!
Thank you..huh..!! alas the issue is resolved..
Thanks to everyone here.. Vitor, fjb_saper. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
