字符编码不适用于 PrimeFaces CellEditor 组件
我在使用
我使用 encoding='windows-1252' 来使用瑞典语字符< /strong> (å, ä, ö)。创建实体工作正常，但是当我使用 "åäö" 并保存编辑（使用 p:celleditor），则数据库中的表包含 "à¤à¶"< /代码>）。
我的 xhtml 页面如下所示：
<?xml version='1.0' encoding='windows-1252' ?>
<!DOCTYPE html>
<html...
我尝试使用字符编码过滤器：
public class CharacterEncodingFilter implements Filter {
private static String ENCODING = "windows-1252";
@Override
public void destroy() {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding(ENCODING);
response.setCharacterEncoding(ENCODING);
chain.doFilter(request, response);
}
@Override
public void init(FilterConfig config) throws ServletException {
}
}
但无济于事。有什么想法为什么 incell 编辑帖子使用不同的字符编码吗？
使用：
- NetBeans 7.0.1
- Glassfish 3.1
- Primefaces 3.0.M4
I'm having some trouble editing a table using <p:rowEditor>
I use encoding='windows-1252' to be able to use Swedish characters (å, ä, ö). Creating an entity works fine but when I edit it in a <p:dataTable> using <p:cellEditor> it commits characters that are unexpected. (If i enter "åäö" and save the edit (using p:celleditor), the table in the database contains "åäö").
My xhtml page starts like this:
<?xml version='1.0' encoding='windows-1252' ?>
<!DOCTYPE html>
<html...
I've tried using a Character Encoding Filter:
public class CharacterEncodingFilter implements Filter {
private static String ENCODING = "windows-1252";
@Override
public void destroy() {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding(ENCODING);
response.setCharacterEncoding(ENCODING);
chain.doFilter(request, response);
}
@Override
public void init(FilterConfig config) throws ServletException {
}
}
But to no avail. Any ideas why incell editing posts using a different character encoding?
Using:
- NetBeans 7.0.1
- Glassfish 3.1
- Primefaces 3.0.M4
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是 UTF-8 编码字符的典型 CP1252 表示形式。在 UTF-8 中，这些字符由以下字节表示：
å(U+00E5) =0xC30xA5ä(U+00E4) =0xC30xA4ö(U+00F6) =0xC30xB6如果您在 CP1252 代码页布局，您会看到它们准确地代表了这些字符
。在生成 HTML 响应和处理 POST 请求时，JSF/Facelets 默认使用 UTF-8 字符编码。 XML
encoding属性实际上并没有对此做出任何改变。它只是告诉 XML 解析器您写入/保存文件的字符编码，以便它可以使用正确的字符编码对其进行解析。更改 HTML 响应的字符编码和 POST 请求的处理是通过设置视图根标记
encoding属性来完成的：但是，我强烈不建议这样做。这样，您就可以从支持超过 100 万个字符的通用字符编码回退到支持不超过 255 个字符并且只能被 Windows 平台理解的专有字符编码。使用 Mac/Linux 或任何其他操作系统的网页访问者将无法正确解释该字符编码的 HTML 响应，也无法以该字符编码发回数据。您的 Web 应用程序还没有准备好成功统治世界。
你需要以不同的方式解决这个问题。显然您的数据库需要更改为支持 UTF-8。无法回答到底如何做到这一点，因为您没有告诉任何有关数据库品牌/版本的信息。但是更改数据库/表的字符编码应该是一些 SQL 命令的问题。或者，如果您正在尝试，只需截断数据库并使用正确的字符集重新创建它即可。有关详细信息，请参阅特定于数据库的 SQL 手册。
另请参阅：
That's a typical CP1252 representation of UTF-8 encoded characters. In UTF-8, those characters are represented by the following bytes:
å(U+00E5) =0xC30xA5ä(U+00E4) =0xC30xA4ö(U+00F6) =0xC30xB6If you lookup those six individual bytes in the CP1252 codepage layout, you'll see that they represent exactly those characters
åäö.JSF/Facelets defaults to UTF-8 character encoding when it comes to generating the HTML response and processing the POST requests. That XML
encodingattribute really doesn't change anything to that. It merely tells the XML parser which character encoding you've written/saved the file in so that it can parse it with the proper character encoding.Changing the character encoding of the HTML response and processing of POST requests is to be done by setting the
encodingattribute of the view root tag<f:view>:But, I strongly disrecommend this. This way you're falling back from an universal character encoding which supports over a million characters to a proprietary character encoding which supports no more than 255 characters and is understood by Windows platforms only. Webpage visitors which use Mac/Linux or any other operating system will not be able to properly interpret the HTML response in that character encoding, nor will it be able to send the data back in that character encoding. Your web application will not be ready for successful world domination.
You need to solve this problem differently. It's apparently your database which needs to be changed to support UTF-8. How exactly to do this cannot be answered, because you didn't tell anything about the DB make/version. But changing the DB's/table's character encoding should be a matter of some SQL commands. Or if you're experimenting, just by truncating the DB and recreating it with the proper charset. Refer the DB-specific SQL manual for details.
See also: