TYPO3 Core

i mean mails that go via mail form content object

What do you mean by "formMailCharset = iso-8859-1"? config.notification_email_charset does not affect (per design) mail forms.

Mail forms do always use the charset of the web page.

there are several lines in class.t3lib_formmail where [config.][formMailCharset] is used.
i thought that this option is used for mailform messages.
am i wrong? what is it for?

You're right. The online version of TSref doesn't know this config.

But what exactly happens? I'm not surprised that the data is in utf-8. There is no charset conversion code in this class or in the base class (t3lib_htmlmail).

What does the header of the mail show? utf-8, not what you want but in sync with the content, or iso-8859-1, the desired charset, but wrong because of the data.

you see. our company site in utf-8. and there are several mailforms that send messages to our internal services. but these services works in iso-8859-1.

i have digged into core and found formMailCharset. so i have set up it: formMailCharset = iso-8859-1.
But headers of messages remained as utf-8 :(

i found that function useQuotedPrintable is called before class.formmail processes formMailCharset. so mail charset is always depends on metaCharset(or forceCharset).
but then question: what is $formMailCharset for?

in my case i added to t3lib_formmail::start($V,$base64=false) following:

$this->useQuotedPrintable(); //again. to pick up formMailCharset

and additional decoding of $V to $formMailCharset in case if $metaCharset != $formMailCharset

formMailCharset probably was intended to set the header of the mail.

There is a pending patch which may solve the issue of the header. But it won't help. Even if the header is set to iso-8859-1, the data will remain in utf-8. So things will get worse.

I'll see if I can get some charset converions into this class. But don't hold your breath. It probably won't make it into 4.0.1. Be ready to use a patch.

"formMailCharset probably was intended to set the header of the mail."
yes but it doesn't work. headers is set up before formMailCharset processed.

"Even if the header is set to iso-8859-1, the data will remain in utf-8. So things will get worse." i said the same :)

as i said before i use my own patch so it works for me. so right now it is not critical and i can wait until 4.0.1 ;)

What does your patch? How do you handle the necessary charset conversion.

Please upload the patch (diff -u)

Dmitry, please upload a diff of your changes.

Code in SVN now honours formMailCharset (and metaCharset) and does also a charset conversion so the mail will be tagged and sent in the desired charset.