Re: Unicode

I suggested not using (forgetting) 61952 as it is based on Unicode Version
1.0.  Back in the 90s when Unicode Version 1.1 came out there were
incompatible changes made (movement of several thousand Korean characters)
and so CCSID 13488 was introduced to reflect the difference in encoding.
Using 61952 runs the risk of working with Korean data in a way that is not
compatible with other Unicode enabled systems, and so I would not recommend
it in todays environment.

61952 was introduced back in V3R1 and continues to be supported today
(though again I wouldn't recommend using it for any new development).

UTF-16 is a superset of UCS-2 providing an expanded character set (roughly
1,000,000 characters vs 60,000 characters).  Where UCS-2 provides for a
16-bit encoding, UTF-16 allows for a pairing of 16-bit values to represent
a character (in addition to the UCS-2 16-bit representations).  Basically
if the first 16-bit value is between U+D800 and U+DBFF then the next 16-bit
value is a second element further defining the current character.  If
you're interested in the details I would suggest reviewing the Unicode
Standard provided by the Unicode Consortium.

Hope this helps,
Bruce Vining



                                                                           
             "James H H                                                    
             Lampert"                                                      
             <jamesl@xxxxxxxxx                                          To 
             om>                       Midrange Systems Technical          
             Sent by:                  Discussion                          
             midrange-l-bounce         <midrange-l@xxxxxxxxxxxx>           
             s@xxxxxxxxxxxx                                             cc 
                                                                           
                                                                   Subject 
             03/31/2005 03:59          Re: Unicode                         
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             Midrange Systems                                              
                 Technical                                                 
                Discussion                                                 
                                                                           
                                                                           




Bruce Vining <bvining@xxxxxxxxxx> wrote:
> V5R3 supports UTF-16 as CCSID 1200 and UTF-8 as CCSID
> 1208.  These are in addition to the previous UCS-2
> support with 13488 (and let's just forget 61952...).

And why should we "just forget about" 61952? Based on what
I've been reading today, it looks like I may have been
able to use 61952 to run Unicode field tests on our D02,
instead of having to transfer and re-encapsulate a *PGM
that came out of over 23000 lines of MI code for every
bloody damned iteration, (do I sound like I'm sick of
waiting 10 minutes for a RSTOBJ of one object to
complete?) and never knew it. (I'm convinced I must have a
barely-noticable case of dyslexia, as I could have sworn
the notes on CCSID 61952 said it was introduced in V3R1,
not V1R3.)

And what is gained by the addition of CCSID 1200?

And can SOMEBODY explain to me what the difference is
between UCS-2 and UTF-16? They both appear to be different
names for the exact same mapping of 2-byte binary values
into glyphs.

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