TYPO3 Core

I forgot to mention that I'm using the version distributed with the Typo3 4.2 release on Firefox 2.0.0.3.

if you deactivate t3editor and just use the normal textfield the "+" sign disappears directly when saving.

I can't confirm c0021528. For me the "+" saves fine if I disable t3editor.

Michael, do you just click on deactivate t3editor (under setup field) - like I did or did you deinstall it? When deinstalling it the problem is gone in my editor too and saving works again.

Sorry Susanne, I really didn't get what you wrote here. I'm completely uninstalled t3editor to make it work.

Sorry, should be learning some better english.

I meant:

deinstalling t3editor = works
deactivating with checkbox = doesn't work but you see the "+" disappearing right away when saving

this issue only happens when not using UTF-8 in BE
it's somehow related to 0006827
for this i substituted "encodeURIComponent" with "escape" when charset is not UTF-8.
"escape" encodes umlauts (äöü) very well, but don't encode "+"

Unfortunately "+" means " " (space) in URL-encoding, so all "+" signs get lost.

i'de made a patch which fixes this

the attached patch should fix this issue.

the initial problem was introduced by #6812

When the backend is not in UTF-8 (using foreCharset), it's delivered in ISO-8859-1. Unfortunately prototypes Ajax.Request does not respect this, but always uses utf-8 for sending content.
This caused e.g. umlauts to broke. To avoid this problem i overwrote the javascript function "escapeURIcomponent" with "escape". On the first look this seems to solve the charset problem, but i didn't notify, that "escape" does not url-encode "+".

A "+" in an URL means " " (blank), so when saving the code, all "+" get lost (as reported in this issue!)

A better solution than this "escapeURIcomponent" / "escape" workaround, is to handle the charset thing on server side (PHP).
The attached patch removed the non-working workaround and uses the new ajax.php-script which handles ajax.requests for the BE.

It
- retrieves the code,
- decides on which way it's got to be processed (for the moment only "Template / tx_templateinfo" is implemented)
- convert the posted content to the correct charset if needed,
- and save the code like the normal form submit would do.

Please test the patch.
i'll post it in the core list, as soon as i get feedback.
So it can be fixed for 4.2.1

Thanks for reporting!
and thanks to Dmitry, Masi and Benni for your hints!

i found out that the TYPO3-api offers methods to convert strings from one to another charset.
i adjusted the patch to use them instead of calling "iconv".

Perhaps it is sensful to handle the encoding issue globally in ajax.php.
So i opened a new issue: #8591

if the ajax.php handles encoding correctly, the t3editor-php-code does not need to take care of. Then i would adjust this patch again.

Patch attached

Summery:
Problem/Background:
Posts in Ajax.requests (prototype) are always UTF-8 encoded, but they are expected to be encoded like the backend is (iso-8859-1 by default).
This caused special chars to get mixed up (happes in shortcut menu and in the t3editor)

I an earlier patch i introduce a workaround for this charset problem. In this patch i had replaced the javascript function "encodeURIcomponent" by "escape". Now the special char gets encoded correctly, but all "+" became " " (space) when sending them by Ajax.request to the server. (This is because a "+" means " " (space) in url encoding, and "escape" does not handle this)

Because of this issue the t3editor now uses the new "ajax.php/class.typo3ajax.php" instead of sending the content directly to tstemplate/ts/index.php. So the workaround "encodeURIcomponent = escape" should be removed from the javascript.
    With the patch for #8591 the "ajax.php/class.typo3ajax.php" detects the content charset of the ajax request and convert all post/get to the charset used for the backend.

How to test/some test cases:
    open a setup or constants in the t3editor
    type some code
    use some special chars and +
    save the code by clicking the save icon or hit CTRL-S
    scroll down and click "edit whole record" 
    check if all special chars are ok

the saving procedure is completely rewritten, so you should test also:
    if saving works correct if you have more than one template on one page (mutible +ext templates)
    saving different templates on different pages
    disable the t3editor and save the code (e.g. with special chars again)

Note:
    This patch really depends on the patch for #8591
    Do not test/commit without it.

new, updated patch attached