Re: (Re-)coding problems forwarding calendar attachment

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> Bjørn Mork wrote:

> I have problems forwarding calendar attachments using a current CVS
> Gnus.

> I don't really know if this posting will survive since I'm posting it
> using Gnus, but I'm trying to force it to 8bit latin1 (knowing that
> there are really utf-8 characters embedded within this article).

Maybe it survived, if the changes that I made in the CVS trunk
solve your problem. ;-)

> This is how the original Microsoft generated blob looks like:

> ------_=_NextPart_001_01C7E4B1.D35AB8EB
> Content-Type: text/calendar; method=REQUEST; name="meeting.ics"
> Content-Transfer-Encoding: 8bit
> Content-class: urn:content-classes:calendarmessage

[...]

> So they are using
>  - 8bit encoding,
>  - mime-type text/calendar,
>  - default charset,
>  - vCalendar version 2.0

> This all looks good to me.  According to RFC2445, the default charset
> for an iCalendar object is UTF-8, and the text within the object looks
> like valid UTF-8 to me.

I've modified Gnus so as to use UTF-8 by default for decoding
text/calender parts.

> If I try to forward a mail like this, Gnus will recode the attachment
> using it's own defaults:

>  - quoted-printable encoding,
>  - mime-type text/calendar,
>  - charset utf-8,
>  - vCalendar version 2.0

> But when sendting it I get the annoying question

>  "Non-printable characters found.  Continue sending? (d, r, i, e, ?)"

> and even if I answer "i" to ignore, the contents
> is changed resulting in invalid UTF-8:

It is because Gnus doesn't decode the text/calendar part since
Gnus doesn't know the default charset for it, and inserts raw
UTF-8 data in the message buffer.

[...]

> If I try to forward a raw copy of the mail with the attachment (C-u 2
> C-c C-f), I get the mime-headers unchanged as expected.

(You don't need `C-u' in Gnus buffers; just type `2 C-c C-f'.)

Now you can simply use `C-c C-f' and Gnus will not make such a
question.  Even if you have to use `2 C-c C-f' in order not to
re-encode the text/calendar part, you will not be prompted for a
question now.  Or is it better that Gnus always uses the raw
form for text/calendar parts regardless of the prefix argument?

> But I get the same annoying question and the contents is still
> changed adding a "Ã" in front of the UTF-8 multibyte characters
> resulting in invalid UTF-8:

This is due to a bug in mml.el.