Thank you so much, Byrial. I'm so much amazed to learn that.
You may know, such message came from Microsoft Outlook Express 5.0. Once again I learned that MS is that irresponsible for the technology society. Or it's their trick again to dominate this kind of software. They've done it in browser - some bad imcompatibilty make people think netscape crippled. They've also tried to do it to java but were stopped. I respect those people that are willing to follow standards - it's them making our life easier, not M$. :-) best regards, charlie On Sat, Feb 09, 2002 at 07:53:01AM +0100, Byrial Jensen wrote: > On Sat, Feb 09, 2002 at 09:40:16 +0800, Charles Jie wrote: > > > But I found mutt doesn't decode them if such encoding happens at > > attachment. > > > > Content-Type: image/gif; > > name="=?big5?B?pN+4Zy5naWY=?=" > > Content-Transfer-Encoding: base64 > > Content-Disposition: attachment; > > filename="=?big5?B?pN+4Zy5naWY=?=" > > Right. These parameters may not ne encoded this way according to > RFC 2047, and Mutt won't decode them by default. > > It should help to set the "rfc2047_parameters" configuration > variable. > > > I did experiments and sent me a file in attachment with Chinese > > filename. Mutt displays OK. But it uses a different and strange > > encoding: > > > > ontent-Type: text/html; charset=big5 > > Content-Disposition: attachment; > > >filename*=big5''%A6p%A6%F3%BF%EF%A4%40%B1i%A6n%A7%C9%AD%DD%BD%CD%BA%CE%AB%BA%2Ehtm > > Content-Transfer-Encoding: 8bit > > > > What's the matter? > > This is the right way to be it: encoding as specified in RFC 2231.
