MySQL encoding (was: [TxMt] mysql bundle, password issues, utf8 encoding)

[Chris Adams]

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.

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://lists.macromates.com/textmate/attachments/20070718/c66c5bb9/attachment.p7s>