Hello I want to ask what can be the source of problem with bad encoding on the page.
This problem is very specific, because first part of page has good encoding and second part is broken.
Moreover it appears only in some scenarios, not allways.
The most weird thing is that starts to appear in the middle of one message and after this message, the rest of page has badly encoded characters.
This message is included in JSP with this part of code <fmt:message key="the.text.wchich.makes.problems"/>
Problem is not related to JSP, because bad encoding appears in the middle of message.
Gratulujeme, toto číslo si môžete zarezervovať kliknutím na tlačidlo Pokračovať.
But sometimes it outputs as
Gratulujeme, toto číslo si môžete zarezervovať kliknut�m na tlaÄidlo PokraÄovaÅ¥.
or
Gratulujeme, toto číslo si mô�¾ete zarezervovaÅ¥ kliknutÃm na tlaÄidlo PokraÄovaÅ¥.
So it is probably not the fault of badly entered text in database.
We are using Liferay 6.0, jsp, spring. Localized strings are stored in Oracle 11g database.
So, how is it possible that encoding begin to break in the middle of page?
You might need to specify encoding in your JSPs as:
<%# page contentType="text/html; charset=UTF-8" %>
You should be able to achieve the same result via CharacterEncodingFilter with forceEncoding parameter set and mapped to * path + INCLUDE dispatch.
This is just one suggestion. Try to set locale from themeDisplay object.
<fmt:setLocale value="<%=themeDisplay.getLocale() >"/>
see if it helps to fmt:message to identify proper locale of message.
Note: This expects that you should have proper locale set for user or at portal level.
Related
I have an html form:
<form>
<input type="hidden" id="hiddenField"/>
...Other form fields
</form>
In this form I want to set a hidden field with xml data.
Can anyone suggest if it is fine to set the hidden field directly with xml data.
i.e. in my javascript function is it safe to directly set the hidden field with xml like: $(#hiddenFiled).val(xml); and get the xml in my java servlet?Please suggest.
No you can't keep xml without encoding
You can opt either
var stringValue=escape(xml);
var xmlValue= unescape (stringValue)
in javascript
Though these methods has been depreciated in newer versions so you could find it in another library like http://underscorejs.org/#escapeUnderScoreJs
Also don't keep XML in hidden field if it holds andy sensitive information.
Hidden form fields are not for session tracking.
We have two mechanism for session tracking, they are cookies and URL rewriting, the latest for the people that doesn't have cookies enabled in their browsers, I could only understand sending a session id in a hidden field when you have your own session tracker and are not using the one that is already with your server container (HttpSession and all), but why re-invent the wheel?
Hidden fields are for passing information between pages, sometimes I use a and I clearly don't want that information displayed to the user
Posting XML without javascript or browser plugins is impossible. You should not send it directly as a form parameter. See this answer for more info:.
Use a library that would encode them while sending to server, and decode them at the server side.
Underscore.js provides such functionality. See the documentation:
escape_.escape(string)
Escapes a string for insertion into HTML, replacing &, <, >, ", `, and ' characters.
_.escape('Curly, Larry & Moe');
=> "Curly, Larry & Moe"
unescape_.unescape(string)
The opposite of escape, replaces &, <, >, ", ` and ' with their unescaped counterparts.
_.unescape('Curly, Larry & Moe');
=> "Curly, Larry & Moe"
However, do keep in mind that usually browsers have limits over the amount of data that you can send through GET request (around 255 bytes). Hence it's always a good option to use POST instead of GET even when sending encoded XML.
I'm having difficulties getting an html page to pick up a rupee symbol (₹), store it into an SQL Server 2016 database and then retrieve it for display.
Important to note here is that I need to enter the actual symbol not the html version.
The basic flow of the page is that an administrator can add a new currency to the application via a web interface. There is a text box where
they would enter the actual rupee symbol ₹ and hit submit. This then passes the parameters via an HttpServletRequest to a java back end.
The java backend just inserts/updates this value to a SQL Server 2016 table in a field nchar(10).
When the page is refreshed it runs a select against this table and displays all the valid currencies.
The problem is that when the java application retrieves from the HttpServletRequest request object the symbol ₹ becomes â?¹. I can see this in the
debugger, I appreciate that this might be due to my debugger not being able to display this so I go forward.
The java (jdbc) updates the field. I view the field using Sql Server Management Studio and it displays â?¹ in both text and grid view.
I know that SSMS can dispay this symbol as I can insert it directly and it works. So it looks like the information is lost at the html>java request.
The web page itself is legacy and built using xslt. I have added some more details below of where I'm up to.
The website runs on tomcat 8 and the pages are built using xslt, the back end is java.
In the front end I have a text field in an EditCurrency page. I enter ₹ in the symbol field and hit submit.
The relevent fragments of the xslt page that is used to build the the front end are:
<!--header indicates page is utf8-->
<xsl:param name="csrfToken"/>
<xsl:param name="currencyFormatError"/>
...
<!-- on submission the EditCurrency java class is called. method=POST indicates it should allow UTF8 request URL's as is my understanding-->
<form id="cmanager" name="cmanager" onsubmit="return(vNewCurrency())" action="../servlet/webpay.website.admin.EditCurrency" method="POST">
<input name="csrfToken" type="hidden" value="{$csrfToken}"/>
<table width="100%" cellpadding="0" cellspacing="0" border="0">
The tomcat 8 server's server.xml set to encoding UTF-8. I understand this allows the request/response to handle UTF-8:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" URIEncoding="UTF-8" />
Java class EditCurrency:
//Retrieves symbol from the HttpServletRequest req
//symbol returns â?¹
String symbol = (String) getParameter(PARAM_SYMBOL);
I've also tried to set the HttpServletRequest req using the following but it does nothing:
try {
req.setCharacterEncoding("UTF-8");
} catch (UnsupportedEncodingException ex) {
java.util.logging.Logger.getLogger(EditCurrency.class.getName()).log(Level.SEVERE, null, ex);
}
Sql Server:
Value â?¹ appears in the nchar(10) field.
Display html:
â?¹ is displayed when the screen is refereshed with this updated value.
So question is how do I fix this up!!??
I had considered some sort of reference table of all currencies and their display values etc but it doesn't seem correct way of doing it.
Unless every tool in the chain, including whatever you use to look at the intermediate results, is UTF-8 capable you will see garbage at some point.
The Unicode code point of the Rupee symbol is 0x20B9, which is UTF-8 encoded as three bytes 0xE2 0x82 0xB9. If you attempt to display that in a tool that uses ISO-8859-1 you see
0xE2 = â
0x82 = ? (there is no character in ISO-8859-1 for code 0x82, so you see a question mark)
0xB9 = ¹
So it appears the symbol is correct in the database, but you are displaying it incorrectly.
To "fix" this problem you must ensure that your tools are all set to UTF-8, and that the web server is configured to include the UTF-8 declaration in the HTML it sends.
I get html code from server to build freemarker.ftl.
Example:
Server return:
String htmlCode="<h1>Hello</h1>";
freemarker.ftl
${htmlCode}
except:Hello
actually: <h1>Hello</h1>
what can i do?
By default FreeMarker has no auto-escaping on, so it should print that value as HTML. But as it doesn't as you say, I can imagine two possibilities:
You are inside <#escape x as x?html>...</#escape>, or that was added to the template by a custom TemplateLoader. In that case, in 2.3.x you have to write <#noescape>${htmlCode}</#noescape>. (In 2.4 it will be much less verbose if everything goes as planned.)
That value was escaped before it reaches FreeMarker. So the template already gets <h1>Hello</h1> as the string.
My servlet is giving me a CSV file with chars like 'é', 'á' or 'õ'. When I open the servlet via browser, it works fine. But when the information get to my page, it's all �.
I tried changing the coding in the actual database, but it didn't work.
console.log(csv), where csv is the information from the servlet, and it's also full of '�'s.
I'm not even sure where the problem is, because the actual page has several latin characters which are presented properly.
I'm using Microsoft SQL '08, tried both nvarchar and varchar fields.
The server has to be instructed to use UTF-8 to decode the JSP output. This can on a per-JSP basis be done by
<%#page pageEncoding="UTF-8" %>
or on an application-wide basis by
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<page-encoding>UTF-8</page-encoding>
</jsp-property-group>
</jsp-config>
refer here for more.
What Ankur posted seems to fix most problems, but I would still have issues from time-to-time with encoding. I really hope you don't have to do this, but I was forced to make a little decode function to replace problematic characters (by using their '\u' code) with web-safe ones.
It seems that the encoding for the page is actually ISO-8859-1. While searching around stackoverflow for the terms mentioned by users I found this:
jQuery $.get() charset of reply when no header is set?
The error happens because there's no header whatever Ajax is getting, setting this up before the $.get command solves this:
$.ajaxSetup({
'beforeSend' : function(xhr) {
xhr.overrideMimeType('text/html; charset=ISO-8859-1');
},
});
Now, why is the server not configured for a more practical charset, I don't know.
I'm using x tag to parse through an xml that has special characters such as é Here is my xml
<stack>
<data title="thé"/>
</stack>
here is the xtag that prints out the output
<x:out select="#title" />
the view source of the page displays this output
theé
and visually this is displayed by the browser
theé
What am I doing wrong and how do I fix this issue?
Since the source view shows the character correctly, the problem is probably not with your JSTL XML tag expression. Instead, it might have to do with the content-type that the page is labeled with.
Single non-ASCII characters getting rendered as two characters (the first is typically an A with some sort of accent) is a pretty sure sign that UTF-8 content is getting treated as ISO-8859-1, or something similar. I'm not an expert in this area, but the browser needs to be told that the content you're serving is in UTF-8. So check the meta content-type of your output. It should specify UTF-8:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >