Hi,
Apologies, my previous mail was missing a few things...
Correction -> Tomcat *does* show UTF-8 encoded data correctly (after fetching
from the database). It also saves UTF-8 encoded data correctly (I verified this
by looking at a saved record). However, the place where it fails is when I pass
UTF-8 data as a URL parameter to a popup screen.
In the attached screenshot, you can see that the main screen fetches and
displays UTF-8 data correctly but the popup screen (which pops up on clicking
the "Edit" button) shows garbled characters.
I checked the encoding on the popup screen and it does show me UTF-8. Am I
losing the encoding when constructing the URL string? Note that this all works
fine when I use ServletExec..
Fyi, the popup screen is launched via the following javascript code:
function editConfirmComment()
{
var form = document.frm_update;
var confirmComment = form.updComment.value;
var url = '../../fc3Common/view/externalCommentDetails.jsp?dummy=dummy'
+ '&confirmComment=' + encodeURIComponent(confirmComment);
popupWindow(url, 'ExternalCommentDetails', 480, 240);
}
Mark, in this case would I need to do as you said in your comments?
>>> If you are encoding your data in the URI, you will need to set the
>>> URIEncoding attribute on the coyote connector to "UTF-8" to ensure
>>> that the URI is decoded correctly.
>>> A clean Tomcat install should only require URIEncoding="UTF-8"
>>> to be added to the connector in server.xml for these to work
>>> for any UTF-8 data.
One issue is that my app would be hosted on a web farm. As the above looks to
be a server-wide change, it will affect other apps hosted on the instance too,
right?
Thanks and regards
Sanjay
Morgan Stanley
-----Original Message-----
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 12:27 AM
To: Tomcat Users List
Subject: Re: Tomcat 5.0.30 - UTF-8 encoding not working
Karanjkar, Sanjay V (IT) wrote:
> Hi msjava,
>
> I'm trying to migrate our webapp from ServletExec4.1.1/JDK1.3.1 to
> Tomcat5.0.30/JDK1.4.2.
> On ServletExec, our app was showing/saving UTF-8 strings correctly. However,
> after migration to Tomcat, the pages are not showing UTF-8 encoded content
> correctly.
If your are POSTing your data, request.setCharacterEncoding("UTF-8")
should do the trick but you MUST call this before any parameters are read.
If you are encoding your data in the URI, you will need to set the URIEncoding
attribute on the coyote connector to "UTF-8" to ensure that the URI is decoded
correctly.
> Do I need to do something else for Tomcat? In particular, do I need to
> do the stuff mentioned here:
> http://wiki.apache.org/jakarta-tomcat/Tomcat/UTF-8
1. Yes
2 & 3 - No . These might work under some circumstances but 2. is trying to
change a read-only property and 3. is hacking around the data not being handled
correctly in the first place.
When I am testing this, I use the following JSP to make sure Tomcat is
correctly configured. A clean Tomcat install should only require
URIEncoding="UTF-8" to be added to the connector in server.xml for these to
work for any UTF-8 data. You should test it with both method="post"
and method="get"
<%@ page contentType="text/html; charset=UTF-8" %> <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"> <html>
<head>
<title>UTF-8 test page</title>
</head>
<body>
<p>UTF-8 data posted to this form was:
<%
request.setCharacterEncoding("UTF-8");
out.print(request.getParameter("mydata"));
%>
</p>
<form method="post" action="index.jsp"
enctype="application/x-www-form-urlencoded">
<input type="text" name="mydata">
<input type="submit" value="Submit" />
<input type="reset" value="Reset" />
</form>
</body>
</html>
If this works, then the chances are your app isn't quite right. If you have a
test case that doesn't work (try and make it as simple as
possible) post it to the list and I'll take a look.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does
not waive confidentiality or privilege, and use is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
