I have the follwing code inside a facelet page:
<h:inputNumber value="bean.property">
<f:convertNumber type="currency" />
</h:inputNumber
The converter is because there can be a kind of default value inside the input field, which comes from the bean property. Everything is rendered correctly. The value inside the input field is rendered with an "€" character (e.g. "1.453 €".
When I submit the form there comes an error up:
"nameOfInputField" konnte nicht als ein Geldbetrag erkannt werden '304,00 â¬'
In english it is some like:
"nameOfInputField" could not be regognized as an amount of money '304,00 â¬'
Please have a look at the "€" character. It seems to be printed as "â¬". While it was rendered correctly before submitting the form, now it looks like "â¬" inside the error message and inside the input field.
All pages are encoded in UTF-8.
What is the reason for this error?
How can fix it?
Thanks in advance
â¬
This is typical for the € from an original UTF-8 source which is incorrectly been decoded using ISO-8859-1. Here's a small snippet which demonstrates that:
System.out.println(new String("€".getBytes("UTF-8"), "ISO-8859-1"));
All pages are encoded in UTF-8.
You're likely talking about response encoding. You need to set the request encoding as well.
To set the encoding for GET requests (basically: URI encoding), you need to consult the appserver specific documentation. As it's unclear which one you're using, here's a Tomcat targeted example: <Connector URIEncoding="UTF-8" />. To set the encoding for POST requests, you need to create a simple filter which does request.setCharacterEncoding("UTF-8") if it is null. More background information and hints can be found in this article.
Put this ontop of your facelets page:
<?xml version="1.0" encoding="UTF-8" ?>
It will instruct the facelets parser.
Related
On our web application we've got different forms which nearly all have a encoding problem on text input fields.
When the input includes special characters like a Ͳ the value in the Bean of the site shows a question mark. Umlauts and accents eg. get to the Bean without any problem.
The sent request tracked with firebug looks fine. The header shows an UTF-8 charset:
application/x-www-form-urlencoded; charset=UTF-8
And the request-parameter gets displayed right:
formInputPanel:comment hello Ͳ
I googled a lot and most of the solutions I found tell me to implement a filter via the web.xml to set the right encoding for the request. The problem is when the filter is called the encoding is set right to UTF-8 but the parameter is already broken and shows hello ?
I also added following to lines to the system-properties of the JBoss without any results:
<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
This problem occurs on all pages except the login page. There the parameters get passed well to the Bean. The login page is implemented via a JSP-Page and a LoginServlet.
Maybe someone can give me a hint where else I can search for the problem.
Problem was solved through adapting the connection-url of the database connection in the JBoss configuration to:
jdbc:mysql://servername:3306/dbname?characterEncoding=UTF-8&useUnicode=true.
The encoding in the console output of the IDE wasn't UTF-8 encoded. So the request parameter were shown in the wrong encoding but the value was correct.
I would like to show code like primefaces showcase:http://www.primefaces.org/showcase/ui/datatableRowSelectionByColumn.jsf
i use SyntaxHighlighter
,when i include facelets file in pre tag, it work fine.But when i show short code like:<h:outputtext value="test"/>
i code:
<pre class="xml" name="code" ><h:outputtext value="test"/></pre>
it will display html code, the code after jsf compile and render.
i want jsf not compile to html code.
If i use html special character, it seem to be more verbose to code.
How to config or take more code to do that.
(Sorry for my English)
Thank for your attention !
When writing code directly inside the XHTML template, you really need to manually escape XML entities if you intend to present them as-is.
<pre class="xml" name="code"><h:outputtext value="test"/></pre>
Hard to read? Perhaps for a starter, but not for an advanced.
Alternatively, you could store them somewhere in a String which can if necessary be populated from a text (properties) file or even a DB.
String code = "<h:outputText value=\"test\" />";
(please note that you need to escape the doublequotes when you want to hardcode it as a Java String; you don't need to escape anything when it's stored in a text file or a DB)
Facelets will automatically escape it:
<pre class="xml" name="code">#{bean.code}</pre>
You need to exchange the < by < and > by >.
In else case it will be treated as HTML.
I am using JBoss AS 7. I created a Facelets page which is bound to a managed bean. I have JSF input text field in my page. If I write some special characters in input text field and submit the page, then it send a request to server. But special characters are already converted to some other characters. I added UTF-8 support tag in Facelets page, but I am still not getting UTF-8 data on server side. Do I need to add some settings on JBoss server so that it can accept UTF-8 data?
i Added a simple Text field
<h:inputText value="#{myBean.value}" />
and wrote text like this
"“ ©” ‘with special character’ — » É €"
i added a breakpoint on server and examined the value and i am getting something like this
â éâ âÂÂwith special characterâ â û àâ¬
I don't know how to get actual value on the server side
I have a problem with the values inserted in all my <h:inputText> fields. Some characters are not encoded in the right way. E.g. if I put ciò in the input field I get ciò.
How can I allow a user to insert text with those characters and save them correctly? The problem in not in the DB encoding since I already have the wrong value before inserting it in the DB.
I'm using JSF 2 with Facelets and GlassFish as application server.
You need to tell Glassfish to use UTF-8 to decode paramters instead of (default) ISO 8859-1. Add the following entry to the <glassfish-web-app> of your /WEB-INF/glassfish-web.xml file:
<parameter-encoding default-charset="UTF-8" />
Using Microsoft's AntiXssLibrary, how do you handle input that needs to be edited later?
For example:
User enters:
<i>title</i>
Saved to the database as:
<i>title</i>
On an edit page, in a text box it displays something like:
<i>title</i> because I've encoded it before displaying in the text box.
User doesn't like that.
Is it ok not to encode when writing to an input control?
Update:
I'm still trying to figure this out. The answers below seem to say to decode the string before displaying, but wouldn't that allow for XSS attacks?
The one user who said that decoding the string in an input field value is ok was downvoted.
Looks like you're encoding it more than once. In ASP.NET, using Microsoft's AntiXss Library you can use the HtmlAttributeEncode method to encode untrusted input:
<input type="text" value="<%= AntiXss.HtmlAttributeEncode("<i>title</i>") %>" />
This results in
<input type="text" value="<i>title</i>" /> in the rendered page's markup and is correctly displayed as <i>title</i> in the input box.
Your problem appears to be double-encoding; the HTML needs to be escaped once (so it can be inserted into the HTML on the page without issue), but twice leads to the encoded version appearing literally.
You can call HTTPUtility.HTMLDecode(MyString) to get the text back to the unencoded form.
If you are allowing users to enter HTML that will then be rendered on the site, you need to do more than just Encode and Decode it.
Using AntiXss prevents attacks by converting script and markup to text. It does not do anything to "clean" markup that will be rendered directly. You're going to have to manually remove script tags, etc. from the user's input to be fully protected in that scenario.
You'll need to strip out script tags as well as JavaScript attributes on legal elements. For example, an attacker could inject malicious code into the onclick or onmouseover attributes.
Yes, the code inside input boxes is safe from scripting attacks and does not need to be encoded.