you haven't noticed this issue probably because browsers know how to handle double encoding.
but clients and dumps and everything else that will try to work against that data won't.
All the data inputed by the user via the forms is being converted to utf8 (with no relation to database at this point) because of the utf8 meta tag which is telling the browser to convert it during the post.
and you can test it yourself:
input a foreign language text (that one of you guys at development know) and try to view the data in one of the free mysql clients and you'll see it as gibrish text.
and then if you're still not convinced, the only way to test if it's true utf8 is to look at the hex value.
do a SELECT hex(columnName) on one of the columns, copy the text and paste it into a good hex decoder such as this one: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder - http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
(don't forget to change the input type to hex on the combo box)
and you'll see it in gibrish too.
then try submitting a form on the forum after making the addition i suggested to the connection string and try the process again. you will see the words correctly this time on the mysql client and the hex decoder.
this is causing issues for foreign languages because we can't backup the DB to a dump file because all the text is garbled, and also since it is double encoded, it takes much more space in the varchar column so for example a column with a limit of 70 chars will only be able to contain about 20 chars and then cut the rest.
Topic Options
Post Options
Thanks(0)
