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

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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