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

问题描述

我通常可以将捷克字符串写入表单:

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?

更新: HTTP 响应头:

解决方案:

• 在 Filter#doFilter() 中使用 request.setCharacterEncoding("UTF-8") 创建过滤器
• 检查所有 xml 以配置 UTF-8
• 将 <f:view contentType="text/html" encoding="UTF-8"/> 添加到主 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:

utf8

<property name="hibernate.connection.useUnicode">true</property>

推荐答案

鉴于这些症状，UTF-8 数据已使用 ISO-8859-x 编码重新显示.č(拉丁文小写字母 C 带 CARON(U+010D)) 存在于字节 0xC4 和 0x8D 的 UTF-8 中.根据 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");

此外，当您通过例如 <?xml version="1.0" charset="ISO-8859-1"?> 显式/隐式更改 Facelets 的默认字符编码时或 ，然后 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.

具体如何解决取决于使用的数据库服务器.通常，您需要在 DB 表的 CREATE 期间指定字符集，但您通常也可以使用 ALTER 更改它.对于 JDBC 驱动程序，这通常通过显式指定字符集作为连接 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

另见:

• Unicode - 如何获取字符对吗?
• 通过 PrimeFaces 输入组件检索的 Unicode 输入已损坏

这篇关于提交表单后输入中重新显示损坏的字符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！