On 3 May 2011 19:13, Paul Gilmartin <paulgboul...@aim.com> wrote: > On Tue, 3 May 2011 17:27:57 -0400, Tony Harminc wrote:
>>Sadly, UTF-EBCDIC, although invented by IBM 10+ years ago, has never >>taken off. And this time one can't even blame the Windows or UNIX >>mainframe-haters. So many z/OS APIs could have been changed one by one >>to support UTF-EBCDIC... Too late. >> > Sigh of relief. > > No. One can blame UTF-EBCDIC. I'd prefer a different parse: "no-one can blame UTF-EBCDIC". > As the OP mused, and a prompt followup expanded, what's desirable is a > prevalent format that > can be served directly by a HTTPD; no filtering or translation. I think I missed both those posts. > That's extremely unlikely ever to happen with UTF-EBCDIC. > (What browsers now support it?) UTF-EBCDIC is no better and no worse than UTF-8 for things like this. Browsers should use UTF-16. Why is legacy ASCII baggage fine, but legacy EBCDIC bad? > If you're willing to change the data stream specification, go with something > now prevalent; > UTF-8 would be my choice. Well since I missed the requirement to do HTML here, I thought we were talking about [TN]3270. One could certainly design a UTF-8 3270 datastream, but then one would lose a lot of app compatibility. SInce it would be a new datastream for the emulators in any case, why not make it a variation on the existing one rather than a brand new one, and leave the apps compatible? Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
