|
From: Christian B. <pos...@cb...> - 2012-01-16 17:10:07
|
Hello, Am Montag, 16. Januar 2012 schrieb David Goodwin: > >> 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, it's returning them in the charset of your connection - which you can influence with SET NAMES ;-) (And you really want to read http://mysqldump.azundris.com/archives/60-Handling-character-sets.html which I already mentioned yesterday.) > >> 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. MySQL _does_ a charset conversion when you ALTER a column from one charset from another (if the latin1 column contained a latin1-"ö", it will contain a utf8-"ö" after changing the column to utf8). This of course only works if the data in the original encoding is correct - you can't expect valid output data if you provide broken input... ;-) (Actually, it's a bit tricky to _avoid_ the automatic charset conversion, for example if you accidently stored utf8-encoded stuff in a latin1 column. IIRC the only way is to change the column to a "binary" varchar and then to utf8. Or of course the hard way of replacing the correct[tm] file in /var/lib/mysql/ - but you shouldn't do this at home ;-)) > 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). The client will not even notice a difference if the column charset is changed. (Except if it tries to store a character that is not available in latin1, of course.) > >>> 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> <round name="two" type="shoutmatch">Even if I assume your statement is true: we don't use the features that makes it better, so there is no difference for us ;-) And MyISAM supports fulltext search, which InnoDB doesn't...</round> <additional_punch>If you implement transaction support everywhere (with the things from my last mail in mind), I'll happily switch all tables to InnoDB ;-) </additional_punch> Regards, Christian Boltz -- Früher mußte man den Müll heimlich im Wald verbuddeln; Heute gibt es EBAY :-) [Axel Lindlau in suse-linux] |
