Bug #17292
closed
Ajax collapse in pagetree destroys extended iso-codes -> euro sign
Added by Thomas Murphy over 17 years ago.
Updated over 14 years ago.
Description
If I name a site "MON€Y MAKING MACHIN€" and click the collapse icon, the page will show as "MON?Y MAKING MACHIN?".
The Ajax script seems to return a different charset.
(issue imported from #M5600)
Files
What do you mean with extended iso code? If you're using iso-8859-1 there is no Euro sign. You could try and use iso-8859-15 or windows-1252.
I tried this. I noticed the same problem that the encoding did not work while using no "forceCharset" option because then it used "iso-8859-1" where there is no EUR sign. If you set "forceCharset" to "utf-8" it should work as expected.
Once utf-8 is on by default in 4.2, I will close this bug.
Benjamin, the code may not work only in utf-8 being default or not. It has to work with every character set TYPO3 supports.
Hey Masi,
you are right. I found the problem and fixed it.
This problem will be resolved with the changes of the AJAX interface.
Hey,
please see if the problem still occurs in the latest trunk version (or in alpha3 once released). It works for me in iso8859-15 and utf-8.
But what happens in eg iso88591-1? Both iso8859-15 and utf8 have a euro symbol. In other charsets it should be represented as an entity (so the browser will probably display it anyway).
This still occurs in latest trunk. I have following configuration here: A site created with an older trunk version (before utf-8 became default) and German umlauts and the euro sign are displayed correctly after loading the pagetree, but after expanding/collapsing the leafs, they are screwed up.
I suppose we have to set forceCharset to iso8859-1 when upgrading if it is not set. At least I don't see another way to move around this problem - not everybody wants to convert their old site to utf-8...
Hi,
ajax.php converts the ajaxresponse to utf8 by default unless you set
[BE][forceCharset] = whatever (e.g. iso-8859-1) explictily. Since 4.2 will default to utf8 this is quite ok.
Nikolas, this is not ok. The BE encoding is defined by $GLOBALS['LANG']->charset and must be observed. It is incorrect for any BE code to check the value of forceCharset to determine the BE encoding.
Hey masi,
totally, I'm gonna fix this ASAP in ajax.php with another RFC. Hopefully we're clean then...
Hey guys,
hope the attached patch fixes the problem.
Can i close this issue now?
Seems fixed to me. Just tried it out.
Also available in: Atom
PDF