by Michael S. Kaplan, published on 2008/10/07 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/10/07/8981958.aspx
This blog dedicated to six weeks I almost got to spend in Australia nearly 15 years ago, and a Kinks song named Long Distance that still reminds of me of the late night phone conversations I had with the girl who was able to make the trip...
In response to chcp can't do everything, rbouman commented:
interesting reading here, thank you.
I've had an occurrance of the path variable on xp pro being displayed correctly once only as human readable then as ascii chars only.
turned out the codepage for this machine was set to 850, if I then manually set the codepage to 437, the path variable remains human readable [that is; from a command prompt screen output].
the mystery is ; the machine is set to australian english in regional settings; there's no multi linguallity [is that a word?] other than that.
what else could possibly cause the path variable [and it's the only environment variable to be affected] to display ascii chars?
I'm also making the assumption that the ascii chars may cause some apps. to not read the path var. properly, right?
Of course the value that chcp returns when you run just it from the command line with no parameters (assuming you haven't modified it) is the default OEM code page, aka the OEMCP, aka the LOCALE_IDEFAULTCODEPAGE of the default system locale.
Which kind of indirectly explains why rbouman is seeing code page 850 -- because the OEMCP for 0x0c09 is indeed 850.
Incidentally, the default EBCDIC code page for 0x0c09 is 500 rather than 037 like it is for US English. I have no idea why this is the case.
If one wants to change it on a total machine wide basis, one can just change the default system locale and reboot.
Unfortunately, even on Vista the reboot would be required since the OEMCP would be changing. So you don't get any of those Ready... set... Don't Reboot! benefits...
For the rest of rbouman's question related to what the path might look like in the console, although I don't know for sure what we're talking about, there are no worries about the path variable changing here based on the codepage -- this is just an illusion of the display, one that does not really change just because the code page does.
Though one should be careful copying it out of the console, like into Notepad or other Windows applications that either use Unicode or use the ACP (which even down under is still 1252).
Code page 850, aka Multilingual Latin 1, is very popular for a lot of Western Europe, and also apparently Australia. Perhaps they will be joining the EU sometime soon? :-)
This blog brought to you by ╚ (U+255a, aka BOX DRAWINGS DOUBLE UP AND RIGHT, which is inexplicably part of both code pages -- 850 and 037)
jmdesp on 7 Oct 2008 6:30 AM:
I just saw the other comment about "chcp 65001", I'd never have thought chcp can do that, it's already a *lot* for me. I don't care so much that it kills batch files, it will be useful some day.
Yuhong Bao on 23 Jul 2011 1:33 PM:
On the other hand, locales like English (India) uses codepage 437 as the OEMCP. I wonder how this was determined.
Michael S. Kaplan on 25 Jul 2011 12:29 PM:
en-IN was based on en-US, unfortunately (that's what most people were using on machines). So it got many en-US traits -- like this one.
Yuhong Bao on 25 Jul 2011 2:51 PM:
I was wondering how the OEMCP of each English locale was picked in general.
Michael S. Kaplan on 25 Jul 2011 3:00 PM:
Arbitrarily, without much thought. Period.