Question

向我的servlet发出HTTP POST请求。在http请求中有一个已发布的表单参数，我的servlet中的代码将检索该参数以进行名为“payload”的进一步处理。当有效负载的值包括windows-1252字符“'”（ascii值146）时，HttpServletRequest实例方法getParameter（“payload”）返回null。 server.log中没有与问题相关的内容。我们认为用于生成此字符的字符编码是windows-1252。 http请求的字符编码glassfish默认为ISO-8859-1。 Ascii值146是ISO-8859-1中的控制字符。

有没有人对如何解决这个问题有任何建议？

显示问题的帖子中的http请求标头是：

POST /dbxchange/TechAnywhere HTTP/1.1
CONTENT_LENGTH: 13117
Content-type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_16
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 13117

Answer 1

Java并不关心Cp1252和Latin-1之间的差异。由于两种编码中都没有无效的字节序列，因此任何一个都不会为null。我认为您的服务器使用的是UTF-8，浏览器使用的是Cp1252或Latin1。

尝试在表单中放入以下属性以查看它是否有帮助，

<form action="..." method="post" charset="UTF-8" accept-encoding="UTF-8"...>

Answer 2

我们认为用于生成此字符的字符编码是windows-1252。

是的，非常可能。即使浏览器声称使用iso-8559-1，它们通常也会使用windows-1252。

http请求的字符编码glassfish默认为ISO-8859-1

很可能它违反了系统的Java'默认编码'。这很少是您想要的，因为它会在您重新部署应用程序时中断它。

对于读取POST请求主体，您应该能够通过在请求对象上调用setCharacterEncoding来修复编码，只要您能够尽早完成，以便没有人已经让它读取了body通过调用getParameter等方法。尝试将编码设置为“Cp1252”。虽然从长远来看，你真的应该为UTF-8做好准备。

不幸的是，没有标准的J2EE方法来指定应用程序对所有请求（包括不受setCharacterEncoding影响的查询字符串参数）所期望的编码。每个服务器都有自己的方式，这会产生恼人的部署问题。但对于Glassfish，请在sun-web.xml中设置<parameter-encoding>。

Answer 3

我们发现问题出在发送帖子请求的javascript代码中。 javascript代码是在发送请求之前编码有效负载值的URL。 javascript内置函数escape（）用于执行URL编码。这将字符编码为％u2019的非标准编码实现。似乎glassfish不支持这种非标准形式的编码。

请参阅http://en.wikipedia.org/wiki/Percent-encoding#Non-standard_implementations

修复是使用内置的javascript函数encodeURI（）为'

返回“％E2％80％99”

windows-1252字符146正在停止到达glassfish v2中的servlet的POST数据

3 个答案: