When I submit a jsp page and the request goes to a portlet controller, I want the french characters on the jsp page to be encoded always using UTF-8 in the portlet controller.
What is the code syntax that I need to use in jsp or portlet controller to ensure this?
For me works
<%# page language="java" import="java.util.*" pageEncoding="UTF-8"%>
in the top of the JSP
Related
I have a form that is sits in a plain .html file with the following meta tag:
<meta http-equiv="Content-Type" content="text/html; charset=shift_jis">
The service I'm posting a form to requires that the data is in shift-jis encoding. When I post this form by just opening this .html file with Chrome, then clicking a submit button, the service accepts it fine. When I inspect the post values in Fiddler, the Japanese characters appear in the post to the service like follows:
goods_name_1 = "���i�P"
Now when I take the exact same form and place it in an ASP MVC view, serve the view to Chrome with its source identical to the one I have in the .html file, view source looks exactly the same as the .html version opened did. But the problem is when I post the form with a submit button, the post values look like this:
goods_name_1 = "商品１"
The service then replies with an encoding issue.
Can anyone suggest what might be going wrong? The view served from ASP MVC has the response header "Content-Type:text/html; charset=utf-8". Im not sure why the post values aren't the same as the .HTML file version though. Any ideas?
Just to add, the .html file I have is saved as Unicode in windows.
Thanks.
Set the ContentEncoding of the response either in your Controller:
public ActionResult MyAction() {
Response.ContentEncoding = System.Text.Encoding.GetEncoding("shift_jis");
return View();
}
Or in the View:
#{
ViewBag.Title = "Home Page";
Response.ContentEncoding = System.Text.Encoding.GetEncoding("shift_jis");
}
I have a JSP page,In that page,I am trying to use the page scope attributes using jstl and struts2 tags.
The following piece of code is,
<%# taglib uri="/struts-tags" prefix="s" %>
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<c:set var="test" value="ramesh"/>
<c:set var="test1" value="${test}"/>
<s:set var="test2" value="${test}" />
the <s:set> tag yields the following exception " According to TLD or attribute directive in tag file, attribute value does not accept any expressions".
I have two questions.
1)${test} works when it is used in <c:set> tag.
2)${test} does not works when it is used in <s:set> tag. Why?
EL and JSTL are now in Java EE standards, so they can cooperate well, I think.
However, when in struts 2 tags, because struts 2 have their expression language - OGNL,
so I think they prefer to use OGNL to EL in their tags, and that is the reason why they do not support EL. These are my guess.
From Apache link
From Apache FAQ link
As of Struts version 2.0.9 the JSTL/JSP expression language (EL) has been disabled for Struts tag attributes which evaluate OGNL. This is a precaution against security vulnerabilities that can result from the double-evaluation that occurs when an attribute is first processed as a JSTL/JSP EL expression and then the result is processed as an OGNL expression. The solution is to express all dynamic attribute values in Struts tags using OGNL expressions directly.
I am using jsf 2. I have a link in a facelet file that points to a external url. My current view is /app1/home.xhtml with a h:commandLink that has an action like so
<h:commandLink value="#{link}" action="#{action.redirect}" target="_blank"/>
the url that action.redirect redirects to is /app2/info.do. However it appears that JSF tries to change the extension of the url to .xhtml. and then fails with the error message.
com.sun.faces.context.FacesFileNotFoundException: /app2/info.xhtml Not Found in ExternalContext as a Resource
how do i get this to correctly redirect ?
Don't use the <h:commandLink> here, it's the wrong tag for the purpose. It is designed to submit a JSF POST form and navigate to a JSF view, both which you obviously don't want to let take place in this particular use case.
Just use the <h:outputLink> or even plain HTML <a>. So,
<h:outputLink value="#{action.redirect}" target="_blank">#{link}</h:outputLink>
or
#{link}
Note that you don't need the <h:form> in both approaches.
the scenario is like this :
datepicker jquery ui in french needs the page to be encoded iso (because with utf , there are some french character that are not well displayed)
<%# page language="java" import="java.util.*" pageEncoding="ISO-8859-1"%>
and i have some arabic data that i need to store in the database, for this the page must be encoded in utf_8
<%# page language="java" import="java.util.*" pageEncoding="UTF-8"%>
data is sent via ajax
what to do ?
In this situation I believe you should always publish with UTF-8. But you need to make sure that all declared encodings agree. For example, for HTML, any encoding declared in a <meta> tag should agree with the actual Content-type HTTP header.
The only reason I can think of to publish in ISO-8859-1 instead of UTF-8 is if you have a client that you cannot change that requires this encoding. But even in that case, hopefully you would be able to use a User-Agent request header to identify this client and serve ISO-8859-1 only to that client.
I'm working in a jsf2 application and I have a problem with the page name displayed in the address bar. When I navigate to an other page I have in address bar the name of the previous page.
Thanks.
That's because you're using POST instead of GET for page-to-page navigation and JSF defaults to submitting to the very same view with you're using <h:form>. Using POST for page-to-page navigation is in any case a very poor approach. It's not only not user friendly (it's not bookmarkable and confusing), but it's also not SEO friendly (searchbots don't follow <form> actions).
To solve this problem, you must stop using <h:commandLink> for page-to-page navigation. Use <h:link> instead.
<h:link value="Go to next page" outcome="nextpage" />
This will just render a
Go to next page
Which is perfectly bookmarkable, user friendly and SEO friendly.
When you're navigating to a different page as result of a real POST form submit, I'd also replace that by returning null or void and just render the result/messages conditionally in the very same view. Or if the result is supposed to be bookmarkable (e.g. search results), you should use normal links or plain <form> instead of <h:form> and use <f:viewParam> in target view.
See also:
When should I use h:outputLink instead of h:commandLink?
This is happerning because, in JSF, when you are navigating to a new page the server is performing a forward to the new page. The browser is unaware of the forwarding and is displaying the old url. To make the server perform a redirect instead of forwarding, you have to either:
If you are using navigation rules, add a <redirect/> to each rule:
<navigation-rule>
<from-view-id>/pages/from.xhtml</from-view-id>
<navigation-case>
<from-outcome>to</from-outcome>
<to-view-id>/pages/to.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
If you are returning an outcome from a bean method, add a ?faces-redirect=true to the outcome:
public String navigate() {
return "/pages/to?faces-redirect=true";
}