What can be done?
Are you setting the character encoding correctly?
try this:
mimemessage.setText(s6,"utf-8");
you may need utf-16, cant remember what char set hebrew is on off the top of my head.
try here http://www.i18nguy.com/unicode/codepages.html
3 years late, but if someone hits this one, I found the answer:
MimeMessage message = new MimeMessage(mailSession);
Multipart multipart = new MimeMultipart("alternative");
BodyPart htmlPart = new MimeBodyPart();
htmlPart.setContent(new String(messageHtml.getBytes("UTF8"),"ISO-8859-1"), "text/html");
multipart.addBodyPart(htmlPart);
message.setContent(multipart);
message.setFrom(new InternetAddress(from));
message.setSubject(subject, "UTF-8");
The trick was to convert my html from UTF-8 (the way it came from my message_iw.properties), and then transform it into ISO format, so that there's no need to set any headers.
Related
I have an incoming MimeMessage in my JAMES mail server. I want to create an eml file dumping the message completely. I tried using the writeTo method of MimeMessage - resulting file contains only the text body of the email. The attachments are not written to the eml file. My code is something like
String logFileName = "dumpNow.eml";
incomingEmail.getMessage().writeTo(new FileOutputStream(new File(logFileName)));
I do not get any multipart content in the dump. Is there any Util available to do this? Apache Mimeutils is also giving the same result.
Try this :
// Create your attachement file
File emlFile = new File("myFile.eml");
emlFile.createNewFile();
incomingEmail.getMessage().writeTo(new FileOutputStream(emlFile));
MimeBodyPart attachment = new MimeBodyPart();
DataSource source = new FileDataSource(emlFile);
attachment.setDataHandler(new DataHandler(source));
attachment.setHeader("Content-Type", "application/octet-stream");
attachment.setFileName("myFileName.eml");
attachment.setDescription("My file description");
attachment.setDisposition(Part.ATTACHMENT);
multipart.addBodyPart(attachmentFile);
I think it is because you missed to set the header and the disposition in your code.
Hope it helps,
I try get email with Zend_Mail_Storage_Pop3 but the chars come with encoding strange.
Example
Endere=E7o
Paran=C3=A1
shold be
Endereço
Paraná
You do not give much explanation or code ...
I can propose this:
When you set your email, use utf-8:
$mail = new Zend_Mail('UTF-8');
I try to download emails from my POP3/IMAP accounts using Zend Framework 1.12 and it's working fine. QP header fields will be decoded automatically. However, when a header field (from name or subject) is base64 encoded like this:
=?UTF-8?B?c3DEvsWIYcWl?=
it will not automatically base64 decode it. Don't know why. While it would be easy to fix this "my way", I would like to do it right.
Can anybody recommend a good approach how to deal with base64 headers?
Thanks a lot.
You can use use iconv_mime_decode_headers() PHP function.
$decoded = iconv_mime_decode_headers('Subject: '.$subject, 0, "UTF-8");
var_dump(decoded['Subject']);
Note, that you can pass multiple header parameters to one function, by separating them with newline or "\n". e.g.
$headers = "Subject: {$subject}\nFrom: {$from}";
$decoded = iconv_mime_decode_headers($headers, 0, "UTF-8");
In this case you will get array with keys "Subject" and "From" with decoded data.
Its the responsibility of mail mime parsers to decode the mail headers. There are open source base64 decoders available on net which can be used to decode these strings.
I have a mailto link with hebrew text in the body parameter.
I am getting gibberish as a result.
example result:
׳©׳ ׳”׳׳™׳¨׳•׳¢:
׳׳×׳—׳™׳: 11.05.2011
׳׳¡׳×׳™׳™׳: 09.04.2014
׳”׳¢׳¨׳•׳×
I can fix this by adding requestEncoding="windows-1255"
in the web config.
but this causes unwanted side effects in the rest of the site.
How can I get proper hebrew text in the mail body?
try this in your href:
mailto:?body=שם האירוע: fixing the encoding issue 27.12.11%0Aמתחיל: 11.05.2011%0Aמסתיים: 09.04.2014%0Aהערות: encoding was messed up here as well%0A&subject=fixing the encoding issue 27.12.11
I played around with this link:
http://www.unicodetools.com/unicode/convert-to-html.php
you should encode your Hebrew text body before sending the e-mail.
i.e:
final MimeMessage msg = new MimeMessage(session);
msg.setText(message, "utf-8");
msg.setHeader("Content-Type", "text/plain; charset=UTF-8");
MimeBodyPart mbp1 = new MimeBodyPart();
mbp1.setDataHandler(new DataHandler(new ByteArrayDataSourcemessage.toString), "text/html")));
mbp1.setContent(new String(message.getBytes("UTF8"),"ISO-8859-8-i"), "text/html");
Multipart mp = new MimeMultipart();
mp.addBodyPart(mbp1);
msg.setContent(mp, "text/html");
worked fine for me :)
good luck !
Dave.
I'm creating an email message using CDO object (and VB6, but that doesn't really matter).
With New CDO.Message
.To = "<address>"
.Subject = "Manifest test 8"
.Organization = "<company>"
.From = "<address>"
.Sender = .From
With .Configuration
.Fields(cdoSendUsingMethod).Value = cdoSendUsingPort
.Fields(cdoSMTPServer).Value = "192.168.0.4"
.Fields.Update
End With
With .AddAttachment("c:\import\customermanifestOURACCOUNT11122008110032.dat")
.Fields(cdoContentDisposition).Value = "attachment; filename=""Consignor.dat"""
.Fields.Update
End With
.Send
End With
As you can see, the message is empty and contains an attachment that I rename in the email.
The attachment is an ASCII text file, fixed-width, that contains some output from our systems, one record per line, separated with CRLF.
When the message gets sent, all CRs get stripped out the attachment, so the receiver gets a file that only has LFs and therefore is corrupted.
I tried to change ContentEncoding to 7bit and base64, didn't work.
I tried to set ContentMediaType for the attachment to text/plain, didn't work.
I tried to not rename the attachment after adding, didn't work.
The ContentMediaType for the attachment is set to application/octet-stream by default, so I can't figure out why (and by what) it gets changed in the first place.
If I execute .SaveToFile() on the attachment right after .Send(), it saves valid file on the disk.
Is this a problem in my code, or is it a mail server setting or something?
Ok, that was weird.
We used our gmail accounts to test that thing, more specifically, gmail web interface. We clicked attachments links to save reveived files. And the files were corrupted.
As soon as we instead tried some thick clients, it turned out to be fine. All files get download properly without any corruptions.
So I assume this is a bug in gmail web interface (as opposed to gmail POP3 interface).
I have not used CDO in a long time, but i remember having this issue in the past. By trying different things, we figured that if there was any content in the body of the message the attachments were sent properly.
Weird, i know.
try it and let us know.
I just got this same trouble. I switched to Jmail and my CSV (text file) was now exactly like the original when I read it from gmail.
I compared the original message (in Gmail, option - view original message) and discovered that with CDO.Message, the attachment is not encoded really well, it is kept in text format, and the mail client do what he wants with it. With Jmail, the message is encoded in Base64 so it is kept in its original state from the start to the end. So, be careful when using CDO.Message with text file attachments! Try using Jmail (free) instead.
CDO.message: Content-Transfer-Encoding: quoted-printable
Jmail.message: Content-Transfer-Encoding: base64