现在的位置: 首页 > 综合 > 正文

resin3.1处理utf-8格式的jsp时存在的问题

2013年12月13日 ⁄ 综合 ⁄ 共 2754字 ⁄ 字号 评论关闭

    以前一直使用resin-3.0.x作为服务器,最近想升级到resin3.1,于是在官网上下载了resin3.1.7a,解压配置一切正常,但把应用重新部署上去的时候就出了问题,以前一直正常的页面,现在却报错:

 

500 Servlet Exception

 

<script type="text/javascript"></script>
[show] /index.jsp:1: contentType 'text/vnd.wap.wml; charset=utf-8' conflicts with
previous value of contentType 'text/html; charset=UTF-8'.  Check the .jsp
and any included .jsp files for conflicts.

1:  <%@page contentType="text/vnd.wap.wml; charset=utf-8"%>
2:  <%@page import="java.util.*"%>
3:  <%!

 

 

    根据上面的提示,意思似乎是我在jsp里面第一行设置的contentType是'text/vnd.wap.wml; charset=utf-8,和前面设置的'text/html; charset=UTF-8'不同导致冲突,但这个文件的第一行就是<%@page contentType="text/vnd.wap.wml;charset=utf-8" %>,根本没有设置过'text/html; charset=UTF-8',这个提示真是让人很摸不着头脑。

    后来想到可能是UTF8文件格式的问题,就用UE打开文件,另存了一次,选的是不带BOM的UTF8格式的文件,这次就可以正常显示了。但服务器上那么多文件,不可能一个一个的改,还得想其他的办法解决。在网上找了很久都没有任何头绪,似乎遇到这个问题的人很少。

    最后实在是没办法,只好把源代码下载下来研究一下看了,还真的找出了原因所在。

    因为resin在处理jsp文件的时候,会首先读取前面的几个字节来判断文件的格式,如果第一个字节是0xef、第二个字节是0xbb、第三个字节是0xbf,那么就认为这个文件是UTF8格式,于是就自作主张的把ContentType设置成了text/html; charset=UTF-8,然后在后面的处理过程中,因为jsp程序里面会有设置ContentType的指令,遇到这个指令会发现和之前的text/html; charset=UTF-8不同,因此就抛出了异常。而如果没有BOM格式的UTF8,前面就不会有那三个字节的标识,所以就不会被处理了。

    相关代码:

Java代码  收藏代码
  1.    case 0xef:  
  2.      if ((ch = stream.read()) != 0xbb) {  
  3. stream.unread();  
  4. stream.unread();  
  5.      }  
  6.      else if ((ch = stream.read()) != 0xbf) {  
  7. throw error(L.l("Expected 0xbf in UTF-8 header.  UTF-8 pages with the initial byte 0xbb expect 0xbf immediately following.  The 0xbb 0xbf sequence is used by some application to suggest UTF-8 encoding without a directive."));  
  8.      }  
  9.      else {  
  10. _parseState.setContentType("text/html; charset=UTF-8");  
  11. _parseState.setPageEncoding("UTF-8");  
  12. stream.setEncoding("UTF-8");  
  13.      }  
  14.      break;  

 

    判断冲突的代码:

  

Java代码  收藏代码
  1. else if (CONTENT_TYPE.equals(name)) {  
  2.     String oldContentType = _parseState.getContentType();  
  3.       
  4.     if (oldContentType != null && ! value.equals(oldContentType))  
  5.       throw error(L.l("contentType '{0}' conflicts with previous value of contentType '{1}'.  Check the .jsp and any included .jsp files for conflicts.", value, oldContentType));  
  6.       
  7.     _parseState.setContentType(value);  
  8.     String charEncoding = parseCharEncoding(value);  
  9.     if (charEncoding != null)  
  10. parseState.setCharEncoding(charEncoding);  
  11.   }  

 

真不明白为什么resin要这么做呢,如果是web网站可能影响不大,contentType本来就是text/html,但如果是wap或者其他contentType的站点这么“智能”的编码判断方式问题就比较麻烦了。

 

 

附:UTF-8 编码的文件可以分为no BOM 和 BOM两种格式(转载)

何谓BOM? "EF BB BF" 这三个字节就叫BOM,BOM的全称叫做"Byte Order Mard".在utf-8文件中常用BOM来表明这个文件是UTF-8文件,而BOM的本意实在utf16中用来表示高低字节序列的。
在字节流之前有BOM表示采用低字节序列(低字节在前面),而utf8不用考虑字节序列,所以其实有无BOM都可以。

微软的记事本 Word 等只能正确打开含BOM的UTF8文件,然后UltraEdit却恰恰相反,回把BOMutf8文件 误认为ascii编码。

UTF-8的BOM是 EFBBBF,因为UE载入UTF-8文件会转成Utf16,上述的EFBBBF 在Utf16中是FFFE(Unicode-LE的BOM),UltraEdit不认识BOM又加多一個BOM,所以有2个FFFE。
文件就被它破坏了。

抱歉!评论已关闭.