[rt-users] Email Subject Header creating fragmented strings when decoded

Kevin Falcone falcone at bestpractical.com
Fri Mar 18 10:28:55 EDT 2011


On Fri, Mar 18, 2011 at 03:14:17PM +0100, Lars Reimann wrote:
> the following problem is very annoying:
> RT Encodes Subject lines using the following concept:

Which version of RT

> Original example Header
> 
> Subject: =?UTF-8?B?W3NlcnZpY2UubWV0YXdheXMubmV0ICM2NzAyOF0gU3BlaWNoZXJwbGF0eiBF?=
>  =?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?=
> 
> The header is split into 2 parts:
> 
> 1st part decoded: "[Queue Name #Ticket nubmer] First part of subject line"
> 2nd part decoded: "Second part of subject line"
> 
> Completely decoded string: "[Queue Name #Ticket nubmer] First part
> of subject line"_"Second part of subject line"
> 
> The underscore (_) marks an additional space character which is
> introduced into ALL emails on decoding the two UTF parts.
> 
> 
> I double checked with decoding UTF in python. Results: When using 2
> UTF parts, a decode introduces an additional space. When using only
> ONE UTF-string (the above subject w/o padding and UTF header) the
> decode is done correctly!
> 
> If would be very glad the resolve this problem. If RT could use only
> one UTF string, the problem would go away.
> How can we do that?
> And: does anyone have the same problem with email clients (we use
> evolution and thunderbird, but most likely other clients are also
> affected).
> 
> p.s. It's unclear to me when UTF encoding is used. Sometimes the
> Subject line is not UTF encoded and uses ASCII. Perhaps it depends
> on non-ASCII characters within the subject.
> 
> greetings,
> l.r.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110318/1c6ffe0f/attachment.sig>


More information about the rt-users mailing list