JSF request parameter encoding struggles - jsf

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.

Related

PrimeFaces Extensions CKEditor: attempts to set encoding to UTF-8 unsuccessful

Why I am using this editor:
In the past I used PrimeFaces p:editor which is however deprecated and lacks functions that the users desperately want. I cannot use the new PrimeFaces p:textEditor because of this: Primefaces textEditor: converting text to HTML with JavaScript not working.
What is it used for:
I am using pe:ckEditor from PrimeFaces Extensions in my program, in which the editor is used by the user to create an e-mail message content. Then by click on a send button, the HTML from the editor is taken and sent via e-mail to a client.
What is the issue:
When using p:editor, I got the HTML by JavaScript function saveHTML and it worked perfectly even when the text contained Czech characters (ěščřžýáíéó), I did not even have to set enconding or anything else and it worked.
Now however when user writes "V případě dalších dotazů se na nás můžete obracet každý den na telefonním čísle", the gotten HTML has the text like this:"V pÅípadÄ dalších dotazů se na nás můžete obracet každý den na telefonním Äísle" - complete rubbish that the user obviously cannot send to a client...
My research:
EDIT: Based on some comments, I tried to add the <meta charset="utf-8> and <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> but that did not help. In pom.xml I have found also this <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>, so I do not think that there is a problem in the HTML page, but in settings of the editor itself...
So I figured, that the encoding must be set especially for the editor in its config. I finally figured how to make the editor access the custom config, but nothing that I found on the Internet and added to the config worked for me:
config.language='cs';
And:
config.entities_latin = false;
And:
config.entities = false;
And:
config.basicEntities = false;
And all its combinations.
ANOTHER EDIT:
Based on some other comments here, I also installed OmniFaces and tried to solve this by CharacterEncodingFilter, but nothing changed and it is still not working.
I also found out that my problem seems to be very related to this issue: Unicode input retrieved via PrimeFaces input components become corrupted, but the accepted answer there gives 3 ways how to solve it, one is the CharacterEncodingFilter, other way is not applicable for Tomcat users (me) and the last "solution" seems to be reporting this to PrimeFaces Extensions developers (which I did: https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/756 ).
Please let me know if you know how to fix this or if there is any workaround.
PrimeFaces Extensions - version 7.0.2;
PrimeFaces - version 7.0.7
I and my colleague found out what the issue was based on the test code that #melloware provided.
The original editor p:editor, which we had been using and which we are trying to replace by pe:ckEditor, could provide us with its content in HTML only in case we used JavaScript function saveHTML.
But with pe:ckEditor, anytime the user hit the Send button, whose onstart contained the saveHTML, the saveHTML corrupted the content. Once we erased the saveHTML and took the pe:ckEditor content as it was (which is already in HTML), it was fine without corrupted characters.

How to allow UTF-8 data in request received from Facelets page

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

Set request character encoding of JSF input submitted values to UTF-8 in GlassFish

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" />

Facelet does not convert formatted currency correctly

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.

Faulty pages created by SiteDefinition

I'm creating some pages using a SiteDefinition, the markup looks something like this:
<File Url="Page.aspx" Name="$Resources:SiteDefinitions,PageName;" Type="GhostableInLibrary">
<Property Name="Title" Value="$Resources:SiteDefinitions,PageTitle;" />
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx"></Property>
<AllUsersWebPart WebPartZoneID="WebPartZone1" WebPartOrder="1">
-- webpart data here
</AllUsersWebPart>
</File>
The page is created as expected, but it's somewhat faulty. If for instance I click Edit Page and then click Publish (without actually editing anything) I will get this error:
"This Page has been modified since you opened it. You must open the page again."
I will get this error approx. every second time I try an editing action.
If I manually create a page using the same page layout everything works as expected and this error does not show up.
Does anybody have an idea what could be wrong?
I too create a Page using the above method only thing I found missing in your code is that I used to have a title in the PageLayout as
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx, Your title"></Property>
This should not be the cause, but you can try it, Also refer the articles this or this
I think you're right with using PublishingLayoutPage. I came across this article today while searching for this error caused by something else. It describes your same issue although the person in the article was not inheriting from PublishingLayoutPage and had not specified the PublishingPageLayout property. When they fixed this it worked.
This doesn't directly help you, although I did notice in their article that they are specifying the ContentType property. Have you tried specifying this? As you can see your complete code, are there any other differences you see from the article or additional information from the comments?
Okay, I (kinda) got this working now.
The guy who had made the ONET.xml had put a reference to the page layout in the Url attribute of the element.
Like I wrote in a comment earlier I tried making the page layouts inherit from TemplateRedirectionPage. Instead I now made an empty default.aspx file that inherits from TemplateRedirectionPage and changed all my page layout files back to deriving from the PublishingLayoutPage. And then I added the PublishingPageLayout element below every element.
Funny, or oddly, having a refence to the page layout in the Url attribute and not having the PublishingPageLayout element at all is actually valid. It doesn't make sense, because it will produce these faulty pages, but SharePoint actually accepts it and spits out all the pages defined in the ONET.xml
Only thing left now is that since I made the above changes, when I manually create a new page based on a page layout every default webpart (as defined with AllUsersWebPart) is instantiated 5 times. Really don't know where this behaviour is coming from, but at least it's not as serious as not being able to edit/publish my pages :)

Resources