乱码问题

{for locale in locales}
<tr align="center" bgcolor="#D5E8FD">
<td height="10" align="center">${locale.orgName}</td>
<td height="10" align="center">${locale.waitStat}</td>
<td height="10" align="center">${locale.monthStat}</td>
<td height="10" align="center">${locale.totalStat}</td>
<td height="10" align="center">${locale.exceedStat}</td>
</tr>
{/for}
===========================================
本人用buffalo调用返回为List,用如上template显示数据,在tomcat下显示正常,在websphere下中文的全显示成乱码了.请有经验的朋友指点,本人初用buffalo.谢谢先

评论

12 楼 tojava 2007-08-02  

搞不懂！为什么呢？

11 楼 hax 2007-06-22  

老是删贴，真没创意。

一片太平，都无长进。

10 楼 hax 2007-06-21  

有人删了我的留言？

算了，跟逻辑混乱或者语文理解能力有问题或者具有选择性阅读障碍或者有人罩着的，也没什么好说的。

9 楼 hax 2007-06-20  

我没有说你有语法问题。。。当然你可以强调一下你的语文水准不会犯语法错误。不过这也能引申出来？那看来不是逻辑问题，还是语文能力的问题了。

“Websphere比tomcat更符合j2ee规范的说法更不知从何而来。”

我确实不知道从何而来。。。

我只说了tomcat的以前版本的实现存在少数不符合规范的地方。联系上下文，不难看出我是特指其encoding处理方面。

有充分语文和逻辑能力的人，都可以看出我指出的tomcat过去版本存在bug的事实，并不能推导出websphere比tomcat更规范。

所以结论是，hexiaodong同志要么语文能力上有问题，要么是逻辑能力上有问题。

当然，没看清、看走眼、走神、偏见、在某些状况下不受控的选择性阅读……，也是合理的解释。

我再搞笑一下，“就jsp和servlet而言，tomcat一直最快最准确地实现这这两个规范”，这肯定经不起推敲。比如tomcat出现之前就有jsp/servlet了，那这个“一直”就不能说啦……

8 楼 hexiaodong 2007-06-20  

hax 写道

“能记住某个服务器的某个配置项就代表你的水准高人一等了!”

请问你这句话有没有逻辑呢？

这句话既没有语法问题，也没有逻辑问题。完全可以从你先前的那句话引申出来。

Websphere比tomcat更符合j2ee规范的说法更不知从何而来。的确，tomcat不符合完整的j2ee规范，但就jsp和servlet而言，tomcat一直最快最准确地实现这这两个规范。相反地是在主要的j2ee产品中websphere在跟随标准方面一直是最慢的，而且最不完整。

7 楼 hax 2007-06-20  

“能记住某个服务器的某个配置项就代表你的水准高人一等了!”

请问你这句话有没有逻辑呢？



我说几点：

1. 最好谨慎使用“标准”这个词。RFC或者ISO、w3c、ECMA等组织公布的，是真正的标准。有时候，比如你这里讲的“标准”是指Java相关规范。但是所谓filter是标准组件，实际上只是指所有容器都支持filter。所谓request.setCharacterEncoding是标准方法，也不过是指容器应该支持的方法。这些只能说我们希望使用一种符合统一规范的容器共通的方式来解决问题。这个愿望当然是良好的，但是并不能直接构成所谓“标准的方式”。没有任何Java规范说，一定要在filter里调用req.setCharEnc是解决encoding问题的“标准方式”。甚至连推荐方式也算不上。

2. Websphere在这点上没有任何违反JavaEE规范的地方。事实上它非常好的遵循了JavaEE规范。几乎在所有场合，Java各种规范都指出默认使用iso-8859-1编码。所以所谓乱码问题，其实是多数容器的默认设置都是iso-8859-1的结果。这个其实是java规范自己的历史包袱问题，如果今天重新设计Java的这些规范，相信一定会改为默认一律用UTF-8编码。

