Greetings, ppl.
It seems that WMS's GetFeatureInfo request is partially affected with
that default character encoding issue. When asking for GetFeatureInfo
with "info_format" of "text/plain", "text/html" or without specifying
output format at all (in that case format defaults to "text/plain"
which is a bit surprising for me; I would rather expect GML2 to be
a default one) I see those nasty question marks instead of cyrillic
letters.
I believe the above behavior is caused by the way in which `writeTo()`
method of
`org.vfny.geoserver.responses.wms.featureInfo.TextFeatureInfoResponse`
and
`org.vfny.geoserver.responses.wms.featureInfo.HTMLTableFeatureInfoResponse`
classes construct their PrintWriter object.
That looks like this:
public void writeTo(OutputStream out)
...
PrintWriter writer = new PrintWriter(out);
As stated by Sun's javadocs, OutputStream-based constructor of
PrintWriter "creates the necessary intermediate OutputStreamWriter,
which will convert characters into bytes using the default character
encoding".
I think it would be more appropriate not to rely on this automagical
conversion but construct OutputStreamWriter explicitly using the
character encoding from "services.xml" file. I.e. after replacing
PrintWriter writer = new PrintWriter(out);
with
OutputStreamWriter osw = new OutputStreamWriter(out,
getRequest().getGeoServer().getCharSet());
PrintWriter writer = new PrintWriter(osw);
in both TextFeatureInfoResponse.java and HTMLTableFeatureInfoResponse.java
the things are definitely straightens up 
`GmlFeatureInfoResponse` class is not affected by this since it is
aware of "charSet" configuration setting.
P.S. It is also slightly confusing to see that `TextFeatureInfoResponse` class
"Generates a map using the geotools jai rendering classes." as it is stated
in class' comments At least there are no clues in the code suggesting
such behavior 
--
WBR,
Artie Konin
Cool, thanks a ton for this. Can you start submitting these directly to
the task tracker?
http://jira.codehaus.org/secure/BrowseProject.jspa?id=10311 That would
help us out a bunch, as that's how we make sure to hit all the bugs for
each release. I put your last one in, hopefully will get to it this
weekend, or next week. Just sign up for an account, and you can submit
bugs directly - just copy and paste this message in. Doing so
additionally generates an email to the dev list, so everyone sees the
issue and can 'watch' it, be notified of updates as to when it is finally
resolved.
Best regards,
Chris
On Fri, 26 Nov 2004, Artie Konin wrote:
Greetings, ppl.
It seems that WMS's GetFeatureInfo request is partially affected with
that default character encoding issue. When asking for GetFeatureInfo
with "info_format" of "text/plain", "text/html" or without specifying
output format at all (in that case format defaults to "text/plain"
which is a bit surprising for me; I would rather expect GML2 to be
a default one) I see those nasty question marks instead of cyrillic
letters.
I believe the above behavior is caused by the way in which `writeTo()`
method of
`org.vfny.geoserver.responses.wms.featureInfo.TextFeatureInfoResponse`
and
`org.vfny.geoserver.responses.wms.featureInfo.HTMLTableFeatureInfoResponse`
classes construct their PrintWriter object.
That looks like this:
public void writeTo(OutputStream out)
...
PrintWriter writer = new PrintWriter(out);
As stated by Sun's javadocs, OutputStream-based constructor of
PrintWriter "creates the necessary intermediate OutputStreamWriter,
which will convert characters into bytes using the default character
encoding".
I think it would be more appropriate not to rely on this automagical
conversion but construct OutputStreamWriter explicitly using the
character encoding from "services.xml" file. I.e. after replacing
PrintWriter writer = new PrintWriter(out);
with
OutputStreamWriter osw = new OutputStreamWriter(out,
getRequest().getGeoServer().getCharSet());
PrintWriter writer = new PrintWriter(osw);
in both TextFeatureInfoResponse.java and HTMLTableFeatureInfoResponse.java
the things are definitely straightens up
`GmlFeatureInfoResponse` class is not affected by this since it is
aware of "charSet" configuration setting.
P.S. It is also slightly confusing to see that `TextFeatureInfoResponse` class
"Generates a map using the geotools jai rendering classes." as it is stated
in class' comments At least there are no clues in the code suggesting
such behavior
--