apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Роман Донченко <DXDra...@yandex.ru>
Subject Re: Misbehaviour of apr_os_locale_encoding on Windows
Date Tue, 13 Apr 2010 16:27:25 GMT
Branko Čibej <brane@xbc.nu> писал(а) в своём письме Tue, 13 Apr 2010
 
22:00:09 +0500:

> 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.

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.

> 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.

Roman.


Mime
View raw message