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:>