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.
