<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #2956: Recipient address broken if containing Š character (UTF-8 code: 0xc5 0xA0)



#2956: Recipient address broken if containing Š character (UTF-8 code: 0xc5 
0xA0)

Comment (by Kyle Wheeler):

 {{{
 On Monday, September 17 at 10:38 AM, quoth Vincent Lefevre:
 > On 2007-09-16 11:59:33 -0500, David Champion wrote:
 >>>>> Subject: Re: [Mutt] #2956: =?UTF-8//TRANSLIT?Q?Reci?=
 >>>>>         =?UTF-8//TRANSLIT?Q?pient_address_broken_if_containing_?=
 >>>>>         =?UTF-8//TRANSLIT?Q?=C5?= character (UTF-8 code: 0xc5 0xA0)
 >>>
 >>> I do not set $send_charset. My $charset contains //TRANSLIT, but this
 >>> one is correct.
 >>
 >> I thought that //TRANSLIT was a libiconv extension, not defined by
 >> spec.  It's definitely not supported by all iconv implementations, so
 >> those wouldn't be able to parse this encoding string (regardless of
 >> correctness).
 >
 > The //TRANSLIT is supported by the libiconv implementations I use here.

 The fact that it's supported by the software that you use doesn't make
 it a valid encoding to send over the internet. We have standards for a
 reason! None of the encoding names that are valid for use in email
 include //TRANSLIT. That encoding name is invalid. Just because iconv
 accepts it doesn't make it valid. If mutt is generating this, then
 something is wrong... perhaps mutt should recognize and strip out
 //TRANSLIT strings?

 > So, that's fine. But this doesn't explain why Mutt uses //TRANSLIT to
 > generate this particular header. It is related to the isspace bug, as
 > this problem doesn't occur with the Euro symbol for instance.

 Wait, so, your mutt generates an encoding that doesn't contain
 //TRANSLIT if it's encoding a Euro symbol? That really is quite
 strange.

 > But in any case, Mutt shouldn't generate invalid UTF-8 sequences
 > (like here).

 Agreed.

 ~Kyle
 }}}

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2956#comment:>