[Email-SIG] Problem Report for email.Utils.decode_rfc2231
msapiro at value.net
Wed Jul 19 07:02:22 CEST 2006
Barry Warsaw wrote:
>The way I read the RFC however, I don't think the patch is quite
>right. Specifically, you can mix encoded and non-encoded segments in
>an extended parameter, like so:
>filename*1="This is%20not encoded"
>I believe this should end up with a 'filename' parameter with a value:
>This is encodedThis is%20not encoded
>Further, if any segment ends in a * then the charset and language
>information must appear at the front of the string, but this is
>decoded after segments are %-decoded and all the segments are
>concatenated together. (The RFC appears to be a bit ambiguous here,
>but this is the only interpretation that makes sense to me.)
I agree with the above. I considered that there could be mixed encoded
and non-encoded segments, but I was focused only on not trying to
split the charset and language info when it wasn't there, so my patch
is over-zealous and will decode non-encoded segments in the mixed case.
I'll take a detailed look at your patch tomorrow I hope and let you
know what I think.
Mark Sapiro <msapiro at value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
More information about the Email-SIG