Unfortunately Windows doesn't in any sensible way... AFAIK and please correct me if I'm wrong, there is still no strateful/resumable stream oriented win32 charset conversion API.
The Apr ucs2 utf8 logic is used for speed because it happens so often. Slower alternatives always existed in the win32 API. And of course with FnA() it was always fun speculating if that call used OEM CP or locale CP. :) On Dec 24, 2016 02:52, "Branko Čibej" <br...@apache.org> wrote: > On 22.12.2016 18:21, William A Rowe Jr wrote: > > What I'd like us to consider is to rip out all FooFnA() ASCII calls, and > > shift entirely to the Unicode mapping, perhaps with some support of > > alternate operating charsets for the non-httpd consumer. Would like to > hear > > of folks deliberately building the ANSI flavor of APR on modern OS's and > > see if we can address any concerns. > > I have always assumed that APR's "internal" encoding on Windows is > UTF-8, and that on any less than decrepit version of Windows it always > calls the FooFnU() variants directly. I'd hate to see these assumptions > broken, if only because Subversion would fall flat on its face. :) > > In other words, +1 to making APR 2.0 talk to Windows only in UTF-16-LE. > > Apropos, I believe said less than decrepit versions of Windows know how > to convert to and from UTF-8, so we may find that misc/win32/utf8.c is > no longer needed. > > -- Brane > >
