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


On Sep 29 13:05, Thomas Wolff wrote:
> Corinna Vinschen wrote:
>> 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`"
>    done
>
> 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.

This isn't feasible for now.  As I described in the documentation, the
actual content of the language and territory part is not evaluated for
now.  *Only* the charset part (and the cjknarrow modifier, FWIW) have
a meaning for newlib/Cygwin so far.  What happens for now is that
Cygwin calls a function which fetches the ANSI codepage and generates
the current charset from there.  So that's what happens:

   LANG="C"               -> UTF-8
   LANG="xx"              -> charset equivalent to ANSI codepage
   LANG="xx_XX"           -> ditto
   LANG="xx_XX.CHARSET"   -> Use charset CHARSET

We won't add extra functionality.  In the long run it would be nice to
change the setlocale functionality to use actual locale files in every
respect, but that's wishful thinking for now.

To return to the original problem which started this request. 

I asked if the default charset for the japanese language should be set
to EUCJP rather than SJIS.  The actual implementation would have been
like this

  if (lang="xx or lang="xx_XX" with x in [a-z] and X in [A-Z]?)
    set_charset_from_codepage()

  set_charset_from_codepage()
  {
    switch (GetANSI ())
    [...]
    case 932:
      charset="EUCJP"    <-- Instead of the current `charset="SJIS"
    [...]
  }

Everything going beyond this in complexity is out of the question for now.
  

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


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