Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA6096 ; Mon, 04 Jan 93 21:06:43 EST Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!nec-gw!nec-tyo!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Newsgroups: comp.unix.bsd Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST Message-ID: <2629@titccy.cc.titech.ac.jp> Date: 6 Jan 93 19:49:50 GMT References: <2565@titccy.cc.titech.ac.jp> <1992Dec28.064029.24421@fcom.cc.utah.edu> <2616@titccy.cc.titech.ac.jp> <1993Jan5.093059.29631@fcom.cc.utah.edu> Sender: news@titccy.cc.titech.ac.jp Organization: Tokyo Institute of Technology Lines: 28 In article <1993Jan5.093059.29631@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >>BTW, can you explain what XPG4 is? > >The internationalization mechanism following XPG3, the SVR4.2 standard for >internationalization. XPG4 is XPG3 with East Asian language support. Then, XPG4 should be EUC. >>>|> True. But, it should be noted that they don't fit even in 16 bits. >>> >>>Work is already under way to adapt Unicode to 32 bits. I would be interested >>>in any similar work you know of in progress for XPG4/JIS. As a subset of ISO 2022, EUC allows for a 16, 24 or 32 bit character code set. >The primary use for an interntaionalization mechanism will be localization; >anything on top of that (and yes, we can build multilingual applications >on top of that with little effort) is gravy. That is exactly the internationalization model of EUC, whose model is proven to be useless for internationalization. So, you don't have to prove it again with Unicode. Just use EUC. Masataka Ohta