attachment filename can't support Chinese

[pkptzx]

attachment name can't support Chinese

all contain Chinese word attachment filename , return "filename":""

[pkptzx]

just fixed filename 1.com.spartasystems.holdmail.domain.HeaderValue `String[] parts = valueString.split(";"); value = parts[0]; for (int i = 1; i < parts.length; i++) { String[] paramToken = parts[i].split("=");

            String keyTrimmed = paramToken[0].replaceAll(TRIM_PARAM_REGEX, "");
            String valTrimmed = paramToken.length < 2 ? "" : parts[i].replaceAll(keyTrimmed+"=", "").replaceAll(TRIM_PARAM_REGEX, "");
            LoggerFactory.getLogger(HeaderValue.class).debug("head {} = {}",keyTrimmed,valTrimmed);
            params.put(keyTrimmed, valTrimmed);

        }`

2.com.spartasystems.holdmail.rest.MessageController.getMessageContentByAttachmentId if(StringUtils.isNotBlank(content.getAttachmentFilename())) { String fn = content.getAttachmentFilename(); try { disposition += " " + encodeFileName(request, javax.mail.internet.MimeUtility.decodeText(fn)) + ";"; } catch (UnsupportedEncodingException e) { disposition += " " + encodeFileName(request, fn) + ";"; } }

=================

`private String encodeFileName(HttpServletRequest request, String fileName) { String userAgent = request.getHeader("User-Agent"); try { String encodedFileName = URLEncoder.encode(fileName, "UTF8");

        if (userAgent == null) {
            return "filename=\"" + encodedFileName + "\"";
        }

        userAgent = userAgent.toLowerCase();
        // IE

        if (userAgent.indexOf("msie") != -1) {
            return "filename=\"" + encodedFileName + "\"";
        }

        // Opera

        if (userAgent.indexOf("opera") != -1) {
            return "filename*=UTF-8''" + encodedFileName;
        }

        // Safari 

        if (userAgent.indexOf("safari") != -1 || userAgent.indexOf("applewebkit") != -1 || userAgent.indexOf("chrome") != -1) {
            return "filename=\"" + new String(fileName.getBytes("UTF-8"), "ISO8859-1") + "\"";
        }

        // FireFox

        if (userAgent.indexOf("mozilla") != -1) {
            return "filename*=UTF-8''" + encodedFileName;
        }

        return "filename=\"" + encodedFileName + "\"";
    } catch (UnsupportedEncodingException e) {
        throw new RuntimeException(e);
    }
}`

[barryoneill]

Thanks for the investigative work; I'll try and work a fix for this into the next release (which is a little overdue..)

[pkptzx]

F**K APPLE-MAIL !!!

APPLE-MAIL's filename is filename*, and value is URL encode , chaset head tag.

--Apple-Mail-4E2DBA30-E036-4DAD-A812-80F8AD052069 Content-Type: application/pdf; name=_________.pdf; x-apple-part-url=B85728B7-75A7-4375-A1C6-DC64176A54FB Content-Disposition: attachment; filename*=GB2312''%B5%CE%B5%CE%B3%F6%D0%D0%D0%D0%B3%CC%B1%A8%CF%FA%B5%A5.pdf Content-Transfer-Encoding: base64

[barryoneill]

Please, keep the language clean :) Yeah, apple mail has many quirks, it's not just the filename that I've found that causes problems, I think I may need to add a separate ticket just to handle some of those.

[pkptzx]

I fixed this issue , and main body.

[pkptzx]

I solve this issue , and main body. ^_^ I always think fixed=solve , sorry ,my English is very poor

[kinbod]

Has the Chinese issue been solved?

[barryoneill]

No, this fix hasn't been brought into the next release yet. @pkptzx if you have a branch with your changes, I'll work with you to bring it in.

[barryoneill]

I've reproduced this issue and have discovered the following:

• This is RFC 2231, an extension to support longer and/or non-ASCII values in headers.
• Holdmail doesn't support this, its trivial header-parsing logic (as you've seen) results in a blank value when it encounters a RFC 2231 value.
• It's not 'attachment' specific, this might be affecting other header values too.
• Turns out despite what we thought, the apple variant above is also valid. The lack of a second * means that the value doesn't contain an encoding directive.
• Ideally, Mime4j (which Holdmail uses) would handle this automatically, but it appears not, see MIME4J-246 and MIME4J-109. The latter does contain a proposed patch which won't see the light of day because apparent licensing problems.

For now, I'll add a mapper containing something a little more compliant with RFC2231, but the ideal solution is for mime4j to deal with this.

[barryoneill]

Hi @pkptzx - A change for this went into master last night. Since it seems you're actively using builds from master, when you pick up this change, could you let me know if it's working for your data? It'll probably only take effect for new mails, not existing ones.

[barryoneill]

Ok - I'm going to consider this one done. Please re-open with sample data (attach the raw mail content ideally - see the 'Original Content' tab) if any problems are found.