Re: Unicode problem

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Answering my own question, I guess.

I noticed that the QlgTransformUCSData() API lets you transfer between 
various flavors of Unicode. I could code a routine that translates 
UTF-16LE (with or without BOM) to UTF-16, then use the standard iconv() 
to convert it to UTF-8.

While I'm at it, I could support UTF-32 and UTF-32LE.

Sounds like fun.


Scott Klement wrote:
> Hi Thomas,
> 
>> The first 2 BOM bytes clearly indicate UTF-16 (LE) because they match the
>> UTF-16 (LE) signature given at:
> 
> Yes, I agree.  I wrote a program (long time ago) that detects the 
> encoding of an XML document, and it came to the same conclusion that you 
> did...  UTF-16LE.
> 
> And Expat understood and read/parsed that encoding without any problems 
> on my box.  So I don't know why the OP had problems?
> 
> But for certain, it's not UTF-8, and the OP's assertion that he "fixed" 
> the problem by using CCSID 1208 doesn't make sense.  It's absolutely not 
> UTF-8.
> 
> Do you know if IBM i has a CCSID for UTF-16LE?  Searching around I found 
> a page that says CCSID 1202 is UTF-16le, but that CCSID doesn't appear 
> to be supported on i.   (Fortunately, Expat doesn't use the IBM i text 
> conversion routines, it has it's own.)
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
> 

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------