• Do not register here on develop.twiki.org, login with your twiki.org account. • Use Item7848 for generic doc work for TWiki-6.1.1. Use Item7851 for doc work on extensions that are not part of a release. More...Close• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update. • Does this site look broken?. Use the LitterTray web for test cases.

Detail

What you need to have this bug:

Using not utf8, so e.g. iso-8859

Using Umlauts

4.1.2 ( heard that it is also happending on 4.2)

With the current version, i got problems with the ecoding. In details that means, editing a topic and adding umlauts, works and shows correctly. But on saving and editing that topic or simply going into raw mode and back ( by pickaxe ) it breaks when viewing the umlauts. Breaks means, umlauts are shown not correctly, seems like a wrong encoding.

I tried to debug it with the pickaxe mode and find out, that it must be the TML2HTML convertert. After just skipping the whole converter, i just returned the TML text in the _restTML2THML handler and the encoding still was wrong. After some tips of CDot, it seems like any content coming from TinyMCE, not depending what your endoding ( in the TWiki configuration ) is UTF8.

And thats where the bug is from. In the current version, there a commented line :

#_handleUTF8( $tml ); if not utf8? :Iam not sure what it was initialy for, but using it, uncommenting does not solve the problem just right away. When you look at the code, it just only decodes the content from UTF-8, when your twiki charset is utf8, what is, not what we need in our case. In our case, we always have utf8, not depending what you set in twiki, because thats the behavior of tinyMCE. So what i did to solve the problem was : lib/TWiki/Plugins/WysiwygPlugin.pm

So i decode the content with utf8 in any case. I did not touch the handUTF8 method as iam not sure, what is should be supposed to do in other cases.

So why i post this all. Iam not a guru on tinyMCE and not with all that encodings, but it worked for me. You guys should check wheather this is the correct solutions and more important, the right place to solve it.

Mayer, I'm sorry but I'm not longer responding to "it works for me" reports that leave me to do the bulk of the work. Our understanding of all the transforms and encoding assumptions is incomplete (as I'm sure you realise) and until we build up a complete picture, I can't be sure your fix doesn't break anything.

Having said that your proposed change does reflect some code I already have in my dev version but not yet checked in (no time).

Here's my current understand of what goes on. Assume a server configured for encoding X (it doesn't matter at this stage what X is):

Server sends edit page encoded using X to the client. This includes a textarea that has the topic content (encoded using X) embedded in it.

Client (e.g. firefox) loads the page, recognises the encoding, and builds the DOM. This implicitly converts the text encoded using X into unicode.

TinyMCE runs, and camps on the textarea, replacing it in the DOM with a div. It then fires a callback that invokes my JS.

My JS compiles an XHR using the content of the textarea (which was converted to unicode in step 2). The XHR uses URL-encoding on the data.