Because of how add_header() works under the covers, although we previously were encoding the information for the attachment name as ASCII, when we joined this information with the other arguments in the add_header() call (which are actually Unicode literals, due to an import statement at the top of the file) the entire header would be represented as a Unicode literal.
Thus, calling get_param() would successfully parse the string into a tuple according to RFC 2231, but all the strings are Unicode. Thus, calling email.utils.collapse_rfc2231_value() on this tuple will fail as it expects ASCII strings, not Unicode.
Fixed, thanks! Would it be too much trouble to have the version bumped? I'm hoping not since you already did all the hard work of getting the tests in order.
Fixes #71.
Because of how
add_header()
works under the covers, although we previously were encoding the information for the attachment name as ASCII, when we joined this information with the other arguments in theadd_header()
call (which are actually Unicode literals, due to an import statement at the top of the file) the entire header would be represented as a Unicode literal.Thus, calling
get_param()
would successfully parse the string into a tuple according to RFC 2231, but all the strings are Unicode. Thus, callingemail.utils.collapse_rfc2231_value()
on this tuple will fail as it expects ASCII strings, not Unicode.cc: @amcgregor