>>
>> And BTW: MySQL automatically converts the charset, so you can give it
>> utf8 as input and it will store it as latin1 if the field is defined as
>> such.
Indeed. But that's fine. As effectively you are passing it a load of bytes in, and it's just returning them as is.
>>>> No. Any utf-8 characters already in there will be stored in a
>>>> weird
>>>> encoding. If you have no existing UTF8 characters in your data
>>>> then it would work.
>>>
>>> Ok, thanks... is there a way to test for existing utf8 characters? I'm
>>> assuming I don't, since this database has apparently always been in
>>> latin1 format...
>>
>> Only ASCII characters (0..127) are the same in all charsets. If you are
>> using other characters (like the german umlauts äöü) which are in the
>> 128..255 area, you'll get invalid utf8.
Yes - but when querying the database for that data it'll probably end up coming out right - as it'll be returned to you the same as what you entered it as (99% of the time) - as long as no one has done e.g. addslashes on the data and the unicode character doesn't contain the Byte 0x5a or whatever it is. (').
>> In other words: never change the charset in a mysqldump file.
>> If you really want to change a column to uft8, do it directly in MySQL
>> ("ALTER TABLE foo CHANGE bar bar VARCHAR(255) CHARACTER SET utf8 NOT
>> NULL").
Wouldn't this still require a dump of the database and reinsertion in order to get the stuff encoded correctly)?
I don't think MySQL can tell what is, and isn't a UTF8 character (can it)?
I think if you just change the table charset it'll still contain the invalid encoding as is.
I assume that changing the charset would just make a difference for future queries (e.g. it'll realise that £ or ö is actually one character and not 2 if you're doing a strlen operation within MySQL).
>>
>>> Last... what is *recommended* for postfixadmin?
>>
>> MyISAM for most tables, as created by setup.php/upgrade.php.
>>
InnoDB is better :-)
<round name="one">fight</round>
David.
|