Checked the headers at 5.0.18, and as you said Content-Type is text/html. I don't use the i18n taglib, and I've tested 15 times that the difference is really between 14 and 16/18. Model is made up of Session Beans, which use Hibernate to get the data from a MaxDB database. In other words there is no relation between data access and my problem (which also relates to message resources). If anyone has a 5.0.16 or 18 up and running, adding a message resource containing a �, � or � and checking the result could confirm that this is not a single case. However, if it works with iso-8859-1, I really don't care (:
Thanks a bunch for the help! milx -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:24 PM To: Tomcat Users List Subject: Re: 5.0.16 and 5.0.18 international character support It probably also has alot to do with the JSTL i18n taglib. Are you using that? Or perhaps your database or JDBC driver? I would not assume that a minor version upgrade from 14 to 16 would produce such a major change. There would have been a massive outcry back then. Although 14 was still beta and 16 is production release, so perhaps not that many people did it. Did you check the http headers? On 02/20/2004 06:14 PM Trygve Hardersen wrote: > Correct, Context-Type is text/html. So what's the conclusion? Tomcat 5.0.14 > and international characters work fine with utf-8, for later versions use > iso-8859-1 or other? > milx > > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Friday, February 20, 2004 6:00 PM > To: Tomcat Users List > Subject: Re: 5.0.16 and 5.0.18 international character support > > The point is that the browser sees the HTTP response headers, even if it > doesn't display them, and it uses them to decide which charset to use to > display the page, regardless of your xml & meta declarations in the html > file. > > On 02/20/2004 05:57 PM Trygve Hardersen wrote: > >>I don't get the point of doing this. The problem is not request and >>response, but the way characters are displayed. >> >>Changed the charset to western European, charset=iso-8859-1, and now >>everything works fine. >>milx >> >>-----Original Message----- >>From: Antonio Fiol Bonn�n [mailto:[EMAIL PROTECTED] >>Sent: Friday, February 20, 2004 5:33 PM >>To: Tomcat Users List >>Subject: Re: 5.0.16 and 5.0.18 international character support >> >>What Adam said was: >>Look in the response headers to see it. >> >>I think he *really* meant the response headers, not the html code. >> >>To do that on IE, you need a plugin called ieHTTPheaders or something like >>that. >> >>On Netscape/Mozilla, use LiveHTTPHeaders. >> >>Otherwise, if you are not on HTTPS, you can use a network sniffer. >> >> >>Antonio Fiol >> >> >>Trygve Hardersen wrote: >> >> >> >>>Thanks for the reply. Project never ran on 4.x, developed on 5.x starting >> >>>from 5.0.14. Using JSTL 1.1. >> >> >>>5.0.14: >>><?xml version="1.0" encoding="UTF-8"?> >>><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> >>><html xmlns="http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> >>><meta http-equiv="Content-Type" content="application/xhtml+xml; >>>charset=utf-8" /> >>> >>>5.0.18: >>><?xml version="1.0" encoding="UTF-8"?> >>><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> >>><html xmlns="http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> >>><meta http-equiv="Content-Type" content="application/xhtml+xml; >>>charset=utf-8" /> >>> >>>That is equal. However, the characters ��� are in plain text in the page, >>>but IE displays them incorrectly. I can't find any difference in the > > source > >>>of the pages between 5.0.14 and later, which makes me wonder if the > > problem > >>>is IE oriented. Thing is though, that IE displays everything correct on >>>5.0.14..... Installing Netscape now, Opera does not support xhtml with >>>script elements. Idea? >>> >>>milx >>> >>>-----Original Message----- >>>From: Adam Hardy [mailto:[EMAIL PROTECTED] >>>Sent: Friday, February 20, 2004 2:43 PM >>>To: Tomcat Users List >>>Subject: Re: 5.0.16 and 5.0.18 international character support >>> >>>On 02/20/2004 01:17 PM Trygve Hardersen wrote: >>> >>> >>> >>> >>>>I'm having a silly problem with 5.0.16 and 5.0.18, regarding the >>>>Scandinavian characters �, � and � (probably others to). I've developed a >>>>project using tomcat and struts, where both message resources and actual >>>>data in the database contain these characters. Using 5.0.14 and prior, >>>> >>>> >>> >>>I've >>> >>> >>> >>> >>>>not paid attention to the characters; just used plain text for both >>>>resources and data. This has worked out just fine, regardless of user >>>> >>>> >>> >>>locale >>> >>> >>> >>> >>>>(and thereby the lang option of the page), the characters have been >>>> >>>> >>> >>>rendered >>> >>> >>> >>> >>>>properly. Attempting to stay up-to-date, I upgraded to 5.0.16 and later >>>>5.0.18, but now the characters are Chinese-like (unreadable for a >>>>Scandinavian). Anyone knows the cause of this? >>>> >>>>The pages are all UTF-8, xhtml and there is no difference in handling of >>>>message resources and model data. >>>> >>>> >>> >>>Are you sure about that? Could it be that you actually did have this >>>problem with tomcat 5.0.x but just didn't notice? When did you upgrade >> >>>from tomcat 4.x? >> >> >>>There are issues going from tomcat 4 to 5 that could affect this, but >>>none that I know of, just from 5.0.14 -> 16. >>> >>>Check the character encoding of your pages in the browser. Look in the >>>response headers to see it. What is it & what do you want it to be? >>> >>>Adam >>> >>> >>> >>> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
