Oy!!
These files are coming from a windows system, and they are usually
tagged with CCSID=1252. I hoped that if I specified 1200 as the
FROMCCSID, that the file's CCSID would be ignored.
And these will not have a line with the BOM only, as you described.
CPY actually does handle a UTF-16BE correctly, with or without BOM, and
does not require that the BOM is on its own line.
I'm looking at that API that Bruce V. cited - looks quite promising.
Now I'm looking at how to identify just what encoding the data is in -
interesting challenge, will likely be making a procedure for this here.
Thanks
Vern
On 3/1/2013 1:32 PM, CRPence wrote:
On 27 Feb 2013 17:51, Vernon Hamberg wrote:
My tests show that CPYFRMIMPF doesn't even correctly process UTF-16
BE with/without BOM.
It seems to do a byte-to-byte conversion, not a
character-to-character.
Using the v5r3 code, the CPYFRMIMPF does fine with UTF-16 data when
the STMF is tagged with CCSID=1200. When the STMF is improperly tagged
with CCSID=819 [for example], but the data is actually UTF16, then the
effect is a single-byte conversion. The proper results however did
require that the first line of text be empty, and thus FROMRCD(2) to
skip the empty line; i.e. in order to bypass the FFEF.
