Hi,
when I use the HTML-Editor in forms and save German Characters (e.g. ?, ?, ?) in MySQL Table of type “text” these characters were replaced by some strange characters.
In case it matters: Project Language is already set to German.
What do I have to change?
Thanks for your help.
Hi,
change / check your client encoding and set to UTF8 (edit connection, bottom right => Advanced).
(In German: es gibt da mehrere Stellen zum eingreifen: Collation der Datenbank, Collation der Tabelle, Client Encoding etc. Ich w?rde es mal mit letzterem zuerst probieren … Einen der besten Artikel, den ich zu diesem Thema kenne, ist dieser. Dort geht es zwar nicht um Scriptcase, aber die Umlaut- oder Sonderzeichenproblematik ist ganz gut dargestellt.).
Hi,
thanks for your answer.
I spent several days to figure out the root cause. I never managed to get same results in database for text fields and HTML Editor: Once German characters worked for text fields but not for HTML Editor (even though both have same DB type and collation) and once German characters worked for HTML Editor but not for text fields.
The solution was pretty easy: Downgrade to ScriptCase 7.0.
After restoring my old SC7.0 Image and databases everything worked perfectly.
Seems I have a similar issue. Everything is set to UTF8 (client encoding, DB collation on table and fields, and encoding in project settings) and when I check the source code it also shows encoding=UTF8. Still, none of my spanish special characters gets displayed correctly, they all show up as question marks. And when I do save data back to the database they get replace with even more weird character combinations.
This was working properly before I upgraded from 7.01.0013 to 7.0.0014.
Oh, and it only affects the production environment, works fine in development.
[QUOTE=fokka71;20665]
This was working properly before I upgraded from 7.01.0013 to 7.0.0014.
Oh, and it only affects the production environment, works fine in development.[/QUOTE]
One idea: your dev environment works at PHP 5.4 and your productions environment nor with PHP 5.3?
both run php 5.4 (prod 5.4.19 and dev 5.4.16).
Prod is Ubuntu 12.04 and Dev Mac OSX 10.9
I already reinstalled everything twice on production but whatever I do, the client encoding in the settings doesn’t work as expected. In both, prod and dev, I’m now connecting to the same database (on ClearDB) with client encoding UTF-8.
When I then check the server variables with: $re = mysql_query(‘SHOW VARIABLES LIKE “c%”;’)or die(mysql_error());
I get these results:
// result from Dev (Mac OSX)
character_set_client: utf8
character_set_connection: utf8
character_set_database: utf8
character_set_filesystem: binary
character_set_results: utf8
character_set_server: latin1
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/
collation_connection: utf8_general_ci
collation_database: utf8_general_ci
collation_server: latin1_swedish_ci
completion_type: NO_CHAIN
concurrent_insert: AUTO
connect_timeout: 10
// result from Prod (Ubuntu 12.04)
character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8
character_set_filesystem: binary
character_set_results: latin1
character_set_server: latin1
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/
collation_connection: latin1_swedish_ci
collation_database: utf8_general_ci
collation_server: latin1_swedish_ci
completion_type: NO_CHAIN
concurrent_insert: AUTO
connect_timeout: 10
I sure don’t know anymore where else to look.
regards,
Volker
I might have figured out why it’s not working but I have no idea how to fix it.
When I check the session variable [‘scriptcase’][‘glo_database_encoding’] in my dev environment it tells me correctly utf8.
In prod the session variable simply doesn’t exist! And I double and triple checked that it is set in the connection properties.
As the variable is not set, it can’t be passed to the connection string so it uses latin_1 as default.
Could that be it? And if yes, how can I fix this?
regards,
Volker
Can you check this settings …?
Edit: try set [‘scriptcase’][‘glo_database_encoding’] manually to “utf8” …
yeah, that was my thought as well, and setting it manually works.
Leaves just the open question why it doesn’t work without that manual hack?
Gruss,
Volker
Hi,
right now I have the same problem.
How and where can I set [‘scriptcase’][‘glo_database_encoding’] manually to “utf8”?
Vielen Dank,
Frederic
so now I found out, that I did not configured the ‘advanced’-setting when configuring the database setup in the production enviroment.
the encoding was set to ‘latin’, I set it now to ‘utf8’ and everything is working fine.
But: use a private window in firefox for testing, otherwise firefox cached the parameters wrong.
Hope that will help sombody,
Frederic