apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@xbc.nu>
Subject Re: Misbehaviour of apr_os_locale_encoding on Windows
Date Tue, 13 Apr 2010 17:00:09 GMT
On 13.04.2010 16:29, Роман Донченко wrote:
> William A. Rowe Jr. <wrowe@rowe-clan.net> писал в своём письме
Tue, 13
> Apr 2010 19:18:57 +0500:
>> And what is the encoding of that file?  Certainly no assurance that data
>> is unicode, or one of the local code pages.  APR can't and doesn't
>> try to
>> deal with the representation of data passed around using APR.  In
>> general
>> windows environment is very good about handling utf-8 data, although
>> it's
>> irritating in the insistence on polluting streams with BOM's.
> I agree that you can't reliably predict what encoding a file is in,
> but I assert the system ANSI code page (which apr_os_locale_encoding
> should IMO return) is a reasonable default. It's certainly not the
> user locale's code page (which it currently returns) — because nothing
> uses that. 8=]
>> Something APR should address, is that -printing- that to a console
>> stream,
>> a utf-8 stream can easily be handled with unicode.  That's a problem apr
>> could reasonably solve for command line apps.
> Perhaps, but printing to the console is not what's broken here.

Well no, but ... as a matter of fact, most of the locale stuff in
Subversion on Windows, starting with command-line parsing (we don't use
apr_app_initialize) all the way to printing to the console (we don't use
the wide-character printf variants) is subtly wrong. And on my head be
it because I implemented all those bits and know about the deficiencies
and haven't fixed it.

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.

-- Brane

View raw message