Article View: comp.unix.programmer
Article #3883Re: EUC<->Unicode (Curses woes on Solaris)
From: Paul Gorodyansky
Date: Thu, 20 Dec 2001 18:46
Date: Thu, 20 Dec 2001 18:46
59 lines
3870 bytes
3870 bytes
Stephen Baynes wrote: > > Paul Gorodyansky wrote: > > > > Paul Gorodyansky wrote: > > >... > > > on a Web page (cannot find URL now) of Sun documentation where they said > > > that their C run-time library's > > > wchar > > > is NOT Unicode, it's Sun's proprietary implementation. > > > > By the way, can anybody answer how people write Unicode-enabled > > programs in C/C++ under Solaris if wchar there is not Unicode? > > > > Solaris 8 claims to fully support Unicode, I can even choose UTF-8 > > as a locale but what does it really means if C/C++ do NOT support > > Unicode there??? > > I don't know - but I guess that if you set UTF-8 as your locales > character set - then it will correctly convert to / from UTF-8 as > a multi byte character set to Sun's (not unicode) wchar encoding. Thanks! It makes sense. That is, it means that now we have UTF-8 _code page_. It's like MultiByteToWideChar() under Windows that converts non-Unicode to wchar_t - the code page must exist on the computer for this function to work. For example, U.S. NT 4.0 that does not have Japanese code page - that function can not be used there to convert Japanese text to wchar. > > Note also that the C standard allows the encoding of wide characters > to be locale specific. So in a UTF-8 locale it could be UNICODE and > in a Japanise locale it could be something completely different. No, here I can not agree. wchar can NOT be locale-specific, otherwise none of our programs would work :) C standard may allow wchar to be _platform_ specific (i.e. Windows has it as UCS-2 while Sun - as their own implementation), but not Locale-specific, wchar has nothing to do with Locales: for example, we have I18n-enabled C/C++ code - as it should be - single executable for all languages, wchar is always "_platform-specific_ wchar" despite the locale being it UTF-8 or French or Japanese - locale serves absolutely different purpose - decimal separators, sorting, etc. - it has nothing to do with character representation. So, in our current code - despite the locale - wchar under Sun is always the same Sun's own form and under Windows it's UCS-2 - it does not matter where our Sun or Windows NT computer is a Japanese or a French one. -- Regards, Paul Gorodyansky "Cyrillic (Russian): instructions for Windows and Internet": http://ourworld.compuserve.com/homepages/PaulGor/
Technical Details
Message-ID:
<3C22320B.E5838283@compuserve.com>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!65.209.212.250!not-for-mailReferences:
<59bfe011.0112181155.77a73800@posting.google.com> <3C213653.A869531E@compuserve.com> <3C213828.435D6692@compuserve.com> <3C21E1EF.EFDADFF0@soton.sc.philips.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f8c9b,4ecdeed075c19330 X-Google-Attributes: gidf8c9b,public X-Google-Thread: fc89c,4ecdeed075c19330 X-Google-Attributes: gidfc89c,public X-Google-Thread: f6653,4ecdeed075c19330 X-Google-Attributes: gidf6653,public X-Google-Thread: 10204d,4ecdeed075c19330 X-Google-Attributes: gid10204d,public X-Google-Thread: fb9a0,4ecdeed075c19330 X-Google-Attributes: gidfb9a0,public X-Google-ArrivalTime: 2001-12-20 10:44:49 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!65.209.212.250!not-for-mail From: Paul Gorodyansky <paulgor@compuserve.com> Newsgroups: comp.unix.programmer,comp.sys.sun.misc,comp.unix.questions,japan.comp.sun,comp.software.international Subject: Re: EUC<->Unicode (Curses woes on Solaris) Date: Thu, 20 Dec 2001 10:46:35 -0800 Organization: Private person Lines: 59 Message-ID: <3C22320B.E5838283@compuserve.com> References: <59bfe011.0112181155.77a73800@posting.google.com> <3C213653.A869531E@compuserve.com> <3C213828.435D6692@compuserve.com> <3C21E1EF.EFDADFF0@soton.sc.philips.com> NNTP-Posting-Host: 65.209.212.250 Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1008873888 18598286 65.209.212.250 (16 [25072]) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru