世界并不如你想象中完美！

这只是一篇以计算机相关的理论知识如unicode开始，你可以认为是一篇发牢骚的文章。

某次我在mysql中使用source XXX.sql命令执行一个脚本文件。发现结果插入数据库内容为乱码。当我在mysql环境设定为charset utf8，结果还是乱码。显示是按utf8的格式，那么肯定输入数据库的内容，不是utf8格式。最后的原因是那个xxx.sql脚本文件不是utf8编码的，导致输入的汉字成为的乱码。由此引开我想要讲的。早先计算机只有ASCII（American Standard Code for Information Interchange，美国信息互换标准代码），因为计算机是美国发明出来的。后来计算机技术作为高科技逐渐在世界范围传播开来。当时，早期让计算机输入中文字符曾被认为是计算机在中国发展的瓶颈。很多时候就是这样，为什么不是一开始就是用unicode，那么后面的麻烦事也要省下好多。为什么unicode又有两套?ucs-2和ucs-4，通用字符集（Universal Character Set，UCS）。ucs-2就是用两个字节编码，ucs-4就是用4个字节编码。正因为有如此多了不平衡以及不完美，那么作为完美主义的程序员就有理由诞生，并来解决各种差异。当时要注意到程序员本身也是不完美的，所以提出的解决方案也是在逐渐完美。这也许就可以理解为什么写好的程序需要一次次的修改，一半是完美主义作祟，另一半是写程序的人不完美。

读者可以先wiki一下unicode，了解一些背景知识，诸如unicode编码方式和实现方式utf8,utf16等。当你读完那些之后，那么我要告诉你的就是你还要关注现实，虽然unicode有utf-2和utf-4，但是目前操作系统windows和linux采用的是utf-2，你使用windows记事本另存为一文本文件时，可以看到编码方式

                      

目前系统也从底层实现了unicode，即使是asscii码也调用api转换为unicode交给下层。我考虑有没有一种统一的方法处理和显示字符，而不论是gb2312还是unicode。最后发现假设我在程序端判断文件所采用的方式，然后分别用对于不同字符集的处理函数。但是发现判断文件存储所采用的字符集所采用的根据特征字符的方法，不能做到完全正确。那么最后的解决方案只有事先客户机和服务器协商。若服务器要求客户端传过来的都是unicode并且是utf16格式，但现实的情况是总会有一些使用gb2312字符集格式的文件传过来。当然，那个程序我还是可以去写 。写这些东西并没有去写什么算法，写什么实实在在的code，我的观点是你还是要预先做好这个准备去写一些类似的程序。也许这样你就不会对人或对事有那么多的期待。因为世界不完美，你也不完美。