On 3/25/07, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas,
Thomas Peter Berntsen wrote:
> Yes, my perception is also that ISO-8859-1 is Tomcat's default encoding.
> Just to be sure I edited the index.jsp of the ROOT app in which I have
> created the "æøå.gif" file and changed the encoding to UTF-8, but with
> no different result.
Hmm... are you sure that you have the attribute correct? Note that it
should be URIEncoding, not URLEncoding. That single letter might be the
difference?
Yeah, you're right. That could have been a cause, but it doesn't seem
so in this case (I've pasted my connector further below).
I'm troubled that things didn't change. I only recently found the
URIEncoding setting myself, and it fixed all GET queries that involved
text. For instance, searching for "José" in a (GET) text field resulted
in the search string being echoed back as "Jos??" (the two question
marks were actually not ?? but two odd characters I don't recall).
Repeating the search with the bad echo would result in "Jos" + those two
weird characters doubled the number of weird characters, and so on.
Yes, in this case I've also created a JSP page with a form for test
purposes, and from that I can see whether or not a parameter sent
though the form using HTTP GET request shows correctly. Without the
URIEncoding="UTF-8" parameter the Danish special characters are not
echoed correctly, whereas _with_ the parameter everything in the
request is echoed correctly.
...But the directory listing seems unaffected, along with the direct
file requests which still return a 404.
I also tried to change the GET to a POST in the form, and that results
in characters getting misrepresented, no matter if the
URIEncoding="UTF-8" parameter is specified in the connector or not.
Setting URIEncoding="UTF-8" cleared that up completely, so that
searching for "José" not only works properly (the search didn't return
the correct records beforehand), but the search-term echo was also correct.
This is only an issue with GET requests since all POST encoding was
properly set to UTF-8.
Be absolutely sure you have your configuration correct. Can you
copy-and-paste your <Connector> just to be absolutely sure?
Absolutely, here you go:
<Connector port="8080" URIEncoding="UTF-8"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true"/>
Thanks.
- -chris
>
> Hmm... and did you still have URIEncoding="UTF-8" set in your
> <Connector>? Also, make sure that it's the right connector... Tomcat's
> default config file has a bunch of connectors that are commented-out.
>
>> Yup, and that's the funky part about it. I have tried many things:
>> - I have added the URIEncoding="UTF-8" to the correct connector (I
>> verified that it is the correct one by commenting it out).
>> - I have even changed the default directory listing to use an external
>> XSL file (http://tomcat.apache.org/tomcat-5.0-doc/default-servlet.html),
>> in which I have specified UTF-8 as encoding almost everywhere.
>
>> ...And also doing the opposite - specifying ISO-8859-1 everywhere I
>> could, also explicitly in the connector through
>> URIEncoding="ISO-8859-1"
>
>> I can verify that a sample JSP file that I have created works as
>> expected when the encoding is changed between UTF-8 and ISO-8859-1 in
>> the connector and in the page. And, as you mention, once UTF is
>> specified in the connector and the page, things work nicely with JSPs
>> (characters display correctly and corresponding to encoding chosen in
>> the browser and text within the JSP page.
>
>> But, unfortunately it doesn't have an impact on directory listings or
>> direct file access. As mentioned, I have tried running Tomcat
>> completely in UTF-8 and ISO-8859-1 mode to avoid mixups of encodings,
>> but without a different result.
>
>> However I noticed that the question marks, which display instead of
>> the expected characters in the directory listing, show up in my text
>> editor when displaying ISO-8859-1 encoded text as UTF-8. Then I
>> noticed that the encoding reported by my browser for the page showing
>> the directory listing is actually UTF-8, no matter what I attempt to
>> specify in the XSL, web.xml, connectors etc.
>
>> I also forced the external XSL file to render the directory listing as
>> XML instead of HTML, with ISO-8859-1 and UTF-8, respectively, but even
>> though the resulting page contained an explicit declaration that the
>> content is ISO-8859-1, my browser still reports it to be UTF-8.
>
>> I have no clue anymore. Could it be that somehow there is a deeper
>> cause than just what parameters can change and tuned? Something in the
>> source code that converts characters in the file names of files in the
>> file system to a UTF-8 representation of ISO-8859-1 characters?
>
>> Perhaps that's a little over the top but so is this issue :-(
>
>> Thanks for your help - it's greatly appreciated.
>
> -chris
>
>>
- ---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGBtZv9CaO5/Lv0PARApq/AJ43CU+QnzjdYPG1f6FvA7TKqp2eqQCgiFTD
IPYX+M86txbGp84IRtRVUaQ=
=SemQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
