apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Misbehaviour of apr_os_locale_encoding on Windows
Date Tue, 13 Apr 2010 17:43:19 GMT
On 4/13/2010 11:27 AM, Роман Донченко wrote:
> Frustratingly, even wprintf will not output Unicode characters to a
> console, it will transform them into chars according to the current C
> locale (there are so many current locales, it's nauseating). To *really*
> print wide characters to the console, one needs to use WriteConsoleW -
> which of course doesn't work on ordinary files.

It is nauseating, considering that a single process is possibly using three
different code pages of the same language at the same time.  And yes, that
implementation would require WriteConsoleW, in my experience you can't set
an actual utf-8 code page on Windows.

>> That's not directly related to what apr_os_locale_encoding does, of
>> course. I'm a bit surprised by WinAPI's behaviour there, though; it
>> doesn't look like this is a problem that can be fixed just by changing
>> how APR behaves, since APR doesn't know anything about how the
>> application behaves.
> Well, if Subversion on Windows actually used apr_xlate_* instead of its
> own substitute, it would be fixed by changing APR. 8=] But since it
> doesn't, I intend to propose an equivalent fix to Subversion once I
> (hopefully) persuade the APR team.

Just an FYI - apr_iconv is likely to be dumped, since it enjoys little to
no necessary maintenance.  Reimplementing in terms of ICU would be ideal,
license-wise, sadly it's buffer oriented with a trip through unicode in
all cases.

But apr_xlate_ itself doesn't help your problem at all with respect to the
selection and acknowledgment of the user's preferences, it just does the
conversions that it's told to do.

View raw message