|
|||||||
| International characters in eMails | ||||
|---|---|---|---|---|
Category Unknown |
Affected Version 1.6 Stable |
Priority 5 - Medium |
||
Status Unconfirmed |
Fixed Version (none) |
|||
Submitted 09-22-2010 |
||||
|
||||
|
|
|
|
|
|
International characters in eMails
Hi,
Currently implementing osTicket, i'm facing some problems with french (and other languages) characters, like é , è , à , ... It seems to work correctly with the web interface, but not with the eMails... here's a small summary : Sending EMails The header (subject) of the email is announced as ISO but coded using UTF-8. Example : "Subject: =?ISO-8859-1?Q?[#121115]=20Message=20ajout=C3=A9?=" Fix : OST allways use UTF-8, but the pear Mail_mime default charset is ISO-8859-1 ... OST define the charset for body but not for the header... to fix, add the "head_charset" settings in class.email.php like that : Quote:
Receiving EMails Using POP3 collector For a message coded using ISO-8859-1 charset, the subject is truncated at the first accentuated character. The body seems to be correct. For a message coded using UTF-8 charset, apparently no problem. Using PIPE For a message coded using ISO-8859-1 charset, apparently no problem For a message coded using UTF-8, the message seems to be interpreted first using ISO-8859-1 charset, meaning that every accentuated char is displayed as two differents chars, example, "é" is replaced by "é" (the UTF-8 representation of "é" is =C3=A9 ) Of course, we cannot know in advance which charset will be used when someone send us a mail, and we cannot force anyone to use the same charset :) I've fixed the problem for the mails OST send, but i need some help to fix the incoming mails, preferably using the PIPE method... did someone know how to first decode the mail using the right charset (defined by the content-type header) before recoding it using UUTF-8 ? |
|
|
||
|
||
|
Thanks for your help.
Could you tell me what utf8_encode in pipe.php broke ? For me, if i apply only your patch on mimeDecode.php it seems to work fine, but if i remove the utf8_encode then every accentuated char is stripped... I will leave the utf8_encode and see further, but for now it seems to work correctly for me. |
|
|
||
|
||
|
Hmm. If it works for You, may be its OK. But on my server utf8_encode leads to utf8-text converted as iso8859-1 to utf8. May be it depends on some php options.
|
|
|
||
|
||
|
It's working, but i'm still facing a problem with some emails :
With EMail containing the ' character encoded like =92 (URL encoding ?) The message is truncated at the first occurrence of =92 I've not yet checked in detail, i think that the SQL security filter replacing every ' character could be executed before the decoding of the mail, and thus after the decoding the ' could be misinterpreted by sql ... if it's the problem, it could be a security problem, allowing SQL injections... |
|
|
||
|
||
|
It seems that the ' problem occur after the patch of mimeDecode... thus i reverted back, i've installed the latest official Pear mimeDecode (1.5.4)... but of course, the problem of UTF-8 encoded messages occur again... utf8_encode does not work correctly with allready UTF-8 encoded strings...
I've then modified pipe.php to replace the utf8_encode function with mb_convert_encoding and mb_detect_encoding: Quote:
It's not perfect yet, but it's much better... accentuated characters are correctly handled, the only detail is that the ' character is now stripped... i prefer that than a whole mail truncated... |
|
|
||
|
||
|
Thanks antarex - this fix worked for me as well.
I also don't mind the missing quotes if the whole message comes through either. Cheers. |
|
|
||
|
||
|
thanks for ur help it worked
technology |
|
|
||
|
||
|
Hi
Please help me with russian charset sent to script via pipe i sent HTML Code:
йцукенгшщз HTML Code:
ЪУеЫХЮЧлнк before i have problem with Russian totally, and i found solution here http://www.osticket.com/forums/showp...7&postcount=11 but now i receive different text to ticket |
|
|
||
|
||
|
Green,
if i try and use an é in a filename to be added as an attachment, that also fails. i guess a similar bug but with the symptom in a different place? |
![]() |
| Issue Tools |
|---|
Subscribe to this issue |