3. 所以在规范之外，完全是各容器自己处理。当然你可以说Websphere的配置方式不如Tomcat。但是一者，事实并非如此，Webshpere的配置设计很合理方便，反倒是Tomcat在5.0版本之前实现上有违反Java规范之处，现在也没有完全等价于Websphere的配置。二者，Websphere当然也可以使用filter，只要没有其他的参数覆盖了它。

4. 比较是采用filter方便，还是通过配置方便，有一个前提是，你认识到或者你认为，处理编码是一个开发问题，还是一个部署问题。作为一个部署问题看待，则你使用filter或者使用配置，方法本身并没有高下之分——只能够得出结论说，websphere比tomcat具有更好的配置特性（不需要写filter，虽然是非常简单的一个filter，也不需要配置filter）。至于反过来埋怨Websphere不应提供这样的配置，那我真不知道说你什么好了。

5. 最后，编码问题总是存在一些复杂的地方。楼主的例子，其实很大可能是其他原因导致，很大的可能是根本不能用request.setCharacterEncoding来解决，而是不是在filter里就无所谓了。

6 楼 hexiaodong 2007-06-19  

并非我有火气。
你一会说人家水平不够，一会说人家火气太大，说话没有逻辑。我都搞不清你这些断言建立在什么基础上。
说我没有水平，那你就把你的水平展示一下。说我没有逻辑，那你说我那几句话该怎么样更有逻辑的说给你听。
可以么？

我提倡写过滤器来解决这个乱码问题不是因为这样做代码更少，而是因为过滤器是标准组件接口，request.setCharacterEncoding()也是标准方法。这些标准在其他服务器上执行的很好。用标准的方式来解决问题，你的程序就可以更容易跨服务器。遗憾地是，我们看到websphere并不支持大家用标准方式来解决问题，在websphere有些符合标准的做法并不能起标准所申明的那些作用。

5 楼 hax 2007-06-19  

我并没有说用filter不好。

不要那么火气，而且你的火气之词并没有什么逻辑。

我没有贬低你的意思。我只是就事论事而已。没有人会天生知道这些东西，我也是逐渐学习和通过教训得来的知识。

我说你水准不够，当然不可能是因为你不知道websphere的配置项，实际上我自己也记不住。我说的很明白：你没有理解问题本身的复杂性而已。

我希望你了解我所讲的“问题本身的复杂性”是什么意思。了解问题本身，你就会不在乎是用filter或者一个配置去解决它。你就不会因为你掌握了filter，而websphere提供了配置让你无法施展filter弄的你不爽而埋怨它。事实上就这个个案来说，配置当然比filter要更方便更简单。了解问题本身，你或许也能注意到，在现在tomcat上，其实也有类似websphere的配置而无需再用filter。你还能注意到，遵循怎样的规范，可以最大程度的避免这样的问题，或者哪些情况下，是本身的误用造成的乱码。

4 楼 hexiaodong 2007-06-19  

像tomcat下用filter来管理编码不是很好么？
能记住某个服务器的某个配置项就代表你的水准高人一等了!

3 楼 hax 2007-06-16  

websphere我用过，我觉得还是蛮好用的，就是管理界面有点慢而已。如果你理解encoding问题，就很容易在管理界面中找到配置项，这正是它作为商用产品方便的地方。

实际上它并没有搞复杂，是你水准不够，你没有理解问题本身的复杂性而已。作为商业公司，支持是要有成本的，他当然希望你不要来烦他啦。所以你的猜想是不对的。

2 楼 hexiaodong 2007-06-14  

呵呵，webshphere是一个不那么容易用的东西。
字符乱码问题，我以前也遇到过，需要在管理界面中配置一下才可以。通用的filter做法是不管用的。具体的什么参数什么值已经忘了，当时是请websphere售前工程师才搞定的。
websphere搞这么复杂是不是为了收服务费方便一些呢？

1 楼 littcai 2007-06-14  

我用DWR提交,在WEBSPHERE里也乱码了