mysql数据库运行sql文件的问题

来源:互联网 发布:淘宝内部折扣福利qq群 编辑:程序博客网 时间:2024/05/21 22:25

今天用sql文件往mysql数据库里导入数据,可是不知道为什么出现了中文不能正常显示的现象。我清楚的知道是因为编码的问题,所以就用urltEdit依次转换格式。发现转换成unicode utf8 utf8无bom等等格式编码,最后转换成utf8无bom编码格式导入中文成功,所以就想知道什么才是无bom格式呢?

现在先介绍下bom

BOM(Byte Order Mark)是一个字符,它表明UNICODE文本的UTF-16,UTF-32的编码字节顺序(高字节低字节顺序)和编码方式(UTF-8,UTF-16,UTF-32, 其中UTF-8编码是字节顺序无关的)。

如下所示:
Encoding Representation
UTF-8 EF BB BF
UTF-16 Big Endian FE FF
UTF-16 Little Endian FF FE
UTF-32 Big Endian 00 00 FE FF
UTF-32 Little Endian FF FE 00 00

有些utf8编码没有这个BOM,该怎么区分了,是utf8还是ansi(根本就没有BOM这个东西),下面先了解下utf8:

UTF-8是UNICODE的一种变长字符编码,由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码UNICODE字符。如果UNICODE字符由2个字节表示,则编码成UTF-8很可能需要3个字节,而如果UNICODE字符由4个字节表示,则编码成UTF-8可能需要6个字节。用4个或6个字节去编码一个UNICODE字符可能太多了,但很少会遇到那样的UNICODE字符。

UFT-8转换表表示如下:

UNICODE UTF-8
00000000 - 0000007F 0xxxxxxx
00000080 - 000007FF 110xxxxx 10xxxxxx
00000800 - 0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
00010000 - 001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
00200000 - 03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
04000000 - 7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

实际表示ASCII字符的UNICODE字符,将会编码成1个字节,并且UTF-8表示与ASCII字符表示是一样的。所有其他的UNCODE字符转化成UTF-8将需要至少2个字节。

以上是网上找的utf8编码介绍,对于这个转换表可以看作一个模板,对于以标示的二进制位值是固定的,XX位是将字符以unicode编码,然后根据值的大小分段,决定使用哪个模板,高位在前的次序填入XX位.
ascii占用一个字节,一般我们见到的其它字符都是占用3个字节,套用00000800 - 0000FFFF 1110xxxx 10xxxxxx 10xxxxxx这个模板,这样第一个字节就是>=11100000(&HE0) and < 11110000(&HF0),后面两个字节>=10xxxxxx(&H80) and < 11000000(&HC0),我们就可以根据这点来写代码了,符合这个规则的都被判为utf8,否则为ansi.

这种判断法,一般的字符都可以正确判断,可踫上特殊的就会变成乱码,像比较普通的"联通"两个字,还有"戟半丁","戟广发"等等,像这种组合正好落在这个判断内就会把本来的ansi编码识别为utf8,从而变成乱码,系统自带的记事本用的判断法应该和这个差不多,对于以上的特殊字眼用ansi编码保存后,再打开同样是乱码,为什么要让无BOM的utf8编码存在了,虽然这种情况很少见.

其实bom对utf8是没用的,bom是用来标注utf16和utf32的,但是bom却会产生输出,就相当于一个空格,所以如果有bom的utf8编码就容易产生错误提示,在运行sql文件时建议采用无bomutf8格式