Re: XML files in the IFS and incorrect code page.

Booth


There are some assumptions the IBM i makes about CCSIDs. If the file comes from Windows, say, it is often set to 1252. This is true, even if the file contents is UTF-8, because the system sending the file has no clue about CCSIDs.


The people sending these fiels - are they coming from another IBM i? Or from a Windows/DOS/Unix box? Are they all from the US?


There are identifying bytes at the start of several encodings. It's called a BOM - for Byte-order-marking. UTF-8 has one set that is optional, I think. UTF-16 has some, and there is a big-endian and a little-endian version for UTF-16.


You can check for these and take some educated guesses as to the encoding. Several sources on the 'net say that nothing is 100% reliable.


Good luck

Vern


On 5/26/2016 1:15 PM, Booth Martin wrote:

The problem is that one customer out of many is sending files and some, but not all of those files, are not what they say they. WRKLNK suggests that the data is EBCDIC but the properties of the file say it is 0819. btw, it is WRKLNK that suggested the 00500 code page. I had already tried a half dozen other code pages, including 37. When I copy the file specifying an 819 code page the new file appears to be fixed.

Arguing with the customer apparently didn't solve the problem. We have no control over the incoming files; they are what they are.

The immediate problem seems to be to identify a file that is bad before it sneaks into the workflow and gums up the works. So my thought was to run some sort of process that would tell me what WRKLNK thinks the code page is, and compare that to the CCSID attribute. If different, shunt the file to a "problems" folder and then deal with it there.



On 5/26/2016 5:46 AM, Scott Klement wrote:

Booth,

... So why are you attempting to use (and failing)

819?? Or much, much worse, using 500 (a flavor of EBCDIC that is
probably not even correct, since we don't typically use 500 in the USA,
and I assume you are still based in the USA?)

So why are you doing things this way?

...

But if you write EBCDIC data (most likely CCSID 37) but tell the system
it's 819, and then have the system choose to interpret it as 500, you'll
almost certainly have a big mess.

-SK