作者buganini (霸格尼尼)
看板Database
标题Re: [系统] MySQL 5.1 / MySQL 3.23 在big5上不相容
时间Sat Dec 25 00:57:54 2010
不是加个\就好了吗@@
你可以写个小程式去检查中文第二个byte
不写程式的话
我有个拙作
https://github.com/buganini/bsdconv/
Download里面有windows用的版本
你可以用
bsdconv ascii,big5:big5-5c,big5,ascii in.sql out.sql
就可以自动在适当的地方加上\
--------------------------------------
关於big5 latin1
有些地方因为不是使用严格的cp950 (有UAO之类的)
所以被迫使用latin1
我目前的解法也是改phpmyadmin
偷工减料一点的话, 通常会遇到的只有big5跟utf-8
那就把语系档砍一砍, 留下中英文
或是复制一份中文改个名字
然後在连线的地方根据语系去set names
这样就可以简单用选择语系切换
--------------------------------------
就我个人的经验
mysql转换应该没这麽凄惨才对
其中一定有什麽误会
※ 引述《EAFV (流浪猫)》之铭言：
: 我不确定这能不能帮到你什麽
: 不过我当初的转换也是搞了很久都没办法
: 我那资料库还更麻烦,有一堆unicode补完产生的日文
: 因为程式不支援的关系,也没办法治本的直接转UTF8
: 之後是用土法链钢的方式
: 写程式去把资料一笔笔捞出来SET为big-5之後写入到新版的mysql里
: 至於校对方面
: 我自己测的情况是big5_bin跟big5_chinese_bin转过去都会有问题
: 後来是设定为binary
: 只是资料库管理的部份,很多不支援big-5
: 我後来是自己改个另外big-5专用的phpmyadmin来用...
除非说当初每个table设定都不一样
不然只要一次mysqldump出来的资料没有乱码
都可以简单解决的
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 220.135.231.23
补充一下
跨这麽大版本升级还有可能遇到的问题是SQL语法不相容
有些人是用phpmyadmin去dump 应该也是可以
我是偏好用新的mysqldump去dump旧的mysql-server
通常再改一改.sql处理一下编码问题
加个set names 就可以塞回去了
然後新版encoding/collation有一个很重要的地方
就是最好在create database的时候就指定好正确的编码
这样底下的其他设定就会自动跟着对
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:02)
1F：推 pingsky:若是我的问题的话, 简单的话, mysql 5.1 若用 big5 不吃 12/25 01:03
不是不吃 只是要escape
现在还有很多系统是big5 也在mysql 5上跑得好好的
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:06)
如果db里面是设定big5
那就同我在原文推的
把.sql转成utf-8
然後在.sql前面加上
set names "utf8";
再倒回去
这个动作不是要把资料库变成utf-8的
是让mysql吃utf-8进去 然後转成big5存
吃utf-8进去就不会有\的问题
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:09)
database编码设为X
client连上去set names Y
mysql就会自动在X,Y之间转换
所以设定正确的时候
UTF-8,Big5的database都可以直接用未经修改的phpmyadmin看到正确的资料
只有被迫用latin1存big5的才会有问题
(因为latin1 (应该就是iso-8859-1吧)
从00~7F~FF都有定义 所以可以当binary用
只是collation就破破的)
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:11)
2F：推 pingsky:不吃'尠' 啊, 问题根本不是在 c5(\) 上 12/25 01:10
3F：推 LPH66:那是 5C...另外这字是 UAO 放在 big5 的造字区的 12/25 01:13
你出问题的的byte sequence是fbf3
mysql5的big5用的是cp950的表
我在
http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP950.TXT
里面找不到
也就是说他对mysql5来说根本就是illegal sequence
你可以把他取代为A148 (全形问号)
厄.. 其实他应该不是全形问号吧?
但我的terminal也不吃那个 所以我看到的就是全形问号XD
或是成为被迫使用latin1的族群
然後转成utf-8去塞的话
也不会有illegal sequence的问题
进去的话有可能会transliterate成某个适当的符号
或是变?
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:20)
4F：推 LPH66:和 UAO 的日文问题是同一件事... 12/25 01:18
5F：推 pingsky:LPH66 大, 我是要打 5C 没错, 手残又太快而打错了.. 12/25 01:19
※ 编辑: buganini 来自: 220.135.231.23 (12/25 01:25)
6F：→ buganini:好吧 我查出他是鹿儿了 XD 12/25 01:28
7F：→ buganini:iconv的transliteration没法处理这个字 只能变问号了 12/25 01:33