From: Bob Eaton (pete_dembrowski@hotmail.com)
Date: Fri Oct 28 2005 - 06:53:33 CST
Does anyone know whether (or why not) it is possible to use the ISCII
Devanagari code page (57002) as the default system code page in Windows?
That is, there is no code page support for "Ansi" Devanagari, but with the
ISCII encoding having code page support, why didn't they associate it with
Ansi programs associated with the Hindi locale (c.f. cp. 932 with JIS) ?
The ISCII encoding seemed like a logical choice... but it wasn't used...
Bob
----- Original Message -----
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: "Peter Constable" <petercon@microsoft.com>; "Unicode Discussion List
(E-mail)" <unicode@unicode.org>
Sent: Thursday, October 27, 2005 11:13 PM
Subject: Re: ANSI and Unicode for x00 - xFF
> From: "Peter Constable" <petercon@microsoft.com>
>> One interesting quirk: in Windows, UTF-8 (code page 65001) and UTF-7
>> (code page 65000) can be considered "ANSI" code pages.
>
> Interesting. It's true that UTF-8 and UTF-7 are compatible with the Win32
> A interface, because it can use strings encoded with 8-bit CHAR units.
>
> But is there now a locale supported by Windows in which the "ANSI"
> codepage is 65001 (UTF-8) (though I doubt that there's any that use
> codepage 65000, because it would break the compatibility with lots of
> Win32 API as it cannot be used to pass 7-bit ASCII-encoded strings) ?
>
> Note that the "ANSI" codepage (ACP) cannot be changed in Windows. It is
> fixed for the built localization of the system. But this is not the case
> of the "OEM" codepage (OCP) that can be used in the Windows console and is
> also used in the basic FAT filesystem (also used by the VFAT extension
> found in "FAT32" that adds the support for UTF-16LE, long filenames and
> other extensions for the format and size of the allocation map and of
> clusters), or for the "Boot" OEM codepage which is also be different from
> OCP and cannot be changed as well (the Boot codepage is typically distinct
> from the default OEM codepage on Asian versions of Windows, and is used in
> kernel drivers and for communication with the kernel debug console).
>
> Anyway, I also think that 65001 cannot be used safely as the OEMCP for the
> filesystem (only because the backslash character "\" cannot be correctly
> encoded the way it is recognized by the FAT filesystem); the same would
> apply to the Win32-A registry API that also requires this character
> (unless all these Win32-A APIs are always implemented by an prior string
> conversion from the current OCP to UTF-16 before calling the corresponding
> Win32-U API), although it could be used for display on a console window
> (but the DOS and BIOS emulation layer will not work correctly with this
> codepage, and this would affect severely the input of characters from the
> keyboard, for example in the "EDIT.COM" program).
>
>
>
>
This archive was generated by hypermail 2.1.5 : Fri Oct 28 2005 - 06:54:52 CST