编码的错觉

　　习惯使用linux+tomcat+jdk+mysql的平台进行web开发工作,乱码是经常的事情，也经常困扰我。从这样一个开放环境来讲出现乱码一般多集中在这样几个环节。底层linux编码的问题，中间服务器组件的编码问题,数据库的编码问题，应用程序的编码问题。一般linux都提供了很多编码方案包括utf-8以及一般的中文编码类如GBK,GB18030,中间的服务器组件类似tomcat也会有编码问题，尤其是在tomcat 的URLencoding上会有多种编码选择，mysql就不要说了一堆的编码字符集，连接字符集，客户端字符集，记录结果字符集，应用程序编码主要是有java应用程序决定，比如我们使用的转编码方法new String(.getByties(),”")。如此多的编码需要考虑确实麻烦。各种编码之间有时还会有些影响，不得不考虑。

　　操作系统的编码是最基础的编码，很多时候我们感觉不到的乱码问题的真正原因就是OS编码的问题。比如前段时间我在linux上安装mysqlcc这个客户端的时候打开发现全都是乱的，以为是数据库和软件本身（软件本身可以认为是应用程序的编码问题）的问题，但最终发现是操作系统的问题，在将操作系统编码更改为GB18030简体中文编码保持与应用程序（mysqlcc ）和数据库(我当时数据库用的是latin1编码来存放GBK简体中文)编码一致后乱码不再出现了。而在安装sqlyog客户端之后又会出现乱码，我判定这不是操作系统和数据库的原因，原因在应用程序sqlyog，他一定采用的是utf-8编码，所以查看所有GBK和latin1中文的数据库一定出乱码。

　　服务器中间组件的编码有时候也会造成乱码的出现，比如你试试在tomcat服务器上通过URL来传递一个中文试试，如果不设置估计一样是乱码，这里需要设置server.xml中的URLencoding编码来控制服务器上传递的参数编码。

　　应用程序上的编码是比较直观的编码形式，在java开发代码里我们可以通过new String这样的方法控制应用程序的每个字符的编码，这种乱码最容易解决也最直观。

　　Mysql的编码这个是最麻烦的，自从Mysql4.1之后的国际语言支持出现，各种编码问题就没停过。因为此后的mysql对字符集的控制更多更细，但这几个字符集是我们在遇到编码问题时候首先要考虑的－－character-set-client character-set-connection character-set-result。Mysql编码问题讨论的文章到处都有，这里不再赘述。

　　每一次的乱码问题一定要分析清楚究竟是哪个环节上出问题了，不同环节之间也会有影响，今天我碰到一个问题可以说明这个情况：一段在我本地Federo8系统上运行很好的程序，上了服务器就出问题，我在java中转换了各种编码但始终不能解决问题，最终发现服务器的编码是ISO-8859-1,我本地是GB18030,这就是问题的关键。

　　乱码问题在各种开源环境中都会遇到，比如LAMP,就算是你用eclipse也会有乱码问题，说到这里我真是羡慕微软的开发者，他们有一个统一的平台从OS到服务器IIS到数据库SQLSERVER到应用程序ASP/.NET,统一最大程度的减少了乱码的可能性。不过对于程序员来说少了点解决问题的喜悦。