Re: charset=macintosh

[Simon Josefsson <jas@extundo.com>]

Jesper Harder <harder@myrealbox.com> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Jesper Harder <harder@myrealbox.com> writes:
>>
>>>    Just because you're using UTF-8, mac-roman, EBCDIC or whatever on
>>>    your local system doesn't mean that it's a good guess that you'll
>>>    receive mail and news using this charset.  
>>
>> I think this guess is better than no guess at all.
>
> Well, I think experience shows that UTF-8 isn't a good guess.  It's a
> bad guess for dk.*, and as Karl says also for de.*.  
>
> Previously `gnus-group-charset-alist' had (".*" iso-8859-1) as the last
> entry -- this was probably better for the majority of users.
>
> I haven't got any statistics to back it up, but I suspect that clients
> which send UTF-8 are probably newer, and thus more likely to include a
> proper MIME charset declaration.

Seems reasonable.

> So, I think it's much more likely that the charset of a message with an
> undeclared charset is iso-8859-x rather than UTF-8.

Or ISO-2022.  Or Big5.  The problem with choosing ISO-8859-X is that
it is western centric, and probably rightly be considered offensive.

But what if you are saying about UTF-8 clients being MIME capable is
true, and since UTF-8 is typically never preferred by current emacsen,
doesn't emacs' current guessing works the best we can hope for?
Doesn't it detect among ISO-8859-X, ISO-2022 and Big5 properly?  I
think it does.

So there is only a problem where:

  1) UTF-8 is used without MIME tagging since emacs never guess this
     correctly, but you argue (and I agree) that this case is unlikely.

  2) Users with emacs in UTF-8 prefers UTF-8 too often, even when the
     data is invalid UTF-8 and another encoding should be selected.

The second situation is a bug, and I hope we can fix this.  Maybe I
missed something.