MySql 4.1.x的编码陷阱

525views

又是一个晚上,不过解决了一个困扰我近两个月的问题,心中的舒畅还是难以言述的,这个Mysql 4.1.x的编码规则改变导致了一大堆软件都要跟着改,可是很多软件如果是用rpm编译好的话,例如PHP4等,就很难搞定这个编码的问题,我的Cacti用PHP抓Mysql服务器的状态的时候,如果服务器的默认字符集是UTF8,DOS的窗口就会出现“File ‘c:\mysql\share\charsets\?.conf’ not found (Errcode: 22) Character set ‘#33’ is not a compiled character set and is not specified in the ‘c:\mysql\share\charsets\Index’ file ”之类的错误,好在错误还不影响输出结果,但每个错误都伴随着一声清脆的beep,真受不了。。

刚架了Mysql的template的时候,研究了一次,因为没有时间,所以就扔那里,忍了两个月,今天正好赶上移动和备份老的Mysql数据库,就一次搞定吧,上网搜索了一下,N多方法,重新一个一个的试验,可是就没有一个好用的,转眼之间5个小时就过去了,搞的我郁闷非常啊,想想都准备放弃了,可是总是不甘心。。。

后来在Mysql的官方网站上看有人说,错误提示信息不是说要找那个目录的某个文件吗,那就去建立一个目录啊,可是4。1的charsets的定义格式和之前版本的完全不同,不过好在咱还有个3。23。54的,那就拷贝出来,然后和新版本开始对比,对比格式定义,对比Index检索,对比语言定义,终于有个大致的概念,这就开始改,好在都是文本文件,把Index文件里加上utf8# 33,然后把latin5.conf 做个copy,然后改名到utf8.conf,再次重新运行poller程序,哇,DOS的窗口无声的关闭。。成功了!!!!!!!!!!!!!!!!!!!呵呵。。

这个4。1的语言部分提高很大,终于成为从底层支持多元字符的数据库,但改动太大,其他相关产品配合不好,很有些问题搞死人啊,我看了N多人搞不定这个问题最后无奈换回4。0x版了,呵呵,偶还是很幸运的啊。。呵呵。。

相关的文章

Leave a Reply

will not be published

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据