Re: unexpected BOM in XML file

Hiya Charles,

I had a couple of comments.

1) A BOM is a unicode thing. CCSID 819 isn't Unicode, and that's why it
causes problems to have a BOM there.

2) No, you cannot expect Java or PASE to automatically set the CCSID to
1208 for you. Remember, Java is a cross-platform language, and CCSIDs
are pretty much IBM-specific, I've never seen them anywhere else.
(They're a great feature, though -- I wish all platforms had them... but
they don't.) Probably Java doesn't do anything with the CCSID at all,
and PASE sets it to whatever PASE uses for a default, which is 819 in
the US and most western counties. It has no idea what the CCSID is
supposed to be, its just a default.

3) The results you're seeing don't seem weird to me. With CCSID 1208
(UTF-8) the system expects the BOM and ignores it -- it's still there,
of course, so you see it in the hex dump -- but it realizes its not part
of the data, so won't try to display it to the user or parse it in the
XML document. This seems normal. Since BOMs don't exist in CCSID 819
(iso-8859-1) it thinks they are special characters or control characters
or something like that, and since that type of character isn't valid in
that spot of an XML document you get the error. Seems like
correct/normal behavior to me.

-SK

On 3/20/2020 4:24 PM, Charles Wilt wrote:

Ok this is getting weirder...

I've got two files...both have the BOM, when view via WRKLNK 5=Display
(F10-Hex)

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com