I am using Jhipster application email functionality to send mail on user creation. When sending mail in French the character like é is printing wrongly.
These characters are coming from standard messages_fr.properties file.
Obviously its encoding issue but both in email template html and java code we are setting encoding as UTF-8, which should display this correctly.
While debugging I found that in MailService.java class, content loaded by the SpringTemplateEngine's process method have already loaded the character wrongly before setting the encoding as UTF-8.
My code:
String content = templateEngine.process("activationEmail", context);
Looks like I know the root cause of it but as it is Spring's internal API class, I don't know how to fix this issue.
As Gael pointed I found that the exact root cause of issue is that STS is changing the encoding of .properties files to ISO by default. Changing the file back to UTF-8 is the solution of this issue. Thanks Gael for pointing to this direction.
Related
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.
I've been using Google Apps Email Settings API for a while but I came to a problem when I tried to insert aliases, signatures or any information with "ñ" or "Ñ". It adds garbage instead of those characters and it doesn't seem to respect the charset specified (utf-8) in the HTTP header nor the XML character encoding.
I have tried via my own python code and also using OAuth Playground[1] but it's been impossible to properly add the mentioned characters.
¿Any idea/suggestion?
Thanks in advance.
EDIT: It seems that the problem is not in the request but in the response. I have encoded it successfully in my code but it should be also fixed in OAuth Playground.
[1] https://developers.google.com/oauthplayground/
I have succesfully called Google API client methods using UTF8-encoded strings, so it is definitely an issue with your Python setup.
I would workaround this issue sending Unicode strings instead of UTF-8 encoded:
u'literal string' # This is unicode
'encoded utf-8 string'.decode('utf-8') # This is unicode
EDIT: Re-reading your answer it seems that you are making raw HTTP calls with hand-made XML documents. I can't understand why. If it's the way you want to go, take a look into Emails Settings API client code to learn how to build the XML documents.
I'm using spring MVC, and I've got a problem in a webpage with a table that is showing some records that could have some special characters as Á, ñ, #, #, etc.
In the database they are stored ok. While debugging, it's taken them right from database. But when showing them at the JSP, it's replacing the special chars with "?" (question marks).
I can solve this issue with the following config at my web.xml:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<page-encoding>UTF-8</page-encoding>
</jsp-property-group>
</jsp-config>
But when I set this, then there're some problems with functionalities that were working before: the files I upload to my web are not encoded properly, and there are some "hardcoded" properties in my jsps like
<option value="name">Seleccione tipo de ordenación</option>
which are not properly written.
With this jsp-config out then they (this option and the file upload) worked ok.
So, if I set this jsp-config property, then it fails with things that were working before.
Any help? Thanks!
Well, finally, it seems that I'd been fooled :)
I've been told that the name was stored properly into the database. But, actually, it wasn't. The problem was when decoding the file when the user uploads it.
The file itself is a ZIP file which I have to decompress with Apache commons compress. I was opening the file with Cp437, which was working well when the file was created in an english Windows system. However, when creating the file in an spanish Windows system, it failed when opening the file.
Changing the Cp850 charset as the following has solved the problem:
zipFile = new ZipFile(f, "Cp850");
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.
I have a problem with cookie encoding. The cookies have some French character inside them. Firefox sends them back correctly, but it seems Chrome has problem with sending them.
Any idea why it happens?
It seems Chrome doesn't support Unicode in its cookies :-/
The correct solution is to
convert the french string to UTF-8 and then
do percent encoding (also known as URL encoding) See http://en.wikipedia.org/wiki/Percent-encoding
This way you can submit any Unicode string via Cookie.
In C# there is a function that does exactly these both things: System.Uri.EscapeDataString()