This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The C locale

Corinna Vinschen wrote:
On Sep 29 01:03, IWAMURO Motonori wrote:
2009/9/27 IWAMURO Motonori <>:
LANG="ja" -> EUCJP
Hmmm, It is a difficult problem.

I think selecting UTF-8 is good because eucJP is legacy.

But, for interoperability with other UNIX-like system(*), I don't
think selecting UTF-8 is good.

* Solaris: ja, ja_JP -> eucJP
* Linux (Debian): ja -> Unknown, ja_JP -> eucJP

I need to think more...
My conclusion is as follows as a result of hearing other Japanese
people's opinion:

LANG=ja -> UTF-8
LANG=ja_JP -> UTF-8

Because, we specify "eucJP" explicitly when we need it.


That's an interesting point.

In theory this sounds like a good idea to be used for all locales which
don't specify the charset explicitely, because that results in using the
same charset, "UTF-8", for all such locales. "C", "ja" or "en_US"
would all default to UTF-8.
The keyword here again should be compatibility. That means, unfortunately, that I do not think this is a good idea.
A number of locales have been established on common systems that do not specify their encoding explicitly (i.e. in their name).
Since there is now more or less a common set of such locales among various Linux and Unix systems, this seems to be
a de-facto standard although I am not aware of any more formal definition/listing/description of this.
On a modern Linux system, use the following command to get a list (not sure if it's appropriate to attach it here):
for l in `locale -a`
do echo "$l `LC_ALL=$l locale charmap`"

I have also tried to incorporate a best guess assembly of mappings from modern systems in my editor mined so it can
derive the encoding from the locale name, so you could also take a working list from there.

I think this list should be used for reference to define the locale/encoding mapping, other choices may be more attractive
but only raise problems.

The downside is that a user, who needs to work under the default ANSI
codepage for some reason, has to know the name of the default ANSI
codepage.  Right now any user who needs the default ANSI codepage can
simply set LANG to some language code and go ahead, without having to
know the number.  With your solution, that wouldn't be possible anymore
and the user would have to figure out the default ANSI codepage on the
system before being able to use it.

I honestly don't know if that's really a problem, though. But I don't
want to take that feature away for now. Anybody having a strong opinion
on this issue?
I wasn't quite aware that the old "codepage:oem" setting didn't strictly mean "CP850" or "CP437" but apparently the respective system locale.
If that is really needed, maybe the "C" locale should get you there, or some "OEM" as (I think) Andy proposed. If someone feels the need
to combine a specific language setting with the unspecific "system locale", well, maybe a pseudo encoding name could be invented to form
names like "en_GB.OEM". Just leaving out the encoding suffix should not have that effect as I argued above.

Kind regards,

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]