× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: EBCDIC <-> ASCII translation tables
  • From: Jason Felice <jfelice@xxxxxxxxxxxx>
  • Date: Mon, 30 Oct 2000 09:35:34 -0500
  • Organization: Cronosys, LLC

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.