On 13.04.2010 16:29, Роман Донченко wrote: > William A. Rowe Jr. <wr...@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
