On 6/9/06, D.J. Heap <djheap@gmail.com> wrote:
> On 6/9/06, Branko Èibej <brane@xbc.nu> wrote:
> > D.J. Heap wrote:
> > > On 6/9/06, Branko Èibej <brane@xbc.nu> wrote:
> > > [snip]
> > >> > Actually, that was just the first problem. I do see the UTF-8 to
> > >> > CP437 xlate take place successfully and then fputs is called and dumps
> > >> > out ? instead of the special characters. I'll keep looking later, but
> > >> > I'm not really sure what to look for. Is CP437 the wrong code page?
> > >> CP437 is, for all intents and purposes, plain ASCII, which obviously
> > >> doesn't support any interesting characters. It this is a strict
> > >> (non-fuzzy) translation, then something is seriously wrong with
> > >> apr-iconv. If it's a fuzzy translation, then it's expected; IIRC that's
> > >> exactly what we do with untranslatable characters.
> > >>
> > >
> > >
> > > It's a strict translation, I think. After the xlate call
> > > (svn_cmdline_cstring_from_utf8 succeeds and so the fuzzy version isn't
> > > called) I see it as a 0x81, but it comes out as a ? on the console.
> > > The CP437 came from GetConsoleCP and GetConsoleOutputCP in
> > > svn_cmdline_init. And those are Win32 API's, so I'm not setting the
> > > language options correctly or something for Console apps?
> > You seem to have a very US-centric Windows installation without any
> > multilanguage support installed... 0x81 isn't a valid character in
> > CP437, IIRC, I wonder if apr_iconv thinks it's converting to CP850
> > (which is the "international ASCII", poor-man's DOS latin-1, sort of).
> > In that case, that's certainly a bug in apr-iconv.
> >
> > -- Brane
>
> Yes, I do have a US Windows XP, but your binaries for 1.3.2 seem to
> work fine (I see the umlaut or whatever it is) and if I force the
> output encoding to CP1252 while debugging then it works also. Very
> strange...for some reason I'm getting CP437 from VC2005 binaries but I
> don't understand how that could be since GetConsoleCP is a Win32 API
> (not a C runtime API). I wonder if there is some preprocessor version
> definition or something in VC2005 that changed and is affecting it?
>
Hmm, Python 2.4 with the Win32 extensions also returns CP437:
C:\Projects>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32console
>>> win32console.GetConsoleOutputCP()
437L
>>>
So why do your binaries work?
DJ
Received on Sat Jun 10 01:54:53 2006