|
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.) 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. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ They have been at a great feast of languages, and stolen the scraps. +--- | 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 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.