Freeform and double-byte (Japanese) characters
Development and Programming
I am using the Freeform module to enable anonymous clients to to write to us and mail us files. Files are first anonymously uploaded to a folder on the site, followed by sending. A separate confirmation email is sent to the anonymous client.
I am on EE 1.6.6, with the Default Character Set set to utf-8 in System Preferences -> General Configuration.
I have two issues:
Some clients have complained about text being garbled in the confirmation email text. After some testing with my email software (Apple Mail), I could not reproduce the problem. Is this an isolated case of clients not setting up encoding properly on their mail client?
Although confirmation email text seems to be displayed properly, filenames containing Japanese characters appear garbled. This problem is generalized in the emailed file attachments we receive. However, through the Freeform module CP on EE, filenames are displayed correctly.
How can the name of attached files containing Japanese (double-byte) characters be correctly displayed in emails? I tried changing the email settings in the EE CP to “iso-2022-jp” or “7bit”, but no effect on filename characters. Is this something I can change in the EE CP? on the Server? Do I need a Japanese language pack for EE or something similar?
Thank you for your help.
Moved to Modules forum by Moderator
Greetings Nicholas:
Since Freeform is a third party module by Solspace, your best bet is to give the good folks over there a shout on their forums
Regards,
-greg
Greg, thank you for your answer.
I’m not sure there is a way to change the character set in FreeForm yet. If it is not possible, can other (or a combination of) EE modules/extensions achieve the same functionality as FreeForm?
I would need to do this to enable iso-2022-jp support in emails. Anonymous users also send attachments. Does the EE Email module support attachments?
Thank you.
Nicolas,
The EE Email module does not support attachments. The Freeform module seems perfect for you though. I see you have exhausted the thread on the Solspace forum.
One thing you could try.
Seeing as the Charset overide for the email module is to actually override the template charset.
Try changing the charset of the template where your form resides to iso-2022-jp
Sounds like a good idea, but how would I do that?
Although the charset option doesn’t seem to be part of the Freeform module, could it still work? If not, how do I change a specific template’s charset in the CP?
Thank you
Nicolas,
You can change the charset of a template/html page by adding a meta tag to your header.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html >
<head>
<meta http-equiv="Content-type" content="text/html; charset=iso-2022-jp" />D’Oh, yes, you’re right. Conditional tags based on URL segments (in my case) may give it a nice touch, too. Let me try it out and tell you what I have found.
I just changed the charset to iso-2022-jp, but now the site text is all garbled. I set it back to UTF-8.
I changed the email encoding in System preferences -> Email configuration, to iso-2022-jp, but messages are still garbled. However, the full email header mentions
Content-Transfer-Encoding: 8bit
I think this has to be 7bit to work with iso-2022-jp, which is 7-bit encoding. How can I change the “Content-Transfer-Encoding” setting? php.ini?
Nicholas, have you asked your host for a bit of help with this?
I remember asking my host about the encoding of my MySQL database (latin1) in the past, but as long as I export with the –default-character-set=latin1, the website, set to UTF-8 in EE, showed fine.
I didn’t even know that this is a host-side problem. What should I ask them, or specifically, what exactly am I looking for?
Nicolas,
Can you try one more thing. Make you your email is set to plain text and not HTML
CP Home › Admin › System Preferences › Email Configuration
and turn off HTML here
CP Home › Modules › Freeform › Templates
See if that makes a difference.
When you say the filename appears garbled. Is the name of the file attachment included in the email or the actual file attached to the email?
Already tried to have everything in plain text, and I get garbled text in my emails. Here is what I heave in the plain text email header:
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 8bitI’m pretty sure “Content-Transfer-Encoding” has to be 7bit.
As for the attachment, I received mixed results after changing the encoding in Email configuration. From memory: UTF-8: OK text (for me, but not others), garbled attachment iso-2022-jp: garbled text, garbled attachment Both “UTF-8” and “iso-2022-jp” in the Encoding field in the EE CP (I think that’s not allowed): garbled text (for some clients), OK attachment.
The name of the attached file is garbled. If the attachment is downloaded, the filename remains garbled.
Edited to change response. 😊
Please update to the most current version first.
The current version is 1.6.7 and the build is 20090320.
Let’s have you try modifying core.email.php, line 1080 to:
$h .= "name=".$this->prep_q_encoding(basename).".$this->newline;Assuming that q encoding works in that header it should be fine with UTF-8 after making this change.
Can you test it for us and let us know what happens? Thanks in advance.
I’m on 1.6.7, build 20090211. Has this problem been fixed since?
Line 1080 is empty, and adding the above code gives me this error:
Parse error: syntax error, unexpected T_DEC in /my/path/system/core/core.email.php on line 1083
So I tried replacing
$h .= "name=\"".$basename."\"".$this->newline;to
$h .= "name=".$this->prep_q_encoding(basename).".$this->newline;and I get the following error
Parse error: syntax error, unexpected T_STRING in /my/path/system/core/core.email.php on line 1068
Japanese emails commonly need iso-2022-jp, 7bit. Although some clients may read a UTF-8 email without any problems, if the email transits through a 7bit-only server, the UTF-8 email text will be garbled.
Is there anyone else having this problem using asian languages?
Here’s something else I noticed: My Email module version is 1.0. Maybe my upgrade did not overwrite the module to 1.1?