解决中文乱码的法则

序：

    昨天又遇到一次异构平台下交互数据中文乱码故障，实在记不清这是第几次遇到了，每个在中文环境下开发的程序员或多或少都会遇到中文编码解码问题。

分析故障原因耗费我几个小时，在反复调试无法知道故障点的情况下，我终于用上了sniffer大法，哦，问题原来出在encode中文URL。

解决思路：发送端是gb2312，接收端也采用gb2312接收，无乱码。不过在urlencode时，将中文URL错误的进行了转换，正确的结果应该是英文URL为3字符，中文URL也是3字符，可将源数据以gb2312一致对待后，编码结果则为5字符。那么要修订这个bug，无非有两种可能，第一，发送端更改，第二，接收端更改。本文的中心思想就是想定义一个法则，能处理所有乱码问题。

正文

一种错误的观念：发送端采用什么格式编码，接收端就采用什么格式解码。这种处理方式在同构平台下好用，在异构平台下则不一定好用。

因为在异构平台下，接收端往往不只一次解码，结果极容易是乱码。根据多年经验，我发现即使让接收端把所有格式都分别去和发送端组合，结果仍然不能保证是100%正确，所以，异构平台下，最好是发送端和接收端同时调整，进行编码解码组合。

那么我要说的法则就是：

一，同构平台下，发送端用什么编码，接收端就用什么解码。100%正确！如果出现不正确，那就参看第二条。

二，异构平台下，要保证100%不出乱码，得发送端和接收端同时调整，进行编码解码组合。

一些经验，出现乱码情况，首先要知道对方是什么编码，最好的方法就是得到原始通信数据，例如sniffer得到的。其次，接收端要尝试几种常用的格式解码，如果还不行，则必须和发送端去组合了。

最后说说我自己的事吧，那个故障分析后得出：

一，发送端不可能更改编码格式，因为开发者居然使用了中文url，这种情况不应该出现的！这是中文开发环境程序员的开发恶习。如果发送端更改编码格式，可能许多功能会失效或乱码。

二，接收端要更改，非常困难，原因是接收到的数据从源到目标，进行了多次格式转换。要支持中英文混合URl，得要点时间，这时间我等不起。

三，我只能自己解决了，解决方法很简单，将源数据进行一次filter，即将URL改成非URL，这样可避免URL encode的故障，因为很庆幸，我将中文URl再返回给发送端的时候，他能正确识别。