Sorry, I should've been more clear.
The problem I'm experiencing is not that the headers aren't being properly set.
It's that UTF-8 in my source page is getting mangled. In this case, a copyright
symbol (©), while still rendered in the page, is preceded by a capital A with
an accent (not sure of the exact character) when finally rendered in Safari or
Somewhere in the long chain of processing, a conversion is happening.
On Aug 28, 2012, at 10:15 , Scott Ferguson <f...@caucho.com> wrote:
> On 08/27/2012 05:04 PM, Rick Mann wrote:
>> Oh, I can also put that empty page directive at the end of my include file,
>> and it also triggers the correct behavior.
> What, exactly isn't working? The parsing of the page? Or the
> content-type header?
> I just created a filter and JSP to reproduce this, and in all cases the
> res.setCharacterEncoding or res.setContentType is passed through to the
> -- Scott
>> On Aug 27, 2012, at 16:39 , Rick Mann <rm...@latencyzero.com> wrote:
>>> I'm trying to serve everything UTF-8. To this end, I wrote a request filter
>>> that sets the input and output encodings to UTF-8, and I've used that
>>> successfully in the past. I've been able to avoid putting a page encoding
>>> directive in each page.
>>> With resin 4.0.30, I'm seeing something odd. I only get the right behavior
>>> if the JSP page as an extra <%@ page %> at the top somewhere. The actual
>>> directive inside doesn't seem to matter. I had an import directive, but
>>> tried it without one and still got the right behavior.
>>> I also have, before that, at <%@ include directive, which must also be
>>> present. It includes the following:
>>> <%@ page contentType="text/html; charset=UTF-8" %>
>>> Without that, the resulting encoding isn't correct, either.
>>> What's odd is the empty page directive required to make it work.
>>> Any ideas?
>>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list