“主要”之间的编码差异 页面和 dojo 对话框
我有一个奇怪的编码情况,html 页面本身按其应有的方式显示(所有重音字符都正确显示),但所有弹出的 dojo 对话框都无法使用正确的编码。
设置如下:
- 在 Tomcat6.0.18 上运行 Hibernate/Spring/Struts2 的 Java Web 项目; 页面生成为 JSP 磁贴,由 Tiles2 组装在一起。
- 所有源文件均采用 UTF-8 编码,例外,资源属性文件 (
*.properties
) 采用 ISO-8859-1(根据 Java 规范)。 - 数据库采用 UTF-8 编码。
struts.xml
包含常量的定义:每个 JSP 磁贴都以语句开头
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %>
每个 JSP 页面(由多个磁贴组成)均以语句开头
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %>
从 JSP 代码生成的每个 HTML 页面包含以下
元标记开头:
>
Tomcat 编码过滤器为每个
设置标头请求通过 Tomcat
获取值:text/html;charset=UTF-8
使用以下语句在每个页面上初始化 dojo 1.2.3 p>
A
dijit.Dialog
首先创建,然后通过以下语句打开(/ voteOptions
action-URL 返回遵循与之前相同规范的 JSP 代码片段 — 该 JSP 代码片段最终嵌入到对话框的中):dialog = new dijit.Dialog({title:"我的标题",loadingMessage:"正在加载..."}); dialog.setHref('/votingOptions'); 对话框.show();
作为所有设置的结果,所有“正常”页面(即,将除了 dojo 对话框之外)按应有的方式显示所有字符、重音符号和所有字符,无论文本来自数据库还是来自资源文件。
另一方面,任何 dojo 对话框的内容都会被破坏:所有非重音字符都很好,但重音字符的显示完全就像尝试将 UTF-8 字符读取为 ISO-8859-1 字符(无论是这些字符来自数据库或资源文件)。
因此,例如,名称“Kurt Gödel”(因为它会正确显示在主页上)将在 dojo 对话框中显示为“Kurt Gödel” !
请注意,Firebug 在这两种情况下都会报告与 Tomcat 提供的响应标头相同的响应标头(无论是调用主页,还是在页面上打开 dojo 对话框):
Server: Apache/2.2.3 (CentOS)
Content-Language: en-US
Connection: close
Content-Type: text/html;charset=UTF-8
这两种类型的请求之间的唯一区别(除了 Content-Length 之外) ) is:
Transfer-Encoding: chunked
在请求主页时存在,但在 dojo-dialog 情况下不存在。
谁能弄清楚我到目前为止错过了什么? 或者,欢迎提出关于我应该进行何种调查以查明真相的建议!
I have a strange encoding situation, whereby the html page itself displays as it should (with all the accénted chäracters properly displayed), but all the popup dojo dialogs fail to use the correct encoding.
Here is the setup:
- Java web project with Hibernate/Spring/Struts2 running on Tomcat6.0.18; the pages are generated as JSP tiles, assembled together by Tiles2.
- all the source files are UTF-8 encoded, except for the resource property files (
*.properties
) which are in ISO-8859-1 (as per Java specifications). - Database is UTF-8 encoded.
struts.xml
contains a definition of the constant:<constant name="struts.i18n.encoding" value="UTF-8"/>
Each JSP tile starts with the statement
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %>
Each JSP page (formed of several tiles) starts with the statement
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %> <?xml version="1.0" encoding="UTF-8"?>
Each HTML page generated from the JSP code contains the following
<head>
meta-tag:<meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
A Tomcat encoding filter sets the header for
every single request going through Tomcat
to the value:text/html;charset=UTF-8
dojo 1.2.3 is initialized on each page with the statement
<script type="text/javascript" src="/scripts/dojo/dojo/dojo.js" djConfig="parseOnLoad:true,usePlainJson:true,locale:'fr'"></script>
A
dijit.Dialog
is first created and then opened by the following statements (the/votingOptions
action-URL returning a JSP snippet that follows the same specifications as previously---that JSP snippet ends up embedded inside the<div>
of the dialog):dialog = new dijit.Dialog({title:"My title",loadingMessage:"Loading..."}); dialog.setHref('/votingOptions'); dialog.show();
As a result of all that setup, all the "normal" pages (that is, putting aside the dojo dialogs) display all the characters as they should, accents and all, whether the text comes from the database or from the resource files.
On the other hand, the content of any dojo dialog gets mangled: all the non-accented characters are fine, but the accented characters get displayed exactly as if one was attempting to read UTF-8 characters as ISO-8859-1 ones (whether these characters come from the database or from the resource files).
So, for example, the name "Kurt Gödel" (as it would correctly appear on the main page) will be displayed as "Kurt Gödel" in the dojo dialog!
Note that Firebug reports the same response headers as served by Tomcat in both situations (whether calling the main page, or, once on the page, opening a dojo dialog):
Server: Apache/2.2.3 (CentOS)
Content-Language: en-US
Connection: close
Content-Type: text/html;charset=UTF-8
The only difference between those two types of request (apart from Content-Length) is:
Transfer-Encoding: chunked
which is present when requesting the main page but absent in the dojo-dialog case.
Can anyone figure what escaped me so far? Alternatively, suggestions would be welcome as to the kind of sleuthing I should perform to get to the bottom of this!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我也遇到了类似的问题。
就我而言,dojo javascript 文件以 iso-8859-1 格式返回。 为了解决这个问题,我必须重写默认 FilterDispatcher 类中的 getContentType() 方法。 我将其替换为以下代码(在Struts 2.0.9中测试):
I had a similar problem.
In my case the dojo javascript files where returned in iso-8859-1 format. To fix it I had to override the method getContentType() in the default FilterDispatcher class. I replaced it to the following code (tested in Struts 2.0.9):
Dojo 中的对话框小部件调用 URL /votingOptions,我假设它是由 servlet 或 Struts 操作处理的。
因为它是 Ajax 调用,所以我还假设如果您使用 struts 操作,那么您将通过 HttpServletResponse 对象发送响应,而不是重定向到视图。
无论哪种方式,请确保使用:
而不是:
我能够重现您使用这些代码片段所经历的行为。 第一个正确显示所有字符(甚至是日语字符!),第二个显示乱码消息。
由于您正在开发 Ajax 应用程序,因此还要确保安装 HttpFox 插件,它比 Firebug 更能显示 Http 流量。
The Dialog widget in Dojo calls the URL /votingOptions, which I assume is handled by a servlet or Struts action.
Because it's an Ajax call, I also assume that if you're using the struts action, then you're sending the response via the
HttpServletResponse
object instead of redirecting to a view.Either way, make sure to use:
instead of:
I was able to reproduce the behavior you were experiencing with these pieces of code. The first one shows all characters correctly (even the japanese ones !), the second shows a garbled message.
Since you're developping an Ajax app, also make sure to install the HttpFox plugin, which is better at showing Http traffic than Firebug.