Thought that, for reference, I'd add some of the things that is needed
when converting an existing app/database to utf-8 (utf8). Actually
altering the table definitions, and connection configurations does not
save data already inserted when the charset was set all wrong.
How to convert existing
Yeah, I got that the reason is linguistic in its origin. It is great
when trying to search a mass of text. But when you try to do a
matching search for an exact string it does complicate things a lot
when you still think that = really means exactly equal.
Doing WHERE username = 'myname' I (as a
Sorry for that. I used the familiar terminology from utf8_encode() and
utf8_decode() in php even though it is more a matter of interpertation
of data then encoding of data.
A am a bit shocked that it is a feature when å is the same as a in
MySQL. That sounds just plain wrong to me. If it had
A am a bit shocked that it is a feature when å is the same as a in
MySQL. That sounds just plain wrong to me. If it had been so for
utf8_some_special_ci, fine, but not for general (the default default)
collations. To me that would be like PHP saying (1 == 1.2) is true
because it is close
Hi,
I have started putting a project onto a rented production server
running a pretty standard Ubuntu installation AFAIK.
I have been able to fix some initial problems with charsets but one
thing I just can seem to figure out.
On my dev system
$this-params['form']['hello_text'] // in MySQL =
I'd say it's the other way around.
Text gets stored in some non-UTF8 format in the database (latin-1 most
likely), so it comes back as gobbledygook. When you explicitly force
the gobbledygook to be interpreted as UTF8, it's being morphed back
into what it was meant to be.
Check your
I'm inclined to agree. I had the same problem. All my MySql
installations default to Swedish, so need to be converted. Have a look
at this page:
http://ragrawal.wordpress.com/2008/02/15/dummys-guide-for-converting-character-set-for-a-web-application/
Be aware that MySql is 'utf8' whereas
Thanks for your replies.
Apparently this sees to have been the problem:
When the nothing was done at all to the charsets you could have stuff
working ok since whenever garbled characters were saved they would
ungarble when they were read out again. Tables were utf8 but not MySQl
itself.
Setting
You're mixing up a lot of terms and concepts here.
It's not about double-encoding, it's about interpreting the data. A
string 'ABCD' is not saved as 'ABCD', it's saved as 1101001001011001
(just pulling that out of my behind for illustrational purposes, no
guarantee for accuracy).
