[TYPO3-core] RFC: Fix charset encoding in TYPO3 mails (not only direct_mail)

[Michael Stucki]

Hi Stanislas,

>> 3. The new function t3lib_div::encodeHeader() is mainly needed to find
>> email addresses which must stay 7bit in all cases. It splits the headers
>> line by line, preserves found email addresses with a special wrap, and
>> encodes all other parts.

You missed to add a comment for this. OK or not?

>> 4. The charset detection in class.t3lib_dmailer.php was written by
>> Bernhard (kb_mailcs). Works absolutely perfect but is not needed anymore
>> after this patch.
>>   
> I don't agree with the charset detection, nor with the getCharSet
> function. I wish for the caller to be able to specify to t3lib_htmlmail
> what charset to use. For example, the Direct Mail module fetches a page
> in order to build its newsletter.

Did you notice that the getCharset() function is overwritten in
class.t3lib_dmailer.php?

What it does is to parse the contents of $this->dmailer['html_content'] and
look for a line like this:

<meta http-equiv="Content-Type" content="text\/html; charset=...">

Thus, the charset definition of the fetched page is respected correctly. You
agree?

> The page is thus rendered as in the frontend. If config.metaCharset is
> used in the TS template applicable to the page, the page will be rendered
> with the charset specified by config.metaCharset. But your patch forces
> the use of the backend charset. The newsletter will be broken.

OK, so I can just add a 2nd check for config.metaCharset which (if set)
overrides the forceCharset setting.

Question: Should I use config.metaCharset or config.renderCharset?

> I also wish to be able to use 8bit as content-transfer-encoding as it
> could allow to transfer non-ASCII characters without using base64.

Right. I have seen that you added this in your patch. Since that is a small
change only, may I ask you to add this separately after my patch is in CVS?

>> Final notice: I have this patch working on many utf8 websites. It is
>> working absolutely perfect, so there should be no problems with this
>> patch.
> 
> If your backend is utf-8, try to set config.metaCharset = iso-8859-1 in
> the TS template of the page you fetch to generate your Direct Mail
> newsletter.

I think this mixture will already work because the charset is detected using
the above mentioned preg_match function. It will also work on forms because
class.t3lib_formmail.php overwrites the getCharset() function as well (to
respect the value of config.formMailCharset).

I think the only situation where getCharset does (currently) not work is if
you want to mail the contents of a website from within a custom extension,
and where this website uses config.metaCharset/config.renderCharset but not
forceCharset. Pretty trick I think ;-)

Correct me if I'm wrong, otherwise I will implement that and write a new
patch. But I'm still unsure about which of both config properties should be
used (metaCharset/renderCharset)?

> I will review the other functions in more details. Please note that the
> next version of Direct Mail will not use t3lib_dmailer. It has been
> completely imported in Direct Mail. My understanding is that it should
> probably be removed from the core.

I think so, yes. I'm looking forward to see the upcoming version of
direct_mail!

Regards, michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/