Re: EBCDIC <-> ASCII translation tables

[Jason Felice <jfelice@xxxxxxxxxxxx>]

Carey Evans wrote:
> 
> Jason Felice <jfelice@cronosys.com> writes:
> 
> > However, my opinion is this: If we're going to change it, let's go
> > to an internal Unicode representation and not just find better ways
> > to implement the current hack.  Correct me if I'm wrong, but from
> > what you have there I think that mapping to the 32-bit Unicode type
> > wouldn't be difficult, and from there mapping to iso-8859-x wouldn't
> > be difficult.
> 
> Not quite, since what I've got at the moment defines the conversion
> straight from EBCDIC to whatever 8-bit character set the file's
> encoded in, so that it doesn't matter what that is.  This makes it
> quite easy to use XEmacs or yudit to check the table against IBM's
> tables at:
> 
>     http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AQ500/F.0
> 
> (And now I see I missed the very useful tables at the top of that
> page.  Oh well.)

Is there a quick-and-dirty way to translate from iso-8859-x to UCS-x? 
Something like twiddling the high eight bits according to the `x' in
iso-8859-`x' and setting the low eight bits to the iso-8859-x character?

(I doubt it, but I need to ask..)

> 
> Wouldn't a 16-bit UCS-2 Unicode representation be enough?  AFAIK, it's
> all that IBM support in OS/400 itself, and all that Python, Windows,
> and some Unixes support.

Hmm, I don't know enough about this, but what about the Kanji?  I don't
beleive most Asian languages are mapped in UCS-2...   If that's not the
case, then UCS-2 is fine by me.  For
the time being 16 bits is fine by me anyway, since if we end up needing
the extra 16 bits,
moving from 16 to 32 bits isn't as big a deal as moving from EBCDIC-8
internal storage to
UTFxx (testing for orders, for example, will have to be changed).

Actually, we might be able to just provide a display buffer function to
retreive a unicode
character from the buffer, and let the function worry about the EBCDIC
code page, DBCS, and
Kanji.  That would be the quickest solution and wouldn't break any of
the existing code.  That would also give me something decent to work
with for Gnome-5250.

> 
> --
>          Carey Evans  http://home.clear.net.nz/pages/c.evans/
> 
>  They have been at a great feast of languages, and stolen the scraps.

-Jay 'Eraserhead' Felice
+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---