current charset guessing

[Werner Koch]

On Fri, 7 Jan 2005 18:23:34 +0100 (CET), Alain Bench said:

>     Thanks: It works in many cases, but fails on implicit charsets,
> ambiguous names, or platform specific spellings. Examples:

Okay.  I looked at it but to fix this we would need to reimplement
everything from libiconv or check whether a proper libiconv is
available.  This is something we should not not.

>     Note in such locales, "make check" also fails:

> | ./gpg_dearmor > ./pubring.gpg < ./pubring.asc
> | gpg: conversion from `utf-8' to `cp-1252' not available

That should not anymore fail because it has been changed to a warning.

> table. BTW the output of nl_langinfo(CODESET) also needs sanitizing on
> some platforms.

Well, this is something libiconv should care about and not GnuPG.

>     CP-1252 is a superset of Latin-1 with 27 more chars. Example one can
> write "Lecœur" (oe ligature) in CP-1252, not in Latin-1:

I see. Removed that.

>     I'd say treating CP-1252 as Latin-1 is good enough and better than
> nothing when iconv is unavailable. But it's suboptimal when iconv is

We better make shure that iconv is available.

>     Looking in libiconv 1.9.2 source: No such alias. But in
> libiconv-1.9.2/libcharset/lib/localcharset.c there is a whole set of
> aliases:

I adapted that list and use it for Windows.

>     Good: Thanks. ISO-8859-15 is Latin-9, just to confuse us:

Thanks.

>     Hum... Libcharset seems to call GetACP() only, never
> GetConsoleOutputCP(). IIUC that would be false for console apps? I'm

GetConsoleOutputCP is the correct thing to do but it does not harm to
fall back to getACP.

>     US-Ascii is not Latin-1. I frequently use a 7 bits terminal in a
> LANG=fr_FR.us-ascii locale, with or without //TRANSLITeration. That
> false aliasing would break it. It would also break any case where
> locales are unset and charset is different. Bad idea, I'd say.

That is right but we got a lot of complaints about these warnings from
US people and it seesm reasonable that many more machines are not
configured properly for Latin-1 than those who are explicitly using
ascii.  Given that keys may contain any characters and as a user you
don't have any control over it becuase this is a public information,
assuming Latin-1 still seems to be working solution for me.

I considere to make a installer based version of iconv.dll to ease
installation and give hints during GnupG installation on the need of
that dll. The 1.4.1 binary distribution will use an NSIS based
installer.


Salam-Shalom,

   Werner