3.2. 转换过程的参数设置
    在以上的转换过程中可以看到，new String(code, "GB2312");这一处的第二个参数非常重要，它告诉java，这个字符串的原始编码是什么，如果写成其他的编码，必然会发生错误。

    因此，转换过程中的参数，java必须有途径得知正确的参数。 
    举例说，让java从文本文件里面读取一段中文。Java最终得到的字符串肯定是Unicode的，但是它需要程序员告诉它，这个文本文件到底是GB2312的，还是UTF-8的。如果程序员不告诉它，它就会贸然选择一种编码，进行解释，其结果可能就是乱码了
又举例说，如果一个Servlet得到了一个http的请求（request），需要程序员告之，这个请求里面的字符串是UTF-8，GB2312，还是纯粹的英文？当然，在得不到信息的时候，它又会自己胡乱猜一个。

    怎么？你不记得自己在代码里面指定过？对了，也许这就是中文问题的原因。 
    多数应用平台（应用服务器或其他）都不是关心中文问题的人编写的，所以不同的应用平台之间，设置参数的方式并不一样，可以说千奇百怪，甚至根本错误。

    在最新版本的tomcat上，推荐的处理方法涉及4个参数
    1. 网页必须制定http content type
    2. JSP必须制定JSP content type
    3. servlet/jsp的请求，必须设定字符集request.setCharacterEncoding.
    4. 修改tomcat的server.xml文件中URIEncoding的设置
    正如文章开头提到的，不同应用服务器的方式并不一致。前3个参数都是规范规定的，而第4的参数并没有规定，所以不同的服务器要用不同的方法。比如tomcat4不需要这个参数，它会直接使用参数3。

    有人认为修改tomcat的配置文件麻烦，而自己写转码的函数进行处理，这不是一个很好的方法，如果转换服务器，因为服务器本身的处理方式变化了，这段“转码”函数很有可能得到面目全非的结果，比如在tomcat4上。

    这里面似乎存在很多重复，但是没有办法。有时候给一段字符给java，java确实没有办法猜测其字符集。如参数3本来是没有的，J2EE规范认为浏览器提交的数据会描述数据的字符集，但是实际上没有浏览器遵守，所以才不得不引入这个参数。

   4. 中文问题的非技术原因
   以上分析了中文问题出现的技术原因，除此以外，还存在两个不是纯技术方面的因素