On 4/13/2010 5:57 AM, Роман Донченко wrote: > William A. Rowe Jr. <wr...@rowe-clan.net> писал в своём письме Tue, 13 > Apr 2010 15:10:30 +0500: > >> On 4/12/2010 3:48 PM, Роман Донченко wrote: >>> >>> F:\Temp>svn ci testwc -m "В лесу родилась ёлочка." >>> Adding testwc\test.txt >>> Transmitting file data . >>> Committed revision 1. >> >> FWIW, when an app is linked to aprapp.lib, or apr_initialize() is >> invoked, >> env tables and command line args are handled as utf-8 from their Unicode >> sources. This solves most of the problem you just quoted. > > It won't, however, solve the problem if I'm reading the log message from > a file,
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. 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. But in terms of 'local code page', really APR only cares how objects are named, and those objects on Windows are always Unicode, and APR on Windows expresses these as utf-8. There are two charsets translations in windows, one applies to the command line, and yet another to gui/windows applications. And neither is the internal representation of the named win32 objects. Can APR provide more help? Sure, but what are we doing today about help for working out LANG and LC_* data? > or when I'm printing the username that I got from apr_uid_name_get. ... will always be utf-8, back to my point about external representations. Internally, APR always pulls from the Win32 Unicode functions.
