UTF-8 translate lang. in FCKEditor

I am having similar problems, but not related to text translation. Here's the situation. I have upgraded to 1.2.4 - ASP, which has solved numerous issues. I use the editor in two internal apps, one with a SQL Server backend, and the other with Access.

The problem is with the Access-based app. 95% of the time, submitting fckedited text to the database is successful. In the other 5%, though, the database gets corrupted. I can usually restore the database, but the html text is lost.

Here is one scenario. A user opens up an existing doc (from the db) in the editor. The original source doc was from Word, and when prompted, the text was cleaned up. In edit mode, the user adds a couple of extra line breaks, some text formatting, and removes an extra bullet (li). On submit, the "search key cannot be found" error results, meaning that the row has been corrupted.

Before writing to the database, I both replace several known illegal characters, and then HTMLEncode the scrubbed content.

I never have this problem with the application running on SQL Server. I have a sense that it's a non-printing, binary character at fault. How can I determine what non-printing characters are passed by the editor for search/replace functions???

Any suggestions would be appreciated.

Paul

I have the same problem, outputting the variable with the text to the browser doesn't give any problems, but outputting it to the editor does, it looses the encoding.

So any help would be appreciated,

Kind regards RObbie

Matt,

I verified that fckeditor.html was, in fact, set to "text/html; charset=utf-8" and it was. The only other HTML file in my app is fck_about.html - a help file, not a forms-based file. In the header of the ASP file, I also added:

Response.Charset = "utf-8"

Neither prevents the row from being corrupted on edit.

You say you are using ColdFusion and MySQL. I think, perhaps, this is actually a Microsoft encoding problem. My data is stored in Access. I also manage sites on SQL Server. I think Access does some special encoding to unicode/UTF character sets that causes the row to become corrupted on edit. (We have similar issues with a completely unrelated Access export to Oracle.)

Although I will eventually migrate my Access app to SQL Server (which works fine, btw), it would be nice to know if anyone has found a solution for Access.

Thanks,
Paul

When I originally tested Unicode compatibility I ran it on *two* platforms, with Access being the other one, and they both worked. In ColdFusion you have to use a special driver (CF uses jdbc and not odbc) to get Access to support Unicode. For that matter, mySQL requires a special connect string as well. Since I can get Access to work in ColdFusion and you can get FCKEditor to work in SQL Server I would guess this points to your datasource connection as the culprit.