Euro symbols entered directly in UTF-8 are junked on first edit, those encoded in entities are de-coded in the first editing round and destroyed in the second.
%u20AC - will be replaced by %u20AC on TMCE edit
€ and € will be replaced by %u20AC on first TMCE edit, by %u20AC on second
It looks as if the translator doesn't handle Unicode properly?
--
TWiki:Main/HaraldJoerg - 17 Oct 2007
This is not a problem of
TinyMCEPlugin per se. TWiki::urlDecode() is not working properly. I've come up with a patch and proposing on
Item4946. So please give it a try.
--
TWiki:Main.HideyoImazu - 28 Nov 2007
Unfortunately the patch doesn't help much. An Euro character (which, admittedly, should not even be present in ISO-8859-1) is now converted to € . I wonder how this will look like after some more edit cycles, since even a verbatim environment doesn't help. The entity
&8364;
is converted to an Euro character on first edit cycle, from there it goes downward as before.
Actually this isn't too surprising at least from the name of the subroutine: I have the Euro symbol in plain text, not in an URL. So any attempt to match
%([\da-f]{2})
as in
urlDecode
must fail.
--
TWiki:Main.HaraldJoerg - 06 Dec 2007
Addendum (again see
Item4946): If I use a site charset of utf8,
Hideyo Imazu's patch works fine.
--
TWiki:Main.HaraldJoerg - 11 Dec 2007
I have similar problem with our national character. I am using ISO-8859-2 and
TinyMCE is unusable with this behaviour. I tried aply patches from Item4946, but it not helped. I have TWiki 4.2RC2.
--
TWiki:Main.VladimirNavrat - 13 Dec 2007
See also
Item5128
I'm afraid nothing is going to happen on this without some help from users of other character sets in debugging and testing. It requires someone:
- who regularly uses a non-8859-1 character set
- who is able to run testcases
- who has enough knowledge of perl, JS and character set conversions that I am not stuck in the debugging loop
Any takers?
CC
Thanks to assistance from some testers, this is finally fixed I think.
CC