On Tue, 5 Sep 2017 02:02:03 +0100, David W Noon wrote: >On Mon, 4 Sep 2017 17:07:08 -0700, Charles Mills (charl...@mcn.org) >wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in ><02b401d325da$f0cb4d30$d261e790$@mcn.org>): > >> COBOL or Java, but what about the OP's PL/I? > >IBM Enterprise PL/I has WIDECHAR(*), which supports UTF-16. It also has >the UTF8(), UTF8TOCHAR() and UTF8TOWCHAR() built-in functions that >translate host code page to UTF-8, UTF-8 to host code page, and UTF-8 to >UTF-16, respectively. These will probably handle UTF-8 translations more >reliably than IND$FILE does. > >The problem is the complexity that was previously hidden is now visibly >the province of the programmer. > Why is there UTF-16?
o It's a variable-length encoding, involving the same complexities as UTF-8. o It lacks the compactness of UTF-8 in the case of Latin text. Is it because it's (sort of) an extension of UCS-2? (What does Java use internally?) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
