On 26.12.2016 19:16, William A Rowe Jr wrote: > 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.
Ah indeed; not that I'm aware of. > The Apr ucs2 utf8 logic is used for speed because it happens so often. > Slower alternatives always existed in the win32 API. Win9x and NT at least up to 4 did not have a UTF-8 "codepage". > 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 >> >>
