Thanks for your help. I think I am beginning to understand what is happening ...and know what i will try. Just before I do, perhaps you could explain if all the browser client supports Windows-1250 ? inluding linux machines for example ????? on the client ?
Is there anything else I should watch out for when converting my database, from iso-8859 to utf-8. I presume this will only determine the way chars are stored in the database. and will not affect anything else..like for example how integers, or floats are stored ? thanks Ben -----Urspr�ngliche Nachricht----- Von: Allistair Crossley [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. September 2004 15:42 An: [EMAIL PROTECTED] Betreff: RE: ++ Best practive ?? ++ (JSP-->Servlet-->Database) character encoding. dear dear! this reminds me of when i was pulling my hair out for days 4 months back ;) are you saying that when you submit a form, the euro correctly goes into the database? make sure you are pulling out euro characters that are correctly encoded in the database .. have you tried entering a new row in the database with a euro character from your form or are you trying existing data? Is your database encoding UTF-8 or something else? you could just for the sake of it try <%@ page contentType="text/html;charset=ISO8859-15"%> <%@ page pageEncoding="ISO8859-15"%> it sounds to me like the encoding is still being switched incorrectly somewhere. ADC > -----Original Message----- > From: Ben Bookey [mailto:[EMAIL PROTECTED] > Sent: 01 September 2004 14:37 > To: Tomcat User List > Cc: Allistair Crossley > Subject: AW: ++ Best practive ?? ++ > (JSP-->Servlet-->Database) character > encoding. > > > > Hi Allistair, > > I have installed your filter and it seems to be working, and utf-8 is > processed on the server. > > > <%@ page language="java" > errorPage="MainIdentificationMainError.jsp"%> > <%@ page > import="java.lang.*,java.io.*,java.sql.*,javax.naming.*,javax. > sql.*,java.uti > l.Enumeration,java.util.*"%> > <%@ page import="com.gistec.webentrytool. > *,org.apache.torque.om.BaseObject,org.apache.torque.Torque,org > .apache.torque > .TorqueException,org.apache.torque.TorqueRuntimeException,org. > apache.torque > .util.Criteria,java.sql.*"%> > <%@ page session="true"%> > <%@ page contentType="text/html;charset=utf-8"%> > <%@ page pageEncoding="utf-8"%> > > But even when I use the above header in my jsp page, the euro > symbol is > displayed incorrectly (with a utf-8 display) > > I would appreciate any support. > > regards > > Ben > > > > > > > > > > -----Urspr�ngliche Nachricht----- > Von: Allistair Crossley [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 1. September 2004 10:50 > An: Tomcat Users List; [EMAIL PROTECTED] > Betreff: RE: ++ Best practive ?? ++ > (JSP-->Servlet-->Database) character > encoding. > > > We had to look at several areas: > > 1. JSP pageEncoding > > <%@ page contentType="text/html; charset=UTF-8" %> > > This ensures that the JSPs will display pretty much > everything. Actually, > our SQL Server database runs Latin1_General_CI_AS (which does > include euro). > 2. Database Connection URL > > jdbc:jtds:sqlserver://intratestgbr:1433/db_iQ;charset=Cp1252;TDS=7.0 > > We discovered that we _had_ to talk to the database using an > encoding it > understood. It turned out that Cp1252 was actually > Latin1_General_CI_AS, so > we make sure the character encoding is set on our database driver. > > 3. Request Character Encoding > > Taken from http://weblogs.java.net/pub/wlg/1078 > > Submitting information via a HTML form. Most browsers don't > appear to send > back a charset in the request that corresponds to the > encoding that was used > to format the page. In this case, the request character > encoding defaults to > ISO-8859-1 meaning that there's potentially a mismatch > between form data > being sent (in UTF-8) and information retrieved from the request (in > ISO-8859-1) using the getParameter() method on the > HttpServletRequest class. > To fix this, all you need to do is explicitly set the > character encoding of > the request before accessing data. > > request.setCharacterEncoding("UTF-8"); > > This is what the filter code I sent you does for all requests. > > I hope this clears up your issue! > > Alles gut, ich wuensche Dir Glueck! > > ADC. > > > > -----Original Message----- > > From: Ben Bookey [mailto:[EMAIL PROTECTED] > > Sent: 01 September 2004 09:37 > > To: Allistair Crossley > > Cc: Tomcat User List > > Subject: How to pre-determine the browser request character encoding > > type > > > > > > Hi Alistair, > > > > I hope you find time to do your work.... more questions :) > > > > Why should the IE client which is definitely reading/parsing as > > ISO-8859-15(i can see this in the IE menu bar), then post to > > the server > > converting the Euro to a questionmark . its rather stupid of > > IE isn't it, > > its definitely reading as ISO-8859-15 then posts anyway as > > ISO-8859-1 ? > > > > Could you explain in simple english, how the filter ensures > > that the request > > is in utf8 encoded. > > > > -----Original Message----- > > From: Ben Bookey [mailto:[EMAIL PROTECTED] > > Sent: 01 September 2004 09:37 > > To: Tomcat User List > > Cc: Allistair Crossley > > Subject: ++ Best practive ?? ++ (JSP-->Servlet-->Database) character > > encoding. > > > > > > > > Dear list, > > > > We have a web-based jsp-servlet application performing > > updates, deletes and > > inserts into an oracle database running with Tomcat 5. We > > want to support > > both > > american, and european customer client locales, so we want to > > use either > > ISO-8859-15 or utf-8. But we are having problems saving the > > Euro symbol when > > using ISO-8859-15 encoding. > > > > I had previously assumed that because java works with unicode > > as default, > > that all data entered in a HTML form would be saved therefore > > as UTF-8 into > > the database. (i.e. as soon as a value is assigned to the a > > java dataobject > > e.g. string or int). I am beginning to think this not to be > > case, and that > > all data is saved in the database based on the original > > encoding as posted > > by the browser. Please can someone explain what is really > > going on?? Do i > > need to have some code which, checks the browser encoding > in the HTTP > > header, and then convert/parse accordingly to a chosen > > standard. This will > > then avoid the situation that our database could end up > > containing records > > in different character encoding systems, which I suspect is > > what is now > > happening. > > > > In addition, how does TC deal with framsets containing many > > html pages. Are > > they all treated individually (in theory allowing many > > character encodings > > to be used in each HTML frame), or as one unit. > > > > I LOOK very much forward to any reply on this matter. > > > > Sincerely, > > > > > > Ben Bookey > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> > ------------------------------------------------------- > QAS Ltd. > Developers of QuickAddress Software > <a href="http://www.qas.com";>www.qas.com</a> > Registered in England: No 2582055 > Registered in Australia: No 082 851 474 > ------------------------------------------------------- > </FONT> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
