JSF 1.1 中的字符编码
我正在使用 JSF 1.1 开发一个工具，但遇到了这个问题： 打印为：
./src.cpp: In function ‘int main()’:
./src.cpp:4: error: ‘dsdada’ was not declared in this scope
我的支持 bean 中有一个字符串，它在 txt 文件上
但是当我把它放在 ah:inputTextArea 上时，它是这样的：
./src.cpp: In function ‘int main()’:
./src.cpp:4: error: ‘dsdada’ was not declared in this scope
-
<%@ page contentType="text/html;charset=UTF-8" %>
and this
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
但它也不起作用。 有人可以告诉我如何解决这个问题吗？感谢
/* String[0] as stdout, String[1] as stderr */
String[] results = sshBO.execCommand(cmd, timeout);
/* Done with SSH things */
sshBO.closeSession();
/* Bring the output and err to the presentation */
msg = results[1]+results[0];
FileServices.saveStringToFile("F:/myoutput.txt", msg);
msg = new String(msg.getBytes("UTF8"), "UTF8"); /* makes no difference */
JSP 页面：
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://sakaiproject.org/jsf/sakai" prefix="sakai" %>
<f:view >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
...
<h:inputTextarea disabled="true" value="#{SSH.msg}" styleClass="myTextArea" />
I'm developing a tool using JSF 1.1 and I'm having this problem :
I have a String in my backing bean which is printed as:
./src.cpp: In function ‘int main()’:
./src.cpp:4: error: ‘dsdada’ was not declared in this scope
on a txt file.
But when I put it on a h:inputTextArea, it goes like this:
./src.cpp: In function ‘int main()’:
./src.cpp:4: error: ‘dsdada’ was not declared in this scope
-
<%@ page contentType="text/html;charset=UTF-8" %>
and this
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
But it didn't work either.
can somebody tell me how to fix this. Thanks
/* String[0] as stdout, String[1] as stderr */
String[] results = sshBO.execCommand(cmd, timeout);
/* Done with SSH things */
sshBO.closeSession();
/* Bring the output and err to the presentation */
msg = results[1]+results[0];
FileServices.saveStringToFile("F:/myoutput.txt", msg);
msg = new String(msg.getBytes("UTF8"), "UTF8"); /* makes no difference */
on the JSP pages :
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://sakaiproject.org/jsf/sakai" prefix="sakai" %>
<f:view >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
...
<h:inputTextarea disabled="true" value="#{SSH.msg}" styleClass="myTextArea" />
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
字符
'存在于字节 0xE2 0x80 0x98 的 Unicode 中。当您使用 CP1252（Windows 默认）编码对这些字节进行编码时，您会得到’。您需要将
pageEncoding显式设置为 UTF-8。这样，它将使用 UTF-8 打印字符并隐式设置
Content-Type标头。The character
‘exist in Unicode of the bytes 0xE2 0x80 0x98. When you use the CP1252 (Windows default) encoding to encode those bytes, you get‘.You need to explicitly set the
pageEncodingto UTF-8.This way it will print the characters using UTF-8 and implicitly set the
Content-Typeheader right.为了确定转码错误的来源，请在每次转码操作后检查数据。使用类似这个的工具来确定值应该是。
例如，JSP 编写器正在将 Java 字符串从 UTF-16（Java 字符串的编码）转码为 UTF-8。其他转码操作看起来像是从本机系统读取程序输出。
例如，您可以使用如下代码打印字符串的十六进制值：
代码点
'应打印为2018。您的文件编写代码可能与读取输入的代码有类似的错误，从而误导您了解问题的根源。这没有什么区别，因为它获取 UTF-16 数据，将其转码为 UTF-8，然后将其转码回 UTF-16。但除此之外，如果您的字符串已损坏，那就已经太晚了。您正在错误的位置修复错误。
In order to determine the source of your transcoding bug, inspect the data after each transcoding operation. Use a tool like this one to determine what the values should be.
For example, Java strings are being transcoded from UTF-16 (the encoding of Java strings) to UTF-8 by your JSP writer. The other transcoding operation looks like reading program output from the native system.
For example, you can print the hex values of your strings using code like this:
The code point
‘should print as2018. Your file writing code may share a similar bug to the code that reads input, misleading you about the source of the problem.This makes no difference because it takes UTF-16 data, transcodes it to UTF-8, then transcodes it back to UTF-16. But aside from that, if your string is corrupt, it's already too late. You're fixing the bug in the wrong place.