MySQL encoding (was: [TxMt] mysql bundle, password issues, utf8 encoding)
chris at improbable.org
Wed Jul 18 21:26:12 UTC 2007
On Jul 18, 2007, at 5:42 AM, Allan Odgaard wrote:
> Your fix (for the ideal setup) breaks this -- if the majority of
> servers out there as the proper encoding set, it seems we should
> take the fix, otherwise I think a more practical solution would be
> to ensure that we set the same encoding as the server use, and let
> the user configure a per-connection encoding, which we then convert
> to ourself (I believe this is what CocoaMySQL does).
Unfortunately, I think you're right to expect things to break. I know
about this for the same reason as I've flushed out a fair number of
bugs making things pure utf8, including a few
The naive patch does meet the "Everything is utf8" goal but can't
help with improperly encoded data. One approach might be to "SELECT
@@character_set_client, @@character_set_database" and require the
user to specify the desired encoding if they don't match since that's
probably a reliable check for encoding problems.
One other approach involves something I've been thinking about for
awhile: mysql has an existing way to specify the database options -
the .my.cnf file. I originally was thinking about modifying the code
to use the default username/password from that file if the user
hadn't configured a value and it occurs to me that we could check for
"default-character-set=utf8" in the mysql section of that file,
probably in conjunction with either hostname=localhost or the
existence of --host/--database options which match the target database.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2423 bytes
Desc: not available
More information about the textmate