昨天做个小页面,忽然发现运行后全是乱码.后来再看看,貌似就是忘记编码问题了.开头加个<%@page contentType="text/html; charset=gb2312"%> ,OK,一切OK了就.实际上这个语句的作用就是在jsp被编译成为html的过程中提供编码方式让java来”读取”表达式当中的String.而类似的有一个句子<META http-equiv=Content-Type content=”text/html; charset=gb2312〃>则是用来显示最后的数据.网络上常能看到合二为一乱用的情况.有关涉及到数据交换的,貌似用<%request.setCharacterEncoding("gb2312");%> 或者是<%response.setCharacterEncoding("gb2312");%> 应该就可用搞定了.
就gb2312来说,它是比较早的中文编码了,属于第一代产品,现在虽然也用的多,不过个人感觉还是GBK大方一点,但是支持的软件米有2312的多,- -!从2312一直向上,到GBK个规范,再到现在GBK2K的国家标准,这个国标貌似生存能力>>GBK...可是现在支持它的软件凤毛麟角,基本上属于珍惜动物..所以现在貌似还是2312范围广一点,毕竟够用,而且不怕什么软件不支持.
到应用服务器端,个人开发还是用的开源tomcat的多.毕竟免费,性能也不错,可人家毕竟是国外开发的,默认的编码当然不会用你的GB,从它的默认文件中就找的出默认编码,

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"

disableUploadTimeout="true" URIEncoding=”UTF-8”/>
最后那个,人家用的是UTF-8.可以用request的setCharacterEncoding方法设定编码方案.8过UTF-8貌似也能支持中文- -!还有个URL中文参数的问题,貌似可以用URLEncode.encode解决之.
MySQL就不用说了,毕竟是瑞典人开发的,默认拉丁编码,其实也是支持中文的,我就曾经同样的编码头一天还能看到中文,第二天打开看就全变固定的乱码了,无奈把编码改个GB才好用- -!