分析服务升级数据库脚本编码问题

一、编写目的

   1、 了解常用文本文件编码格式，了解跨程序，跨操作系统文件的访问。

    2、  规定mysql,达梦等数据库脚本的统一格式。

二、预备知识

   1、  一个标准的文本文件应该是：文件头+文件内容 这样的格式。文件头指定了后面的文件内容是用什么编码，如:GBK，UTF8，UNICODE等。没有文件头的文件被认为是操作系统当前编码。WINDOW上认为是ANSI编码，Linux上认为是UTF8编码。

    2、 没有文件头的文件(通常是程序生成的一些文件等)在不同的程序，不同的系统中交互会存在障碍。例如:A程序用GBK编码写日志文件 A.log, B程序希望读取A.log这个文件，但B程序采用的标准编码是UTF8编码，直接读A.log就会出现乱码。这时B程序需要明确知道A是什么编码格式，将读取出来的内容转化为UTF8编码才能使用。

    3、经常我们写日志文件不加文件头，但是用记事本都能打开查看。这时因为记事本有个强大的功能，会根据内容的上下文和操作系统的语言猜测是使用什么方式的编码，但一般程序并不具备这个功能。当用记事本另存为...并指定保存的编码格式，记事本就会在文件中加入文件头标记。常用的文件头标记：

ANSI:                         无  中文WINDOWS系统上就认为是GBK编码

UTF-8:                       0xEF,0xBB, 0xBF  前3个BYTE

UNICODE16 BE:          0xFE, 0xFF 前2个BYTE

UINCODE16 LE:          0xFF,0xFE 前2个 BYTE

用一些二进制查看工具如(UltraEdit)等，可查看前几个字节确定编码格式。

有一个经典的例子，就是打开记事本，写“联通”两个字，然后保存，这时是按ANSI保存的，保存关闭后再用记事本打开它，就变成乱码了，因为联通两个字的ANSI编码恰好与UTF-8文件头一样，记事本会认为这个是文件头标记，再读取就乱码了。

     4、  应为我们常用GBK和UTF8编码，这两种编码在英文字母和符号的编码上是重合的，所以转不转都是一样的，但涉及到中文字符就不一样了。

     5、所以如果我们生成的文件如果要被第三方程序使用，我们尽量写入文件头信息，其他程序会判断文件头信息来确定我们是采用的什么编码(虽然现在的采用的UTF8居多)。读取文件的时候也一样先判断是否有文件标记头，根据文件标记头确定后续数据的编码。如果与自己程序采用的编码方式不一样，先转换为自己的编码再使用

三、数据库脚本出现的问题

    1、目前我们的mysql开发基本采用Navicat相关工具开发，该工具“转存SQL语句”功能生成的文件,采用UTF8编码但没有写入文件头。导致我们读取这个脚本文件的时候认为是GBK编码的，在有中文的时候出现乱码，如果是在注释部分出现乱码还没问题，在具体语句上(特别是字典初始化)就会出现执行错误。

Sqlserver客户端工具保存脚本，没有这个问题，虽然没有文件头，但采用的是GBK编码。如果使用Navicat来开发sqlserver也要注意这个问题。

验证：可以将mysql转存的.sql文件，在sqlserver管理工具中打开，如果有中文，会显示乱码，sqlserver也是识别不了的。

四、解决方法

     1、Navicat“转存SQL语句”功能生成的文件不能直接使用,将该文件用记事本打开另存为UTF8，并覆盖同名文件即可。这样记事本就会在.sql脚本文件开头加入文件标记。（不涉及到中文可以不用这样操作）