On Thu, Mar 31, 2005 at 03:18:27PM +1100, Troy Rollo wrote:
That assumes every process is OK working with the same code page. This is not necessarily the case with a server application, which may well be serving clients in multiple regions in a multi-national environment. I know one major
The solution in this case is to use Unicode internally, and then add calls to WideCharToMultibyte() (NOTE: the first parameter "can be given the value of any codepage that is installed or available in the system" (Borland 5.0 helpfile)) or a cross-platform library like iconv(3) to your I/O pipelines. I would say that using the Windows OEM code pages is not suggested for new application development.
It may not even be the case with a client application: you may have a software reseller who supports multiple regions and needs to be able to view data in a program that does not use Unicode when that data has come from a client in a region with a different code page; you may have somebody in a business whose native language is not the same as that of the locality they are in who prefers to use most applications in their native language, but needs to use some with the local code page to get access to business data.
This situation is an even worse case to try hacking the undocumented Windows internationalization APIs. Remember, for instance, that Win95/98/ME *only* supports one OEM code page for the whole system, in the U.S. and Canada, and that for those systems the wide-character APIs are provided by a redistribuable DLL. If you're writing a text-editor or other general-purpose tool, you ought to be building in some character-set detection heuristics, conversion, etc., anyway. If you're developing you're application's data-file formats from scratch, you ought to define a format (probably using some form of Unicode for character data) and stick to it.
Do you think IE or IIS actually uses this particular call?