Windows NT shell + extended characters. Bug or what?

[Wolfgang Strobl]

17 Mar 2002 20:46:57 +0100, martin at v.loewis.de (Martin v. Loewis):

>Wolfgang Strobl <ws at mystrobl.de> writes:
>
>> >This is rather unlikely, I doubt the interactive interpreter will ever
>> >be able to properly identify the encoding of the console window. 
>> 
>> What's wrong with GetConsoleOutputCP, besides the restrictions
>> documented in "Q99795 SetConsoleOutputCP Only Effective with Unicode
>> Fonts"? 
>
>There are several problems with that:
>- as you point it, it fails for the raster fonts (for no apparent
>  reason)

Carefull. The problem applies to _SetConsoleOutputCP, the reason being
"SetConsoleOutputCP() is designed to change the mapping of the 256
8-bit character values into the glyph set of a fixed-pitch Unicode
font, rather than loading a separate, non-Unicode font for each call to
SetConsoleOutputCP(). " according to the Knowledge Base entry mentioned
above. 

_Identifying_ the input and output encoding of the console window is no
problem at all.


>- for outputting Unicode, OutputConsoleW is more appropriate, IMO,
>  since it can also output characters not supported in the output
>  code page.

AFAIK there is no function OutputConsoleW.  Do you mean WriteConsoleW?


>- we were talking about input. Admittedly, GetConsoleCP might be of
>  use here

Right.


>- it is tricky to determine reliably that a file descriptor is
>  connected to a terminal.

I wouldn't want the python interpreter become dependent on whether the
stdout file descriptor is connected to a console window  or not.
Either always use the CPs of the console window associated with the
current process, or never.

IMHO, a standard module which allows more control over platform
specific parameters (like the code pages of the console window, if
there is one) would be my prefered solution to this class of problems.

-- 
Wir danken für die Beachtung aller Sicherheitsbestimmungen