Re^3: Email::MIME support for utf8 filename

Yes, that makes it much easier to find where the warning originates:

The warning comes from Email::MIME::ContentType line 106:

    if ($STRICT_PARAMS and length $ct and $ct !~ /^;/) {
        carp "Missing semicolon before first Content-Type parameter '$
+ct'";
[download]

So, one very simplistic workaround is to set $Email::MIME::ContentType::STRICT_PARAMS to 0 to suppress this warning.

I don't know where/why the content type string goes awry, but that's to debug another day...

Comment on Re^3: Email::MIME support for utf8 filename Select or Download Code

Replies are listed 'Best First'.
Re^4: Email::MIME support for utf8 filename by Arik123 (Beadle) on Dec 27, 2018 at 08:25 UTC
Okay, that worked. Interestingly, it not only suppressed the warning, but also, below in the code, enabled Email::MIME to really extract the filename.... Thanks a lot!	[reply]
Re^5: Email::MIME support for utf8 filename by Corion (Patriarch) on Dec 27, 2018 at 11:21 UTC
I think something about that line is not strict enough for the regular expressions to match, but I don't immediately see what makes Email::MIME::ContentType dislike that line. Update: It seems that the handling of Email::MIME::ContentType does not like `?` in the string (and the test suite does not contain anything like `name="?UTF-8?foobar"`). RFC 2048 allows such values (I think), so I think that this causes the bug (but I haven't written a proper test case to reproduce this). I haven't reported the issue yet, so if anybody wants to beat me to the punch (or finds the existing issue for that), feel free to open an issue yourself!	[reply] [d/l] [select]