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

Replies are listed 'Best First'.
Re^3: Email::MIME support for utf8 filename by Corion (Patriarch) on Dec 27, 2018 at 07:44 UTC
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...	[reply] [d/l] [select]
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]


Problems? Is your data what you think it is?
	PerlMonks