request.getCharacterEncoding()返回NULL ...为什么? [英] request.getCharacterEncoding() returns NULL... why?

查看:808
本文介绍了request.getCharacterEncoding()返回NULL ...为什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的同事创建了一个基本的联系我们类型的表单,它是重音字符(è,é,à等)。我们在Struts 1上使用KonaKart一个Java电子商务平台。

A coworker of mine created a basic contact-us type form, which is mangling accented characters (è, é, à, etc). We're using KonaKart a Java e-commerce platform on Struts 1.

我已经将问题缩小到通过HttpServletRequest对象进入的数据。比较一个类似的(正常工作的)形式,我注意到在旧的形式请求对象的字符编码( request.getCharacterEncoding())返回为UTF-8但是在新的表单上,它返回为NULL,并且来自 request.getParameter()的文本已经被破坏。

I've narrowed the issue down to the data coming in through the HttpServletRequest object. Comparing a similar (properly functioning) form, I noticed that on the old form the request object's Character Encoding (request.getCharacterEncoding()) is returned as "UTF-8", but on the new form it is coming back as NULL, and the text coming out of request.getParameter() is already mangled.

除此之外,我还没有发现已知良好形式和新破坏形式之间的任何显着差异。

Aside from that, I haven't found any significant differences between the known-good form, and the new-and-broken form.

我已排除的操作:


  • < meta http-equiv =Content-Typecontent =text / html; charset = UTF-8/>


  • 从Firebug检查,请求和响应标头都具有相同的属性

  • 这两个JSP网页在<%@ page contentType =text / html; charset = UTF-8language =java%> tag

  • * Form.java文件中没有任何有趣的东西可以继承自BaseValidatorForm

  • 我已经检查了源文件编码,它们都设置为Default - 继承自Container:UTF-8

  • Both HTML pages have the tag: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  • Both form tags in the HTML use POST, and do not set encodings
  • Checking from Firebug, both the Request and Response headers have the same properties
  • Both JSP pages use the same attributes in the <%@page contentType="text/html;charset=UTF-8" language="java" %> tag
  • There's nothing remotely interesting going on in the *Form.java files, both inherit from BaseValidatorForm
  • I've checked the source file encodings, they're all set to Default - inherited from Container: UTF-8

如果我将它们从ISO-8859-1转换为UTF-8,它工作伟大,但我更愿意弄清楚核心问题。
eg: new String(request.getParameter(firstName)。getBytes(ISO-8859-1),UTF8)

If I convert them from ISO-8859-1 to UTF-8, it works great, but I would much rather figure out the core issue. eg: new String(request.getParameter("firstName").getBytes("ISO-8859-1"),"UTF8")

欢迎任何建议,我的想法。

Any suggestions are welcome, I'm all out of ideas.

推荐答案

现代浏览器通常不提供HTTP请求中的字符编码 Content- code>头。在基于HTML表单的应用程序的情况下,但是与为表单的页提供的初始HTTP响应的 Content-Type 标题中指定的字符编码相同。您需要明确地将请求字符编码设置为相同的编码,这在您的情况下,因此是UTF-8。

Modern browsers usually don't supply the character encoding in the HTTP request Content-Type header. It's in case of HTML form based applications however the same character encoding as specified in the Content-Type header of the initial HTTP response serving the page with the form. You need to explicitly set the request character encoding to the same encoding yourself, which is in your case thus UTF-8.

request.setCharacterEncoding("UTF-8");

在之前执行此操作从请求中检索任何请求参数它太晚了;然后将使用服务器平台默认编码来解析参数,这通常是ISO-8859-1)。在 / * 上映射的 servlet筛选器是完美的地方。

Do this before any request parameter is been retrieved from the request (otherwise it's too late; the server platform default encoding would then be used to parse the parameters, which is indeed often ISO-8859-1). A servlet filter which is mapped on /* is a perfect place for this.

  • Unicode - How to get the characters right?

这篇关于request.getCharacterEncoding()返回NULL ...为什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