Re: Still having encoding problems

On Saturday 14 February 2009 22:27:37 Ingo Klöcker wrote:
> On Saturday 14 February 2009, Anne Wilson wrote:
> > On Wednesday 11 February 2009 22:52:11 Ingo Klöcker wrote:
> > > On Wednesday 11 February 2009, Anne Wilson wrote:
> > > > On Wednesday 11 February 2009 20:33:54 phep wrote:
> > > > > Anne Wilson a écrit :
> > > > > > I'm flabbergasted!  So an English company sends out English
> > > > > > email to English customers, using an encoding that will make
> > > > > > no sense to them?
> > > > > >
> > > > > > KMail didn't get it wrong - the headers say
> > > > > > charset="iso-8859-1". I guess they've just got a new Windows
> > > > > > install :-)
> > > > >
> > > > > Sorry, I made a copy/paste error in my previous message : I
> > > > > meant "ISO-8859-1 displayed as ISO-8859-15".
> > > > >
> > > > > According to what you observed, it's KMail's fault as I
> > > > > considered previously. ISO-8859-15 is mainly used for it
> > > > > introduced the € (Euro) character in ISO-8859 tables. I
> > > > > understand that this may not be what an English company might
> > > > > wish to use ;-).
> > > > >
> > > > > Sorry for the confusion.
> > > >
> > > > Unless I'm much mistaken, 8859-15 is actually mostly used in
> > > > British English mail.  The € is present, but so is the £, so
> > > > that's no problem.  I'm guessing that it is a new setup and they
> > > > haven't realised that they have a different charset.  I've
> > > > emailed them and gently pointed it out :-)
> > > >
> > > > Meanwhile, if you are saying that kmail displayed it as 8859-15,
> > > > I guess I should file a bug.
> > >
> > > I'm pretty sure KMail only does what it is told to do. If the
> > > message advertises the charset as ISO-8859-1 (latin1) then KMail
> > > uses this charset for decoding/displaying. If the message
> > > advertises the charset as ISO-8859-15 (latin9; don't you love the
> > > consistent numbering schemes ;-) ) then KMail uses latin9.
> >
> > The headers say it is 8859-1
> >
> > > ...unless the user forces KMail to do something else, e.g. by
> > > setting an override character encoding.
> >
> > KMail is set to Auto
> >
> > > It'd be great if you could forward such a message to me.
> >
> > On its way :-)
>
> The message is a multipart/alternative message with plain text part and
> HTML part. The interesting lines of the message are:
>
> [...]
> Content-Type: multipart/alternative;
>   boundary="=_NextPart_2emsgsadvnqw3nerasdf";
>   charset="iso-8859-1"
> [...]
> --=_NextPart_2emsgsadvnqw3nerasdf
> Content-Type: text/plain
> [...]
> --=_NextPart_2emsgsadvnqw3nerasdf
> Content-Type: text/html
> [...]
>
> So the charset is specified for the enclosing multipart/alternative body
> part, but no charset is specified for the enclosed text/plain body part
> or the enclosed text/html body part. Therefore KMail uses the fallback
> encoding for the text in the text/plain body part and the text/html
> body part. Anne told me that she had set the fallback encoding to
> ISO-8859-15. This explains Anne's observation.
>
> A message with correctly specified charset would look as follows:
>
> [...]
> Content-Type: multipart/alternative;
>   boundary="=_NextPart_2emsgsadvnqw3nerasdf"
> [...]
> --=_NextPart_2emsgsadvnqw3nerasdf
> Content-Type: text/plain;
>   charset="iso-8859-1"
> [...]
> --=_NextPart_2emsgsadvnqw3nerasdf
> Content-Type: text/html;
>   charset="iso-8859-1"
> [...]
>
So now we all understand a little more about how this all ties together.  
Good.  I hate mysteries :-)

It seems I had misunderstood 'fallback'.  My (wrong) logic said that it would 
be used if utf-8 had any problems with the content.  Now I understand its 
purpose I have simply set the fallback to utf-8.  Hopefully all will display 
better for the change :-)

Thanks for taking the time to educate us, Ingo :-)

Anne

_______________________________________________
KDE PIM users mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmX+4QACgkQbMErw/n0TZpUpQCfafrBQhstmUhsLyoX5pdFNsIi
fp8AmwbimjHKxaW9Rm6qg0zXr97LE250
=PfKi
-----END PGP SIGNATURE-----