[Kde-pim] codec from a KMime::Message

[Thomas McGuire]

Hi,

On Wednesday 28 October 2009 15:37:30 Thomas McGuire wrote:
> For KMail to display the message correctly, it needs to know the charset
> the mail was written in. If the wrong charset is used, the mail will be
> displayed incorrectly, e.g. umlauts are displayed the wrong way. (There is
> even a word for that: Mojibake).
>
> So to display the mail correctly, the charset encoding needs to be known.
> To solve this, the charset encoding is noted down in the mail itself, as
> part of the content-type header.
>
> [..]
> 
> Summary:
> Fallback charset: Charset that is used when the message has no specified
> charset
> Override charset: Charset that is always used, even if the message
> specifies a charset
> MIME part: Mails can consist of multiple parts, which form a tree. Each
> part has headers.

Ok, now let me explain charset vs content-transfer-encoding, for the brave.

The charset is only used when displaying text MIME parts, e.g. text/plain.

But what is content-transfer-encoding?
The problem is that mails can not use the full byte range from 0 to 255 when 
being sent, this is disallowed.
However, most attachments like images, zip files and so on do use all 256 byte 
values. Text encoded with some charsets also use the full byte range from 0 to 
255, for example UTF-8.

Mail sending is constrained to only a part of the byte range, 0 to 127 I 
think. This is fine for ASCII text, since that is 0 to 127 only, but things 
like attachments or UTF-8 text which use the full byte range can not be sent.

To solve that, stuff that uses the full byte range needs to be 
transformed/encoded to something that only uses the first 128 byte values. The 
encoding that does this is called content-transfer encoding. There are 4 
different content-transfer-encodings:

7-bit: This does nothing, it assumes that the input is already in the 0 to 127 
byte value range, and therefore the input can be sent unencoded.

base64: Encodes each and every byte-value into two human-readable characters 
from the alphabet

quoted-printable: Encodes each non-ascii character as an equal-sign followed 
by two human-readable characters from the alphabet. The advantage over base64 
is that nearly all ASCII characters remain unchanged and is therefore much 
more human-readable, but the disadvantage is that this encoding scheme has 
more overhead.

8-bit: This is an exception, some SMTP servers actually do support sending 
mails which contain the fully byte range from 0 to 255. For those SMTP 
servers, input that uses the full byte range does not need to be encoded at 
all, which is called the 8-bit content-transfer-encoding.

The rule is: Use 7 bit if it is possible, mail clients can deal with that the 
best and it has no space overhead.
If something doesn't fit into 7 bit, use either base64 or quoted-printable. It 
depends on the input which of those is best for space usage. quoted-printable 
is much more human-readable, though.
KMime even has a nice class to detect which is the best content-transfer-
encoding for a given input, see KMime::CharFreq::type().

(BTW, it is even more fun when dealing with linebreaks, but even I don't know 
the details there)

For text parts, the content-transfer-encoding is applied on top of the charset 
encoding, e.g. first the text is charset-encoded with ISO-8859-15, then it is 
content-transfer-encoded with quoted-printable.

Non-text parts, like attachments, don't need a charset encoding, since there 
is no text to display. Those parts are encoded with the content-transfer-
encoding only.

Content-transfer-encodings are specified in RFC 2045, section 6.

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091028/afe5a925/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/