Author |
Message
|
RAJESHRAMAKRISHNAN |
Posted: Wed Oct 06, 2004 11:27 pm Post subject: MQSI CCSID Issues |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hi ,
I would like to know whether there are any known issues in MQSI with respect to CCSID convertion.
For example, is there any chance that the MQInput node might fail to convert (Correctly) certain characters in one particular CCSID to the character in CCSID 437?
BTW I am using MQSI 2.1
Thanks very much. |
|
Back to top |
|
 |
Nigelg |
Posted: Thu Oct 07, 2004 12:12 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Conversion is mechanical. Put the original chars in one end, and the converted chars come out the other end.
Do you have any particular examples?
If the data to be converted is described as being in a particular CCSID and contains embedded chars from another CCSID, e.g. a msg in 819 contains embedded Japanese chars in 932, then when the conversion to 437 is done, the Japanese chars will be converted as if they were in 819, and so lose their meaning in Japanese. |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Thu Oct 07, 2004 12:41 am Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Thanks Nigel. I don't have any particular example. But we get messages from a wide range of geography. The message will not be of mixed CCSID in nature. The example that you are sighting will never accur for us. |
|
Back to top |
|
 |
JLRowe |
Posted: Thu Oct 07, 2004 1:56 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
Nigelg,
I thought that conversion errors would occur if you try to convert a character which does not exist on the target codepage? |
|
Back to top |
|
 |
Nigelg |
Posted: Thu Oct 07, 2004 2:19 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
jlrowe
Yes of course a conversion error will occur, but that is not an issue with MQSI or WMQ, it is inherent in the data, The same error would occur,
probably EILSEQ, if the data is converted on the command line using iconv. |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Thu Oct 07, 2004 2:31 am Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hi Nigel.
If there are no embedded chars of some other CCSID, then will MQInput node convert characters from any CCSID to characters of another CCSID without any loss in meaning ?
Thanks |
|
Back to top |
|
 |
Nigelg |
Posted: Thu Oct 07, 2004 3:28 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
No. Conversion is only possible between certain CCSIDs. For example, conversion is not possible between Japanese codepages and English codepages, because the characters have no direct equivalents.
In general, the codepages must represent the same or similar languages, and differe only in the individual machine representation, e.g. 819 (AIX English) -> 437 (Windows English). |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Thu Oct 07, 2004 4:04 am Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hi Nigel,
Thanks you very much. |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Thu Oct 07, 2004 4:07 am Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hi Nigel,
Normally, how conversion between different CCSID's handled(For instance Japanese to English). Can this be never handled? |
|
Back to top |
|
 |
wooda |
Posted: Thu Oct 07, 2004 6:22 am Post subject: |
|
|
 Master
Joined: 21 Nov 2003 Posts: 265 Location: UK
|
As Nigel has said repeatedly you cannot convert from a character in one codepage where there is no equivilent character in the other codepage.
There may well be some characters in a Japanese codepage which will convert to an English codepage. But there will clearly not be many. How can you possibly convert a Japanese kanji to an English character ??
What you are eluding to is at best transliteration or at worst translation and both of these are well beyond the realms of data conversion since you would have to not only understand the format of the data but also it's meaning to do this.
Enough of my ranting.
The short answer is no you can't do this. |
|
Back to top |
|
 |
wooda |
Posted: Thu Oct 07, 2004 6:34 am Post subject: |
|
|
 Master
Joined: 21 Nov 2003 Posts: 265 Location: UK
|
As Nigel has said repeatedly you cannot convert from a character in one codepage where there is no equivilent character in the other codepage.
There may well be some characters in a Japanese codepage which will convert to an English codepage. But there will clearly not be many. How can you possibly convert a Japanese kanji to an English character ??
What you are eluding to is at best transliteration or at worst translation and both of these are well beyond the realms of data conversion since you would have to not only understand the format of the data but also it's meaning to do this.
Enough of my ranting.
The short answer is no you can't do this. |
|
Back to top |
|
 |
Tibor |
Posted: Thu Oct 07, 2004 6:42 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
Quote: |
For example, is there any chance that the MQInput node might fail to convert (Correctly) certain characters in one particular CCSID to the character in CCSID 437? |
Yes, of course but our problem was a slightly different: I tried a setting special CCSID (Latin-2) and the DFE collapsed totally (abend and so on).
Tibor |
|
Back to top |
|
 |
JLRowe |
Posted: Fri Oct 08, 2004 1:38 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
My take on this is to always encode my messages in unicode as CCSID 1208, unicode represents almost everything you'll ever need. |
|
Back to top |
|
 |
Tibor |
Posted: Mon Oct 11, 2004 12:25 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
jlrowe wrote: |
My take on this is to always encode my messages in unicode as CCSID 1208, unicode represents almost everything you'll ever need. |
You I right, UTF-8 is great and this is the 'best practise' in non-ASCII locale environment, IMHO.... but in real life we have a lot of legacy interfaces with other codepages
Tibor |
|
Back to top |
|
 |
|