I am trying to include words containing a diaresis (particularly "ë" in messages through PHPMailer, but am getting "ë" in the emails.
I have included the following right after instantiating my class:
$mail->Encoding= 'base64';
$mail->CharSet = 'UTF-8';
The character encoding appears correct when I preview it in a browser:
But when I view it in gmail, I get junk:
I have also tried running the content of the message through iconv, mb_convert_encoding, and even str_replace, all to no avail.
What can I do to make sure that characters like this show up correctly in emails sent via PHPMailer?
Why on earth are you using such an ancient (from 2012!), buggy & vulnerable version of PHPMailer? Update now. Also your images are broken.
Aside from that, $mail->CharSet = 'UTF-8'; should be all you need, though you do also need to be sure that you are actually feeding UTF-8 content into it, so check your sources. You don't need to set the encoding at all - in fact you're more likely to get marked as spam if you base64-encode message bodies.
Related
I have a concrete5 site, which uses 'designer content' an add on available via their market place.
Our clients site requires the use of macrons for their language.
Now this is fine throughout 99% of the site, whether hard-coded html or via a content block etc. However, when macrons are used inside a block created with 'designer content' the macron is replaced with a "?"...
Can anyone help?
Unfortunately this site wont let me post an image to help you see whats going on due to my 'low reputation'....riiiiight thats helpful.
Thanks in advance!
usually the apparition of question marks "?" instead of certain characters is the sign of a charset coding problem. With C5 you should be using a generic UTF8 encoding however if your database table was set to use a different charset or if your php settings are set to a different charset, then you will get those weird characters.
You should start with your php.ini and set the charset to utf8
If that doesn't fix the problem, check this thread, it has a useful script to use to fix the database
http://www.concrete5.org/community/forums/usage/utf-8-or-unicode-problems-preventing-corrrupt-fonts-on-the-front/#52300
Be aware however that if content was saved while the charset was not correct, you may discover that the content still looks weird and you will have to insert it again AFTER having set the correct charset.
On IE when i try to browse the rest apis, i am getting a application/json response instead of api (text/html) response (Returns html response on firefox). I am using django restframework 2.2.5 for this purpose.
I read through the documnets and understood that in order to overcome the problem of broken headers for IE we need to use TemplateHTMLRenderer explicitly in the view, so i have added the following to the class definition of my view but still i am getting a json response. Am i not doing it correctly or i am missing something else?
class CustomReports(generics.GenericAPIView):
`renderer_classes = (renderers.TemplateHTMLRenderer)`
Can you please help in fix the problem so that i get html response in case of IE as well?
Which version of IE are you using? I believe newer versions of IE should send correct Accept headers.
I probably wouldn't bother trying to fix things up to work around IE's broken behavior, but instead just make sure that you're including format suffixes in your urls. Then you can simply use the .api suffix to see the browseable API, or the .json suffix to see the plain json.
Eg instead of http://127.0.0.1:8000/api-root/, use http://127.0.0.1:8000/api-root/.api.
I use the latest CI version. In config.php:
$config['global_xss_filtering'] = TRUE;
I can't change this.
I need to save adserver tags (will stored in files, not DB), which contains also Javascript. So with this setting I cant save the adservertags, CI or the input filter removes some parts of it.
My first idea was to encode the adservertag with base64 in the client and then on ther server decode it again, what dou you think?
Sounds like a plan.
Except there is no native way to base64 encode on the client. However, a friendly fellow on Stack-O has solved this for you already: https://stackoverflow.com/a/246813/183254 Be sure to share an upvote for them.
I have a problem with an attachment's name. When I call the site on google chrome it returns the file with the right name and extension. I tested it with internet explorer and it works fine too. The issue lies with only Firefox. I call the site and it returns the first word on the file title and no extension.
For example if I wanted a file called "My report.docx" it turns a file called "My". I Googled around and it turns out this is a common issue with people because browsers read the headers differently. They said the fix is to quote the file name:
Content-Disposition: attachment; filename=My Report.docx
is now: (note the quotes)
Content-Disposition: attachment; filename="My Report.docx"
However, that did not work for me.
On chrome it returned "My Report.docx" (actually with the quotes). Firefox returned a odd file that had the proper extension and proper name and no quotes yet it could not be executed. It was the proper file size, proper extension, and proper name yet it could not be executed. Also it returns a space before and after the file name.
I know this is a very old question, but I was recently having the same problem. The solution is to either
Encode your filename per RFC2184 or,
If you don't have special characters in your filename, quote it in the content disposition string.
Since you've already tried 2, you could try using 1 and seeing how that works out.
Usually I use the ContentDisposition class to generate my header for me:
Dim contentDispositionHeader = New Net.Mime.ContentDisposition() With {.FileName = filename}
Response.AddHeader("Content-Disposition", contentDispositionHeader.ToString())
Hope this helps.
This should work as expected, here's another SOq with the same problem:
Downloading a file with a different name to the stored name
and also the Mozilla page (I guess you were referencing this one):
http://kb.mozillazine.org/Filenames_with_spaces_are_truncated_upon_download
I don't know the specifics of your server side code, but here are some things to confirm / try:
If you have PHP available at the server, can you try the code from the first link above? If not, you can probably find something on the Net in your language of choice. That way, you can confirm whether the issue is in your code or somewhere else (server setup, browser, etc.)
Is this happening on other client machines (i.e. where you try the download from) or only on that one? You might want to try others to confirm.
Is this working fine in IE / Safari or some other browser? You can even try doing it with wget or curl from the command line or something like that.
Are you also providing the Content-Type header correctly?
Can you try downloading some other file or a file of a different type, e.g. a .png or a .xls? In fact, probably the easiest would be to try a plain text file (text/plain) and then take it from there.
Hope this helps.
My project is based on CodeIgniter, but I guess this question isn't about it at all.
First, I have enabled query strings and a search function. Search string passes to the “searchterm” variable and when I pass it through the form, it works fine and looks like:
http:// local/home/search/?searchterm=testtesttest
Okay, now when I input some cyrillic string in a search form, it works fine as well, the URI would be for example:
http:// local/home/search/?searchterm=привет (in chrome) or
http:// local/home/search/?searchterm=������ (in IE, Opera etc.)
Two above cases work fine, BUT WHEN I enter the CYRILLIC search string directly from the address bar (for example, in Opera or IE) it doesn’t wanna search anything. $_GET[‘searchterm’] is empty, and as for QUERY_STRING, it is something like searchterm=������ (all data from profiler).
I urldecode my string from the controller, but it somehow doesn’t work. I also tried some iconv() cases, from what I’ve googled, but they also didn’t work.
So the question is why all other browsers except chrome doesn’t retrieve CYRILLIC $_GET variable from the address bar if it was entered from there? Passing through the form everything works fine.
Thanks in advance, guys. Hope for your help.
P.S.
I've also found:
%D0%BD%D0%BE%D1%87%D0%B0%D0%BB%D0%BE
this is passed from the form, accept-charset is set to UTF-8. In that case, as I said, everything works fine. And:
%ED%E0%F7%E0%EB%EE
this comes in the address bar when typing the string directly inside the address bar. So I guess every browser changes my cyrillic symbols into something strange... I don't know :(
Don't forget that with Chrome everything works fine! Maybe it's because by default this browser doesn't encode cyrillic symbols in wrong way like other browsers.
I'm guessing part of the issue here is that you are using UTF-8 characters in the URL ... You can setup PHP to use UTF-8 by default from within the php.ini file or by adding ini_set('default_charset', 'UTF-8'); somewhere in your application, (I add it to the root index.php file within CodeIgniter if I can't modify the .ini file).
I tested both Japanese and your example in Firefox and Safari quickly and they both displayed the correct strings. More information about setting up Apache/PHP for UTF-8 can be found in this excellent guide.