昨晚预生产，出了不少问题，其中SQL文件隐藏乱码问题始料未及，这个几年前就出现的问题，如今又重现。时间是最好的疗伤神药，同时也是“忘情水”，所以说好记性不如烂笔头，记录下来很重要，方便日后温习。
平时都是用UE（UltraEdit）工具来打开或编写SQL文件，而且文件都是用UTF-8编码保存，所以乱码看不到有任何乱码问题。
但昨晚部署后看到执行脚本后的日志（见下方），还是颇感意外。
Server 'XXXX', Line 1:
Incorrect syntax near '»'.
Msg 102, Level 15, State 1:
Server 'XXXX', Line 1:
Incorrect syntax near '¿'.
一番冷静之后，开始一遍遍检查脚本，无果。复制到SqlDbx客户端执行，一点问题都没。
后面把整个文件内容拷贝到空白文本文件保存后再复制回去，还是不行。
最后同事说用SqlDbx客户端打开就看到乱码了，肿么可能？我刚才才试过。再三追问才知道，原来是打开文件的姿势不对。她是直接把文件拖到客户端打开，而我是复制到客户端，就这点区别，囧。
自己试了一次，果不其然，首行就赫赫显示了上面的几个“特殊字符”。
后面又拖到eclipse，结果也可以看到。
考虑到文件全都是英文，并无中文，所以保存为ANSI/ASCII编码便可解决乱码问题。
——记录于2018-11-06
下面趁这个机会普及下编码知识吧。
ANSI和ASCII区别、Unicode和UTF-8区别
ANSI: American National Standards Institute 的缩写, 意思是美国国际标准学会, ASCII方案就是他们制定的。
ASCII: American Standard Code for Information Interchange.(美国信息交换标准码)
ASCII码中，一个英文字母占一个字节的空间，不分大小写。
由于美帝国主义没有想到其他落后国家需要用到计算机，所以只使用256个字符（2的八次方）表示大小写字母，数字和符号，并且刚好256个字符都用完了。
到中国人使用计算机的时候，已经没有可用的字符状态来表示汉字了。但这难不倒智慧的中国人民，我们将127号后面的奇异符号给取消，然后将两个127号后的字符表示为一个汉字。这就是GB2312的来源，它是对 ASCII 的中文扩展，后面由于字符还是不够用，所以又产生了GBK，GB18030。
结果每个国家都跟中国一样，搞出自己的一套编码标准，彼此之间互不兼容。简直乱出一锅粥。
最后 ISO（国际标谁化组织） 出手了：废除所有地区性编码，采用两个字节表示一个字符，也就是16位表示所有一切字符。缺点在于由于"半角"英文符号只需要用到低8位，所以其高 8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。该方案史称Unicode 。
UTF(UCS transfer format) 是随着计算机网络兴起而出现的传输标准。UTF-8就是每次传输8个位数据，UTF-16就是每次传输16个位数据。只不过UNICODE跟UTF不是一一对应的关系，而是通过一些算法和转换规则。
参考资料：
https://blog.csdn.net/zeroubuntu/article/details/19680005
https://blog.csdn.net/xiangxianghehe/article/details/77574965
网友评论