mysql: unknown variable 'character_set_client=UTF8'

刚进公司，在使用mysql的时候遇到一个问题。

后来看了看Mysql这个目录下有一个my.ini文件

[client] 
character_set_client=UTF8  
[mysqld] 
# set basedir to installation path, e.g., c:/mysql 
basedir=d:/mysql 
# set datadir to location of data directory, 
# e.g., d:/mysql/data or d:/mydata/data 
datadir=d:/mysql/data 
character_set_server=UTF8 

这里设置了mysql的编码,因为网站所有网页使用的都是utf-8编码。为了方便和统一，故设置这个选项很是有必要。
在网上查找了下相关的资料，了解到这个是mysqlbinlog的一个bug。 既然client选项组里允许通过
default-character-set选项设置客户端编码，为何自带的工具mysqlbinlog却不认识这个选项？
在这里即使不认识，那也用不着直接出错而退出运行，若是不认识这个选项那只要略过此选项
（能给出个notice提示下不认识此选项则更好）继续运行岂不更好？

尽管如此，要解决这个bug的方法还是有的，

一种方法是使用：

loose-default-character-set=utf8

loose-选项,loose为宽松的, 散漫的, 自由的意思，在选项前加了loose-，则当程序不认识此选项时会略过此选项，
并给出一个警告

/mysql/bin/mysqlbinlog: unknown variable 'loose-default-character-set=utf8'
....(注：后面跟着的是日志内容)

另一种方法，我们使用mysqlbinlog查看日志的情况并不多，一般都是临时性的。我发现在使用mysqlbinlog工具查看
二进制日志时会重新读取的mysql的配置文件my.ini,而不是服务器已经加载进内存的配置文件。
也就是说只要修改并保存了my.ini文件，而不需要重起mysql服务器，则使用mysqlbinlog查看时修改后的my.ini配置文件
对mysqlbinlog而言已经生效。所以这里可以使用此方法：把client选项组中default-character-set=utf8选项屏蔽掉，如

#default-character-set=utf8

然后运行mysqlbinlog工具，则不会产生任何问题了。当然记得在不在使用mysqlbinlog工具时，把#default-character-set=utf8
选项恢复为default-character-set=utf8

若是在脚本中使用mysqlbinlog工具有此问题，则最好使用两份配置文件，一份是已屏蔽掉上面选项的，一份是没有屏蔽掉的。
在使用mysqlbinlog工具时使用前一份配置，在不使用时使用后一份配置，这样也是为了防止服务器重起导致default-character-set=utf8选项没起作用。