users@javamail.java.net

Re: problem with MimeBodyPart.getFileName()

From: Oleg Sukhodolsky <oleg.sukhodolsky_at_gmail.com>
Date: Sat, 1 Aug 2009 13:43:00 +0400

On Sat, Aug 1, 2009 at 11:01 AM, Bill Shannon<bill.shannon_at_sun.com> wrote:
> Oleg Sukhodolsky wrote:
>>
>> Hi Bill,
>>
>> On Fri, Jul 31, 2009 at 9:12 PM, Bill Shannon<bill.shannon_at_sun.com> wrote:
>>>
>>> See the mail.mime.decodeparameters System property described in the
>>> javadocs for the javax.mail.internet package.
>>
>> as you can see the first variant of params value in the test has no
>> non-ASCII symbols, but it still doesn't work.
>> So, I think this is why mail.mime.decodeparameters doesn't help me :(
>> Do you have any other magic property
>> to share with me ;)  Or I have to try to implement parsing of such
>> filename format myself?
>
> Ya, sorry, I should've looked closer.
>
> The message is incorrectly formatted.  There should be a semicolon
> after each of the pieces of the filename parameter.  Whatever program
> created the message is broken.  Please report the problem to the owner
> of the program that created the message.
>
> The correct message format is:
>
> Content-Disposition: attachment;
>  filename*0*="UTF-8''%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82
> %D0%BF%D1%80%D0%B5";
>  filename*1*="%D0%B4%D0%BE%D0%BF%D0%BB%D0%B0%D1%82%D0%B0
>  %D0%9E%D0%A1%D0%9D";
>  filename*2*=".doc";
>
> (Note that the example in section 4.1 of RFC 2231 is buggy in this same
> way; you have to read the ABNF to determine the correct syntax.)

After some investigation I've found that the problem has been fixed in
the mail program (RoundCube Webmail).
Hope it will be updated on the sender's host soon :)

>> BTW at
>> http://java.sun.com/products/javamail/javadocs/javax/mail/internet/package-summary.html
>> description for this property says
>> "If set to "true", non-ASCII parameters in a ParameterList, e.g., in a
>> Content-Type header, will be encoded as specified by RFC 2231. The
>> default is false."
>> I wonder if it really means that java mail will ENCODE the param value
>> and I will see it encoded?  Why someone may need this?
>
> Yes, the descriptions for the encode and decode properties are reversed.
>  Sorry.

no problems, just hope it will be fixed soon :)

With best regards, Oleg.