提交表单后,在输入中重新显示损坏的字符 [英] Corrupted characters redisplayed in inputs after submitting form

查看:108
本文介绍了提交表单后,在输入中重新显示损坏的字符的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我通常可以用以下形式写czech字符串:

I can normally write czech string to the form:

但是在验证后(当我将收集的字符串发送到数据库时),字符串是另外一些字符集:

But after validation (and also when I send the collected string to database) the string is in some other charset:

>

h:outputTexts (jméno,příjmení)仍然正常显示, h:inputTexts

h:outputTexts (jméno, příjmení) are still shown normally, h:inputTexts are not.

我应该在哪里查找问题?

Where should I look for the problem?

UPDATE: HTTP响应headers:

UPDATE: HTTP response headers:

>

解决方案


  • 使用 request.setCharacterEncoding(UTF-8)过滤器#doFilter()

  • 所有xml已配置UTF-8
  • 添加< f:view contentType =text / htmlencoding =UTF-8/& code>到main xhtml

  • 将这些行添加到hibernate.cfg.xml中:

  • create filter with request.setCharacterEncoding("UTF-8") in Filter#doFilter()
  • check all xml to have UTF-8 configured
  • add <f:view contentType="text/html" encoding="UTF-8"/> to main xhtml
  • add these lines to hibernate.cfg.xml:

hibernate.connection.useUnicode> true

property name =hibernate.connection.characterEncoding> UTF-8

property name="hibernate.connection.useUnicode">true
property name="hibernate.connection.characterEncoding">UTF-8

推荐答案

鉴于症状,使用ISO-8859-x编码重新显示UTF-8数据。 č拉丁语小写字母C与CARON(U + 010D))存在于字节的UTF-8 0xC4 0x8D 。根据 ISO-8859-1编码页布局,这些字节表示字符Ä和[nothing]分别,这正是你看到的。

Given the symptoms, UTF-8 data is been redisplayed using ISO-8859-x encoding. The č (LATIN SMALL LETTER C WITH CARON (U+010D)) exist in UTF-8 of bytes 0xC4 and 0x8D. According to the ISO-8859-1 codepage layout those bytes represent the characters Ä and [nothing] respectively, which is exactly what you're seeing.

这个特殊的问题可以有很多原因。由于Facelets本身已经使用UTF-8 (默认情况下)来处理HTTP POST请求参数和编写HTTP响应,因此应该/无需在Java / JSF端修复/更改。

This particular problem can have many causes. As Facelets by itself already uses UTF-8 by default to process HTTP POST request parameters and to write the HTTP response, there should/can be nothing which you need to fix/change in the Java/JSF side.

但是,当您在JSF创建/恢复视图之前手动抓取请求参数(例如在自定义过滤器中)时,Facelets可能为时已晚设置正确的请求字符编码。您必须先在自订筛选器中加入下列程式码,才能继续使用这个链接,或者在之前映射的过滤器中加入以下内容:

However, when you're manually grabbing a request parameter before JSF creates/restores the view (e.g. in a custom filter), then it may be too late for Facelets to set the right request character encoding. You'd need to add the following line to the custom filter before continuing the chain, or in a new filter which is mapped before the filter causing the trouble:

request.setCharacterEncoding("UTF-8");

此外,当您明确/隐式地将Facelets的默认字符编码更改为例如<?xml version =1.0charset =ISO-8859-1?> < f:view encoding =ISO-8859 -1> ,则Facelets将使用ISO-8859-1。您需要将其替换为 UTF-8 或将其全部删除。

Also, when you've explicitly/implicitly changed the Facelets' default character encoding by for example <?xml version="1.0" charset="ISO-8859-1"?> or <f:view encoding="ISO-8859-1">, then Facelets will use ISO-8859-1 instead. You'd need to replace it by UTF-8 or remove them altogether.

如果不是,只有数据库端是主要的嫌疑。在这一边,我可以看到两个可能的原因:

If that's not it, then only the database side is the major suspect. In that side I can see two possible causes:


  1. 数据库表不使用UTF-8。

  2. JDBC驱动程序未使用UTF-8。

如何解决它取决于所使用的数据库服务器。通常,您需要在数据库表的 CREATE 中指定字符集,但通常也可以使用 ALTER 更改它。至于JDBC驱动程序,这通常通过明确指定charset作为连接URL参数来解决。例如,在MySQL的情况下:

How exactly to solve it depends on the DB server used. Usually you need to specify the charset during CREATE of the DB table, but you can usually also alter it using ALTER. As to the JDBC driver, this is usually to be solved by explicitly specifying the charset as connection URL parameter. For example, in case of MySQL:

jdbc:mysql://localhost:3306/db_name?useUnicode=yes&characterEncoding=UTF-8



另请参阅:



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