i've a plugin that should process some mails, so i need to get attachments from an imap mail and do some stuff.
All seem to work but i've a single mail that have a strange attachment header and i'm not able to get it correctly, here the attachment header:
--_01d0aeb2-3f01-4153-9121-66b7af6924f1_
Content-Type: application/msword
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=
"=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?=
=?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
"x" are for privacy but that should not be important, the problem is that when i try to get the filename of this attachment with javaMail:
Attachment att = new Attachment(mailPart);
String filename = att.getFilename();
i get only this: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
seem that it doesn't read the second line.
I've also tried to get the filename in another way:
mailPart.getHeader("Content-Disposition").getAttribute("filename").toString();
and that return: filename="=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?==?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
so it seem that the attribute is correctly readed, but if i try to get:
mailPart.getHeader("Content-Disposition").getAttribute("filename").getValue();
then i get again a truncated filename: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
anyone know how to get the complete filename or how i should decode the filename attribute?
thanks for any help
If you're using IMAP, the IMAP server is parsing the mail headers and returning the parsed values to the JavaMail client. Your Content-Disposition header has several continuation lines. The IMAP server needs to properly combine those continuation lines and return the parameter values. It looks like the server is omitting the whitespace implied by the continuation line and joining the "?=" with the "=?". Without whitespace between them, they appear to be one encoded word instead of two, which likely explains why you're getting the wrong results when decoding them.
Try setting the System property "mail.mime.decodetext.strict" to "false"; this may allow JavaMail to decode the value. See the javadocs for the javax.mail.internet package for details.
Related
I am trying to figure out how to manage an attachment of a mail that has the filename chunked. I am on java 1.6 with javamail 1.5.1 and my code can manage all kind of mails but when I receive one from a specific adress(i can't talk with those guys) it doesn't import some attachments properly. When I open those atachments(assuming that this one's name is filename without extension.extension) with notepad I find this:
Content-Type: application/octet-stream;
name*0="filename without extension"; name*1=.extension
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0="filename without extension"; filename*1=.extension
before the base64 content. I tried to search for similar problems but I have the exact filename but it's splitted and the BodyPart.getFilename() method returns null. I was thinking about taking the whole header and work on that.
This should be supported by your version of Javamail.
System.setProperty("mail.mime.decodeparameters", "true");
For more info, search for "RFC 2231" on the package documentation of javax.mail.internet:
https://docs.oracle.com/javaee/6/api/javax/mail/internet/package-summary.html
I am currently writing a function to upload files into server.
My filename format is typical like this ACTION#USERNAME.TXT, I run into the error
java.lang.StringIndexOutOfBoundsException: length=41; regionStart=38; regionLength=-28
when on this line of code
writer.append("Content-Type: " + URLConnection.guessContentTypeFromName(fileName)).append(LINE_FEED);
I did some debugging and realised the problem was caused by the character '#'. Taking it out allows the file to be uploaded. The actual file allows for the # character so I don't really understand why would # cause a StringIndexOutOfBoundsException.
Could anyone enlighten me please?
The # sign has special meaning in a URL.
The #fragment part of a URL (see syntax) is never sent from the client to the server. It is a part of the URL that is handled by the client. It can be sent from the server to the client in links and redirects.
To include a # sign (or any other special character) in the file name, it must be escaped/encoded using %NN hex codes.
The encoding of # is %23, but you really should use a URL encoder.
Our application download files using HttpClient. We take the filename from the HTTP Header and emit out as SysOut (System.out.println())
When there are non-USASCII characters like umlauts the sysout does not decode correctlty.
Ex: filename Textkürzung.txt is printed in sysout (And also in console) as Textk³rzung.txt
How can we encode this to UTF-8? Unfortunately we don't get the encoded character-set from the HTTP Headers
May i know the use of response.addHeader when we already have response.setContentType in java...
I m unable find proper solution.
<% response.addHeader("Content-Disposition","attachment;filename=Report.xls"); %>
<% response.setContentType("application/vnd.ms-excel"); %>
Here the above second statement is enough to get response as excel format.
which scenario i need to use response.addHeader ?
please ...
This particular header :
"Content-Disposition","attachment;filename=Report.xls"
tells the browser to download the file as an attachment with default name Report.xls.
Also check the HTTP/1.1 specs
The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user
requests that the content is saved to a file.
An example is
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path
information present in the filename-parm parameter, which is the only
parameter believed to apply to HTTP implementations at this time. The
filename SHOULD be treated as a terminal component only.
If this header is used in a response with the application/octet-
stream content-type, the implied suggestion is that the user agent
should not display the response, but directly enter a `save response
as...' dialog.
Remember though , HTTP/1.1 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard.
IMHO , don't use JSP to do the downloading stuff , use a Servlet instead !
I don't write in Java, but I know there are many sharing the same feature.
And IMO it's just a shortcut.
BTW, there are so many headers... Not just Content-Type or something like that.
Whenever I try to know the content type of multipart message by using javamail API, I'm getting the content type as:
multipart/mixed;
boundary="----=_Part_19_32879825.1271840022140"
I've already disable my antivirus, but I'm still not able to terminate that boundary.
I'm trying to send the message using IMAP protocol.
I'm using Hmail Server.
Could anyone please tell me the reason of it?
If the email that you're sending contains an attachment, this is not an error. It is how the message header is really supposed to be:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"
This is a message with multiple parts
in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--
From: http://en.wikipedia.org/wiki/MIME
The value of the boundary attribute indicates where each message part finishes and the next one begins.
EDIT:
If you're getting an error related to missing end boundary (is that your question?), then you may want to set the missing end boundary to false:
The
mail.mime.multipart.ignoremissingendboundary
property may be set to false to cause
a MessagingException to be thrown if
the multipart data does not end with
the required end boundary line. If
this property is set to true or not
set, missing end boundaries are not
considered an error and the final body
part ends at the end of the data
That's from the JavaMail API.