🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.unix.programmer
Article #3883

Re: EUC<->Unicode (Curses woes on Solaris)

#3883
From: Paul Gorodyansky
Date: Thu, 20 Dec 2001 18:46
59 lines
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-mail
References: <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