关注技术，关注生活

     摘要: 因为工作需要，在做过电子地图和WEB游戏的JS应用程序后，将其中一些经验跟大家分享一下。就像文章的名称一样，这篇里的优化方式并不是教你如果减少JS的时间，而是增加它的时间来达到高速度。不要怀疑你的眼睛，也不要怀疑我是标题党，看下去自有分晓。  阅读全文

     摘要: 这段时间开始使用SPRING2.5+Hibernate，发现里面对hibernate配置的Annotation无法支持对包路径下的类进行扫描（annotatedPackages并不是这个作用），只能一个个添加，对比起xml配置的路径扫描就弱了许多，也麻烦了许多。在网上搜了一下，发现在Spring Annotation这个项目中有实现这个方法，但在国内的网站上都没提到过，所以就把内容给转过来，方便大家参考下。  阅读全文

我在之前的一篇文章《struts,ajax乱码解决方案》中讲到ajax提交乱码的解决方案。这个方案在utf-8的编码下，不管提交或获取都没有变成乱码，但当你的客户端是GBK编码时提交就会出现乱码（获取时不会）。BeanSoft 说用encodeURIComponent保险，呵呵，这个不是我没试过，从一开始我就试过了encodeURIComponent ,escape,encodeURI，但最后出来的结果都没我说的那种好。它们使用的结果如下：
escape  后提交，getParameter出来的是null，
encodeURI　后提交，和没使用用的时候是一个样，
encodeURIComponent  后提交，包含特殊字符的请求都无法取得正确的值。

使用GBK编码提交后的数据在使用服务器端用new String( value.getBytes("gbk"), "utf-8")后部分可以恢复正确的中文，但有一部分无法恢复，这个原因估计是AJAX提交时设置了编码为UTF-8，但我字符的实际编码是GBK，所以在提交用用request.getParameter()获得的数据是用UTF-8的编码在GBK的字符集中找字符，像我在《struts,ajax乱码解决方案》中说的那样，UTF-8的编码可能有1位2位或3位16进制，如果它这个编码刚好是2位的话，那在GBK可以找到正确的字符（但并不是正确的），但如果是三位呢？那就惨了，它后面的字符全部就会变成乱码，比如%6D%51%C5　%E5%23%1C分别表示一个UTF-8编码的中文字符，那如果在GBK中，就会把它当成三个字符去查找，当然肯定是找不到的，有些找到的也是你读都读不出来的。用new String( value.getBytes("gbk"), "utf-8")后就是用GBK的编码在UTF-8的字符集中查找字符，如果刚好你的字符在UTF-8编码中全部是2位的话，那就能正确恢复，如果不是的话。。。。。。

现在还没找到在GBK编码下比较好的解决方案，但今天看到BeanSoft 的一篇文章《JSP 中 AJAX 的表单提交中文问题的简单解决方案》说到使用BASE64的方法，这个倒是没有试过，过两天放假的时候就试一下，如果成功了就跟大家共享一下。

PS：因为项目用也用到了FILTER，在提交后第一时间会被改变字符编码，不知道是不是这个增加的乱码解决的复杂性，当然我也试过在getParameter之前改变它的编码回utf-8，但结果是一样的。