Stephan Siano created CAMEL-13024:
-------------------------------------
Summary: Camel-Mail breaks some attachment names with many special
characters
Key: CAMEL-13024
URL: https://issues.apache.org/jira/browse/CAMEL-13024
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.23.0
Reporter: Stephan Siano
Attachments: MailBindingAttachmentEncodedFilenameTest.java
The patch for CAMEL-12630 introduced the following line for Attachment file
names in the MailBinding class.
{code:java}
String fileName = FileUtil.stripPath(part.getFileName());{code}
This code usually makes sense, it strips paths from attachment names. However,
if the file name of the attachment contains many non-ASCII characters (more
than ASCII characters) the file name provided by the mail is Base64 encoded,
e.g.: "=?UTF-8?B?6Kq/5pW0?="
As the / is a valid character in Base64 encoding (but is not a path delimiter
there) the stripPath() call on that string will mutilate the filename to
"5pW0?=".
A workaround for this issue is to set the Java system property
"mail.mime.decodefilename" to "true". In this case the part.getFileName() will
decode the filename before stripping paths.
The attached unit test might demonstrate the issue.
I am not sure how this can be fixed in a compatible way. One option would be to
perform a MimeUtility.decodeText() call on the file name (if it is not null),
which will essentially have the same effect as setting the system property
(which means that the attachment filename is decoded before processing it
further), but this will be kind of incompatible.
Note: The issue will not occur if there are more ASCII characters than
non-ASCII characters in the filename, because in that case the non-ASCII
characters will be encoded using quoted printable encoding (which does not
include a "/" character), and even if the file name is Base64 encoded it does
not necessarily mean that the Base64 encoded filename contains a "/", so you
might hardly see that issue in real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
