I have an input field <input type="file"> in a form, and want to send this file as an attachment using PHPMailer. The file reaches my PHP script as base64, stored in $fileBase64. This is for example what it looks like (beginning of file contents) when it's a pdf file:
data:application/pdf;base64,JVBERi0xLjcKCjQgMCBvYmoKKElkZW50aXR5KQplbmRvYmoKNSAwIG9iagooGVjBdh...
Supposedly I thought I'm meant to send this using PHPMailer's AddStringAttachment(), no?
$mail = new PHPMailer(true);
// ...PHPMailer config code
$mail->AddStringAttachment($fileBase64, $filename);
$mail->Send();
The email reaches the inbox fine, and there's a pdf file attached with almost exactly the same file size (only a few bytes off), but when I open it, Acrobat Reader tells me the file is corrupt, damaged, badly encoded and stuff like that. Same thing happens when I send a jpg - Windows tells me the format is unsupported. I also tried specifying the encoding and filetype at AddStringAttachment(), like so when it's a pdf file:
$mail->AddStringAttachment($fileBase64, $filename, 'base64', 'application/pdf');
This code above has the same result.
Does anyone have an idea of what I'm doing wrong? Thank you!
Related
Recently I changed the extension of an .apk file to .txt and despite this, I was able to open it on Notepad with some random characters, that weren't available on the keyboard in the file. org/antlr/runtime/ANTLRFileStream.class…TmOÓP=w[×QËÀ)ê|A…ÑETÔ¢NP¢™ãË—º•Q3ZÓcüþ¿j",£ß4ñGÏmÇñ˽Ïs{žçœçeûùëóW ±¨á0F5d0ÖA˔‹LÈã’ŠËR˜PqEƒ†Iy\•ØkÒºÞÁЂ´¦TL«˜H95{ÙÚ°2K/×–Y³Üªù(ð·:%œv\'¸!Гû÷óðª#¢èUܵä¸öòæÆ Û_±^ÔÂt^ÙªZ¾#ýæc"XwêKž_5-7¨ù¦¿éΆmÞZ^Y*ÍS “ÛÖ¹µ¹7eûUàxn]% µ‘Ð^TÊvË^…kžUˆ;u_àTw<sÁ}µDL%ÛªØ>ùÄš#º…Rø˜¨;o)\,0ǚԞ݇ؓ‡àΪ<ò6ýr³¥GsÃ횪EOÌ_…É =è•Ç¬Ž#8ª£½ú^fùõ˜Ž›¸%pü IT{`Á2þ¶<Š:î`NÇ<î긇A ˜èÿïˆ8Ç0Q¥»¨#- Ze7srRÉšíVƒõÐ]0rí&tÀ”O´‡[Y±K ö¬H›¯Ü %÷¬8Ì) r+åšW·ÑÏF†¿,bd—i%h³ˆá8½YÄiª‘
Not just this, but while converting many other extensions like .jar,.xapk, etc. would show me these characters.Can anyone please explain, what factors are these characters based on, and how does the OS decides or try what characters to show in an unsupported file exactly.
Is there a way to get the original content through this data?
Lets say you created a text editor, which can write and save text files as well as open text files. you also defined the encoding that will be used to save text in binary files(all files when saved are binary). So your encoding looks something as following:
Your encoding Emacs encoding
TEXT BINARY TEXT BINARY
A 01000001 ă 01000001
B 01000010 Ћ 01000010
... ...
Z 01011010 Ϡ 01011010
lets say you create a file with 'ABZ' as its contents. this file when saved contains value 010000010100001001011010. When you open this file with your text editor, the editor finds 010000010100001001011010 as file contents and using above encoding it knows that its 'ABZ' hence it prints 'ABZ' on the screen.
Now lets say you open same file using emacs, since emacs uses its own encoding it displays "ăЋϠ", There is nothing wrong with emacs. it just doesn't know that data was written using your custom encoding.
So the point is that every file is written in a specific format, for example APK format can only be correctly understood by Android system. when you try to open the APK file in a text editor it just tries to make sense of binary data in the same way as emacs does in above example.
Is there a way to get the original content through this data?
If you know the originally encoding using which data was written, then you can read the contents of file using same encoding.
I'm searching for a method to convert msg files to eml format. I have Outlook 2010 but it appears only possible to save as msg. I did find some third party tools that can be used but I prefer not to use a third party tool - if possible.
If you are looking for a quick and dirty VB script, Redemption (I am its author) is probably your only option. Other options are IConverterSession (C++ or Delphi only) or explicitly building the MIME file one line at a time from various message properties (MailItem can be returned by calling Namespace.OpenSharedItem in the Outlook Object Model).
set Session = CreateObject("Redemption.RDOSession")
Session.Logon 'not needed if you don't need to convert EX addresses to SMTP
set Msg = Session.GetMessageFromMsgFile("c:\temp.test.msg")
Msg.SaveAs "c:\temp.test.eml", 1031
MSG file and EML file both formats are used for containing the email with the attachment, but different from each other. EML extension used by multiple email clients, other hand MSG file only used by Outlook email client. In your scenario, you need an effective way to convert multiple MSG files to EML format, by using Outlook email client you can easily convert MSG file to EML format by using save as option of Outlook email client, but this way cannot convert their attachment.
From the RFC for card 4.0 I learned that vcard 4.0 is always utf-8.
I am using ez-vcard to export contacts into a export.vcf file transferred via http:
response.setContentType("text/vcard; charset=utf-8");
response.setStatus(HttpServletResponse.SC_OK);
PrintWriter writer = response.getWriter();
VCardWriter vCardWriter = new VCardWriter(writer, VCardVersion.V4_0);
// add cards...
vCardWriter.close();
Guess what? Characters are not being encoded properly. If I open the file in a text editor, I see characters are messed up.
Any help?
It may be ignoring the character encoding specified in the content type because you are setting it to something other than text/html.
Try setting the character encoding using setCharacterEncoding() instead (make sure to call it before calling getWriter()).
response.setContentType("text/vcard");
response.setCharacterEncoding("UTF-8");
response.setStatus(HttpServletResponse.SC_OK);
PrintWriter writer = response.getWriter();
Also, make sure your text editor is reading the file correctly. During my testing, I found that Eclipse would not display UTF-8 characters correctly, because it was configured to load the file under a different character set. Try viewing the file contents from the terminal:
cat the-vcard-file.vcf
EDIT: One more thing: Do not close the VCardWriter object. This will close the servlet's PrintWriter object, which you must never close!!
We have created an Outlook Plugin which (amongst other things) can be used to save Mail items in text form to a specific folder. However, the text of the resulting text file is encoded in ANSI and I would like to save it as UTF8. I have already set the Codepage of the mail item like so:
mail = (MailItem)objItem;
mail.InternetCodepage = 65001; // equal UTF8 encoding; see http://msdn.microsoft.com/en-us/library/office/ff860730.aspx
mail.SaveAs(filePath, olSaveAsType);
However, the resulting file is saved as "ANSI as UTF8" and all extended characters (e.g. in Arabic or Russian) come out as question marks.
Does anyone know how I can save the mail item in utf8?
Thanks a lot.
Cheers,
Martin
Instead of trying to set the encoding, try reading InternetCodepage and then using a System.Text.Encoding object to read the saved file into a string. You could then convert and re-save the string as another file in the encoding you prefer.
Alright. I thought this problem had something to do with my rails app, but it seems to have to do with the deeper workings of email attachments.
I have to send out a csv file from my rails app to a warehouse that fulfills orders places in my store. The warehouse has a format for the CSV, and ironically the header line of the CSV file is super long (1000+ characters).
I was getting a line break in the header line of the csv file when I received the test emails and couldn't figure out what put it there. However, some googling has finally showed the reason: attached files have a line character limit of 1000. Why? I don't know. It seems ridiculous, but I still have to send this csv file somehow.
I tried manually setting the MIME type of the attachment to text/csv, but that was no help. Does anybody know how to solve this problem?
Some relevant google results : http://www.google.com/search?client=safari&rls=en&q=csv+wrapped+990&ie=UTF-8&oe=UTF-8
update
I've tried encoding the attachment in base64 like so:
attachments['205.csv'] = {:data=> ActiveSupport::Base64.encode64(#string), :encoding => 'base64', :mime_type => 'text/csv'}
That doesn't seem to have made a difference. I'm receiving the email with a me.com account via Sparrow for Mac. I'll try using gmail's web interface.
This seems to be because the SendGrid mail server is modifying the attachment content. If you send an attachment with a plain text storage mime type (e.g text/csv) it will wrap the content every 990 characters, as you observed. I think this is related to RFC 2045/821:
Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email are
represented, in their "natural" format, as 8bit character or binary
data. Such data cannot be transmitted over some transfer protocols.
For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
data with lines no longer than 1000 characters including any trailing
CRLF line separator.
It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7bit short line format. Proper labelling
of unencoded material in less restrictive formats for direct use over
less restrictive transports is also desireable. This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field. This field has not been defined by
any previous standard.
If you send the attachment using base64 encoding instead of the default 7-bit the attachment remains unchanged (no added line breaks):
attachments['file.csv']= { :data=> ActiveSupport::Base64.encode64(#string), :encoding => 'base64' }
Could you have newlines in your data that would cause this? Check and see if
csv_for_orders(orders).lines.count == orders.count
If so, a quick/hackish fix might be changing where you call values_for_line_item(item) to values_for_line_item(item).map{|c| c.gsub(/(\r|\n)/, '')} (same for the other line_item calls).