encoding problem

[Nikola Stefanovski]

hello.

i'm working with cyrillic characters and i can't get them to show ok.
i'm working on win2000 and i've tried tomcat versions 3.2.3, 3.3a and 4.0.1.
the page directive is specified as:

<%@ page contentType="text/html; charset=windows-1251"
pageEncoding="windows-1251"%>

this makes the static content of the jsp appear correctly, but the strings
retrieved  through an expression (<%=bean.getString()%>) are just
question-marks. if i take out the page attribute, the browser shows some
funny characters as it doesn't recognise the encoding. but if i then switch
to cyrillic (windows) encoding manually, everything appears fine.
i can't figure out where the catch is, any help?

i'm sorry if this has already been an issue on the list, but i could not
find an answer in the archive.

greetings,

nikola.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Encoding problem (?)

[Ferrari Massimo]

Hi all,
I have troubles trying to start timcat 4.0.2 on win2k.
I get this error

ERROR reading java.io.ByteArrayInputStream@704baa
At Line 20 /web-app/servlet-mapping/

when tomcat tries to read my web.xml file (attached)
I tried to convert this file to UNIX, UTF, ... but without success.
Thank you in advance
Massimo




web.xml
Description: Binary data

--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

encoding problem

[santhosh]

Hello all,

I am using struts in our project. application server is JBOSS with Tomcat as servlet 
container.  If i set contenet type ans UTF-8 
(<%@ page contentType="text/html;charset=UTF-8"%>) in jsp i am getting the following 
error.

org.apache.jasper.JasperException: null(-1,-1) Cannot read file: ze file

if i use other charset like EUC-JP  or  Shift-jis  its working fine.  Can i get some 
solution how to solve this problem.

waiting for the reply




Thanx with regds
santhosh hegde A

Character Encoding problem

[Nehemia Litterat]

Hi 

I am using tomact 4.0.4 and JDK1.3.1

I am trying to read parameter in hebrew from the URL but get '???' writing Hebrew to 
the browser works fine

I can not use req.setCharacterEncoding(java.lang.String env) (can not compile the code 
when I am using it)

is there a way to go around it. I am very flexiable in choosing the JDK and TOMCAT 
version to work with but they need to be release version and not beta or something 
like this 

Thanks in advance

Nehemia Litterat

 



-
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes

Re: encoding problem

[Nikola Milutinovic]

Nikola Stefanovski wrote:

> hello.
> 
> i'm working with cyrillic characters and i can't get them to show ok.
> i'm working on win2000 and i've tried tomcat versions 3.2.3, 3.3a and 4.0.1.
> the page directive is specified as:
> 
> <%@ page contentType="text/html; charset=windows-1251"
> pageEncoding="windows-1251"%>
> 
> this makes the static content of the jsp appear correctly, but the strings
> retrieved  through an expression (<%=bean.getString()%>) are just
> question-marks. if i take out the page attribute, the browser shows some
> funny characters as it doesn't recognise the encoding. but if i then switch
> to cyrillic (windows) encoding manually, everything appears fine.
> i can't figure out where the catch is, any help?

Sounds like you got something wrong in the database part of your web 
application. From what you've said, I can only conclude that what your 
JSP/Servlet reads is a totally incorrect string.

Java supports only UNICODE, as it's internal character encoding. So, if you have 
an architecture like this:

RDBMS <-> JDBC <-> JRE <-> Tomcat <-> Servlet(JSP) <-> HTTP

then JDBC must read characters INTO the Unicode encoding. ServletResponse class 
will translate Unicode into specified HTTP encoding. Given your description of 
the problem, I'd say you have CP-1251 encoded text that gets just pasted into 
Unicode. This is irregular, since CP-1251 is not getting translated into proper 
Unicode characters. I'd say you have wrong setup of your DB.

I've had similar problems with PostgreSQL and Tomcat, my data was CP-1250 and I 
was forcing it as Unicode. My problems went away when I translated CP-1250 into 
Unicode on the DB side and set DB encoding to UTF-8. I believe things would be 
OK if I switched to any other supported encoding of the DB.

I'd say you have the same problem as I did - DB was of one encoding and data of 
the other.

Nix.

P.S. I'm on a vacation for the next ten days, so I won't be answering my mails.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Response encoding problem

[Dragomir Denev]

Hi all,

I have a simple servlet that retrieves a string from the database via jdbc.
The database is sybase and its default encoding is utf-8. I run tomcat
with -Dfile.encoding=iso-8859-7 option. In the servlet I do a
System.out.println() for the string and on the console I get the correct
greek symbols. But when I send the string via the response object I get
trash in the browser. The servlet looks like this:

...
 response.setContentType("text/html; charset=iso-8859-7");
 PrintWriter out = response.getWriter();
 out.println(str);
 System.out.println(str);
...

If I don't use the -Dfile.encoding=iso-8859-7 option the I get question
marks in the console and in the browser.
Can somebody help me with this? 10x in advance.

D.Denev


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

character encoding problem

[Winter, Wolfgang]

hi,

since two weeks I'm fighting with a character encoding problem without
success: I send a JSP form to a Tomcat 4.03 servlet and log the form input
with log4j into a file and into a database. Running on a german server with
Suse Linux everything works fine. Now I installed Tomcat and servlet on a
Slackware server in the US and all special characters are logged as a
question mark. I tried everything I could get hands on in the mailing list
archive, without success:

- <%@ page contentType="text/html;charset=iso-8859-1" %> in the JSP

-  in
the JSP

- start tomcat with CATALINA_OPTS=-Dfile.encoding=iso-8859-1

- set environment variables LC_ALL=de;export LC_ALL and LANG=de;export LANG
(locale -a on slackware yields de, deutsch or german)

- request.setCharacterEncoding("iso-8859-1"); as first statement in
servlet.doPost()

- convert form parameters like: 
 byte[] bytes = param.getBytes("iso-8859-1");
 String convertedParam = new String( bytes, "iso-8859-1" );

I tried everything with iso-8859-1 and with UTF-8. 
With a perl script I have no problems handling the form input, so it must be
a Java/Tomcat problem. What else could I do to change the platform's default
encoding? 

please help
Wolfgang




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Page encoding problem

[Nikola Milutinovic]

Hi all. I'm having a bit of an page encoding problem. I'm trying to use 
ISO-8859-2 (a.k.a. Latin-2) page encoding and something is going wrong.

I have a page that wascreated first as HTML, with ISO-8859-2 encoding. This page 
displays OK under Dreamweaver 4 and web browsers.

Then I added JSP directives and converted it to a JSP page. The problem is that 
all text characters specific to our alphabet, from Latin-2 extended ASCII set, 
are displayed as "?".

The question mark is not browser's inability to display something - it is really 
a "?". Why is this happening?

What is more disturbing is that all data in my database, which is correctly 
entered both with LATIN2 and UNICODE encodings (I have two databases under 
PostgreSQL) also exibits this behaviour.

Could this be JDK issue? Could it be connected to i18n (internationalization) 
support under my OS.

I find it hard to believe that BOTH PostgreSQL JDBC driver AND Tomcat are at 
fault here. Any help?

OS: Digital UNIX 4.0D on Alpha
JDK/JRE: DEC/Compaq JDK 1.3.0 for Digital UNIX/Alpha
Tomcat: 4.01
Database: PostgreSQL 7.1.3

TYIA,
Nix.



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Encoding problem (?)

[Alexander Höglind]

Hi Massimo,
Maybe this solves your problem.
Any servlet-mapping or filter-mapping URL must begin with a "/".  
/MyURL

Alexander Höglind
[EMAIL PROTECTED]

- Original Message - 
From: "Ferrari Massimo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 19, 2002 11:41 AM
Subject: Encoding problem (?)


> Hi all,
> I have troubles trying to start timcat 4.0.2 on win2k.
> I get this error
> 
> ERROR reading java.io.ByteArrayInputStream@704baa
> At Line 20 /web-app/servlet-mapping/
> 
> when tomcat tries to read my web.xml file (attached)
> I tried to convert this file to UNIX, UTF, ... but without success.
> Thank you in advance
> Massimo
> 
> 





> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Character Encoding Problem

[atumer]

Hi,

I know that this is a popular (!?) problem in tomcat. Dur despite my efforts I could 
not find any solution. Here it goes:

We have jsp page in encoding type ISO-8859-9. With the line
<%@ page contentType = "text/html; charset=ISO-8859-9" %>
we define the encoding type of the document.

Result:
The strings in the jsp file are encoded correctly, like
- The text in html
- the text written inside jsp code between <%, %>

Problem:
The strings that are recevied from a class, read from a file, inside a constant are 
not encoded correctly.

<%= "Pretend to be a ISO8859-9 string" %> is encoded correctly but,
inside a class let's say we have
String x = "Pretend to be a ISO8859-9 string";
then
<%= myClass.c %> is encoded wrong with many ?'s

The problem is not in JVM/JDK, I think, as I read a file and write the content into 
another file, both files are the same with no loss in encoding.

Also the encoding problem is there when I include files with

lame,encoding problem

[bwasko]

Hi
I have a strange problem. 
On my jsp pages use utf-8 encoding. Because of problems in my struts application I use 
the tomcat-example-encoding-filter and set it in web.xml to utf-8 and to processing 
all requests . It works , tomcat starts normally . When I submit a form i can get the 
request parameters properly encoded and properly write them with for example 
System.out.print().
But then when I do something with these parameters and my mysql database I get then 
them wrong encoded and all data read from mysql are wrong encoded .
What is wrong???
I use MS Windows XP and tomcat 4.1.29
My Locale is pl_PL.
Cheers Bartek Waśko

Turkish encoding problem

[Metin Zavrak]

Hi,
I am working on a project in which I use XML files.
I wrote an JavaServlet which reads an XML and an XSL file and creates an 
HTML file.
My XML and XSL files contain Turkish characters (Turkish encoding is 
ISO-8859-9).
These characters are displayed as a question mark (?).

I have tried many solutions but couldn't fix the problem.
I attached the codes so that you can see what is going on.
I am using   Windows XP
  Java 1.4.2_03
  Xalan-Java 2.5
  Xerces-J 1.4.4
  Tomcat
 
   





http://www.w3.org/2001/XMLSchema-instance"; 
xsi:noNamespaceSchemaLocation="D:\Tomcat\webapps\book\WEB-INF\source\xml\kategori.xsd">

isletim sistemleri
100

Unix
100


Linux
101






http://www.w3.org/1999/XSL/Transform";>



:::LeoFibo.NET:::









 
   
   
   
 


 	
   Leofibo.NET	
 



  
  
  ARAMA 
  ISBNBaslik
  
  
  
 



  

 


 

 













]>
http://www.w3.org/1999/XSL/Transform"; version="1.0">










kategori_browse?id=
 :: 

Arabic encoding problem

[vijaya prasad pala]

Hi

i am reading arabic text from oracle database.
if i am displaying that text in that page it ok.
if i am passing the same arabic string to another page
then in that page it is displaying in ?. 
i tried like this

 if(request.getCharacterEncoding()==null)
request.setCharacterEncoding("windows-1256");
  
  linkString = request.getParameter("linkLine");
  userString = request.getParameter("userLine");

Here my problem is passing string from one page to
another page... 

Thanks in Advance
vijay


__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character Encoding problem

[Fabio Mengue]

Perhaps something like this is /bin/setclasspath.sh

JAVA_OPTS="-Dfile.encoding=ISO-8859-1"

(with you ISO configuration, of course).

Fabio.

Nehemia Litterat wrote:

>Hi 
>
>I am using tomact 4.0.4 and JDK1.3.1
>
>I am trying to read parameter in hebrew from the URL but get '???' writing Hebrew to 
>the browser works fine
>
>I can not use req.setCharacterEncoding(java.lang.String env) (can not compile the 
>code when I am using it)
>
>is there a way to go around it. I am very flexiable in choosing the JDK and TOMCAT 
>version to work with but they need to be release version and not beta or something 
>like this 
>
>Thanks in advance
>
>Nehemia Litterat
>
> 
>
>
>
>-
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>  
>

-- 
Fabio Mengue - Centro de Computacao - Unicamp
[EMAIL PROTECTED]   [EMAIL PROTECTED]
"Quem se mata de trabalhar merece mesmo morrer." - Millor



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Character Encoding problem

[Bill Barker]

"Nehemia Litterat" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> Hi
>
> I am using tomact 4.0.4 and JDK1.3.1
>
> I am trying to read parameter in hebrew from the URL but get '???' writing
Hebrew to the browser works fine
>
> I can not use req.setCharacterEncoding(java.lang.String env) (can not
compile the code when I am using it)
>

This is almost certainly due to having an older version of servlet.jar in
your classpath.  One especial got-ya is to have on older version of j2ee.jar
and/or servlet.jar in $JAVA_HOME/jre/lib/ext.  If this is the case, kill it.
Otherwise, try compiling with:
javac -classpath $CATALINA_HOME/common/lib/servlet.jar:$CLASSPATH
MyServlet.java

> is there a way to go around it. I am very flexiable in choosing the JDK
and TOMCAT version to work with but they need to be release version and not
beta or something like this


Tomcat 3.3.1 has excellent charset support, especially if you are willing to
use it's non-portable features.

However, once you solve your compilation problem, 4.x should do everything
that you need it to do (and portably as well :).

> Thanks in advance
>
> Nehemia Litterat
>
>
>
>
>
> -
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Character Encoding problem

[Irina Lishchenko]

On Wednesday 28 August 2002 13:17, you wrote:
> Hi
>
> I am using tomact 4.0.4 and JDK1.3.1
>
> I am trying to read parameter in hebrew from the URL but get '???' writing
> Hebrew to the browser works fine
>
> I can not use req.setCharacterEncoding(java.lang.String env) (can not
> compile the code when I am using it)
>
> is there a way to go around it. I am very flexiable in choosing the JDK and
> TOMCAT version to work with but they need to be release version and not
> beta or something like this
>

You can use followed form just with right encoding for you, W3C has foreseen 
the atribute accept-charset for element/tag form. Then your request object 
will have right encoding too



~~~
...



ilis

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Response encoding problem

[Ryszard Lach]

On Wed, Oct 16, 2002 at 05:41:58PM +0200, Dragomir Denev wrote:
> Hi all,
> 
> I have a simple servlet that retrieves a string from the database via jdbc.
> The database is sybase and its default encoding is utf-8. I run tomcat
> with -Dfile.encoding=iso-8859-7 option. In the servlet I do a
> System.out.println() for the string and on the console I get the correct
> greek symbols. But when I send the string via the response object I get
> trash in the browser. The servlet looks like this:
> 

Did you try:

-Djavax.servlet.request.encoding=ISO-8859-7 

???

BTW: I didn't know there is -Dfile.encoding switch recognized by Tomcat.
I hope it will solve my problems with encoding during file or tcp socket
print ;-))

Richard.

-- 
"First they ignore you. Then they laugh at you. Then they
fight you. Then you win." - Mohandas Gandhi.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Response encoding problem

[Ryszard Lach]

On Wed, Oct 16, 2002 at 06:06:02PM +0200, Ryszard Lach wrote:
> On Wed, Oct 16, 2002 at 05:41:58PM +0200, Dragomir Denev wrote:
> > Hi all,
> > 
> > I have a simple servlet that retrieves a string from the database via jdbc.
> > The database is sybase and its default encoding is utf-8. I run tomcat
> > with -Dfile.encoding=iso-8859-7 option. In the servlet I do a
> > System.out.println() for the string and on the console I get the correct
> > greek symbols. But when I send the string via the response object I get
> > trash in the browser. The servlet looks like this:
> > 
> 
> Did you try:
> 
> -Djavax.servlet.request.encoding=ISO-8859-7 
> 
> ???
> 
> BTW: I didn't know there is -Dfile.encoding switch recognized by Tomcat.
> I hope it will solve my problems with encoding during file or tcp socket
> print ;-))
> 

Well, file.encoding does not change anything in my installation.

R.

-- 
"First they ignore you. Then they laugh at you. Then they
fight you. Then you win." - Mohandas Gandhi.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Response encoding problem

[Dragomir Denev]

10x, but this doesn't solve my problem since I don't want to encode the
request, but the response (it doesn't work anyway, I've tried it).

-Original Message-
From: Ryszard Lach [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 6:29 PM
To: Tomcat Users List
Subject: Re: Response encoding problem


On Wed, Oct 16, 2002 at 06:06:02PM +0200, Ryszard Lach wrote:
> On Wed, Oct 16, 2002 at 05:41:58PM +0200, Dragomir Denev wrote:
> > Hi all,
> >
> > I have a simple servlet that retrieves a string from the database via
jdbc.
> > The database is sybase and its default encoding is utf-8. I run tomcat
> > with -Dfile.encoding=iso-8859-7 option. In the servlet I do a
> > System.out.println() for the string and on the console I get the correct
> > greek symbols. But when I send the string via the response object I get
> > trash in the browser. The servlet looks like this:
> >
>
> Did you try:
>
> -Djavax.servlet.request.encoding=ISO-8859-7
>
> ???
>
> BTW: I didn't know there is -Dfile.encoding switch recognized by Tomcat.
> I hope it will solve my problems with encoding during file or tcp socket
> print ;-))
>

Well, file.encoding does not change anything in my installation.

R.

--
"First they ignore you. Then they laugh at you. Then they
fight you. Then you win." - Mohandas Gandhi.

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Encoding Problem on Tomcat4.0

[jacob]

Can I change the default encoding "ISO-8859-1" to "BIG-5".

Thanks,
Jacob

Re: Page encoding problem

[Micael Padraig Og mac Grene]

At 08:57 PM 12/3/01 +0100, you wrote:
>Hi all. I'm having a bit of an page encoding problem. I'm trying to use 
>ISO-8859-2 (a.k.a. Latin-2) page encoding and something is going wrong.
>
>I have a page that wascreated first as HTML, with ISO-8859-2 encoding. 
>This page displays OK under Dreamweaver 4 and web browsers.

It is impossible to say what you are doing wrong if you do not include your 
code.  I use full internationalization on all my jsp pages with no 
problem.  But, I don't know what your "encoding" code is.

-- micael


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Page encoding problem

[Nikola Milutinovic]

> It is impossible to say what you are doing wrong if you do not include your 
> code.  I use full internationalization on all my jsp pages with no 
> problem.  But, I don't know what your "encoding" code is.

I'll have to get back to you - it started working.

The "only" thing I did was set UNIX LOCALE to sl_SI.ISO8859-2. The funny thing is it 
is not beahving like ISO-8859-2 is the default encoding. It is still ISO-8859-1, but 
now when I set contentTpe to "text/html; charset=ISO-8859-2" the page displays OK. 
Looks like DEC's JVM is nailed to ISO-8859-1 *if the LOCALE is set to "C"*. If it is 
set to something from the i18n "menu", other encoings, localizations, etc. kick in.

Shucks! I just waisted a couple of weeks on that matter...

Nix.

Re[2]: Encoding problem (?)

[Jacob Kjome]

Hello Alexander,

That isn't true,

How about this?



jsp
*.jsp


That is the standard way to map any file ending in .jsp and this is
pulled straight from Tomcat-4.x.x conf/web.xml.  Do you see a
prepended "/"?  I don't.

Jake

Thursday, April 25, 2002, 1:39:09 PM, you wrote:

AH> Hi Massimo,
AH> Maybe this solves your problem.
AH> Any servlet-mapping or filter-mapping URL must begin with a "/".  
/MyURL

AH> Alexander Höglind
AH> [EMAIL PROTECTED]

AH> - Original Message - 
AH> From: "Ferrari Massimo" <[EMAIL PROTECTED]>
AH> To: <[EMAIL PROTECTED]>
AH> Sent: Friday, April 19, 2002 11:41 AM
AH> Subject: Encoding problem (?)


>> Hi all,
>> I have troubles trying to start timcat 4.0.2 on win2k.
>> I get this error
>> 
>> ERROR reading java.io.ByteArrayInputStream@704baa
>> At Line 20 /web-app/servlet-mapping/
>> 
>> when tomcat tries to read my web.xml file (attached)
>> I tried to convert this file to UNIX, UTF, ... but without success.
>> Thank you in advance
>> Massimo
>> 
>> 


AH> 


>> --
>> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
>> For additional commands: <mailto:[EMAIL PROTECTED]>
>> Troubles with the list: <mailto:[EMAIL PROTECTED]>


AH> --
AH> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
AH> For additional commands: <mailto:[EMAIL PROTECTED]>
AH> Troubles with the list: <mailto:[EMAIL PROTECTED]>



-- 
Best regards,
 Jacobmailto:[EMAIL PROTECTED]


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Character Encoding Problem

[Tõnu Põld]

Hi,

You should compile the java classes with ISO-8859-9 encoding.
Look at the -encoding flag of the 'javac' compiler.

In compilation the 8-byte characters in strings are converted to unicode
characters.
By default the encoding is probably ISO-8859-1.

Regards,
Tõnu


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 10:33 AM
> To: [EMAIL PROTECTED]
> Subject: Character Encoding Problem
> 
> 
> Hi,
> 
> I know that this is a popular (!?) problem in tomcat. Dur 
> despite my efforts I could not find any solution. Here it goes:
> 
> We have jsp page in encoding type ISO-8859-9. With the line
> <%@ page contentType = "text/html; charset=ISO-8859-9" %>
> we define the encoding type of the document.
> 
> Result:
> The strings in the jsp file are encoded correctly, like
> - The text in html
> - the text written inside jsp code between <%, %>
> 
> Problem:
> The strings that are recevied from a class, read from a file, 
> inside a constant are not encoded correctly.
> 
> <%= "Pretend to be a ISO8859-9 string" %> is encoded correctly but,
> inside a class let's say we have
> String x = "Pretend to be a ISO8859-9 string";
> then
> <%= myClass.c %> is encoded wrong with many ?'s
> 
> The problem is not in JVM/JDK, I think, as I read a file and 
> write the content into another file, both files are the same 
> with no loss in encoding.
> 
> Also the encoding problem is there when I include files with
>  If I include the file with <%@ include .. the problem is
> not there .. But I really need to use  
> Can anyone solve my problem ?? ..
> 
> Arif Tumer ..
> 

İlgi:RE: Character Encoding Problem

[atumer]

> Kimden: Tõnu Põld <[EMAIL PROTECTED]>
> Tarih: 2001/07/02 Mon AM 10:48:10 GMT+03:00
> Kime: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Konu: RE: Character Encoding Problem
> 
> Hi,
> 
> You should compile the java classes with ISO-8859-9 encoding.
> Look at the -encoding flag of the 'javac' compiler.
> 
> In compilation the 8-byte characters in strings are converted to unicode
> characters.
> By default the encoding is probably ISO-8859-1.
> 
> Regards,
> Tõnu
> 

I tried, a few minutes ago, but the problem remains. I don't
know the usage of -encoding parameter in detail but,
I think it is related with the string constants in the 
source files. The main problem is the encoding when I read
a text file and show its contents in the jsp with something like,

<%= FileReader.readLine() %>

And as I mentioned, when I load a file and write it into another file, the encoding is 
correct. The result of my string manipulation functions are correct. The single, 
devastating, problem occurs when I pass a string with characters in ISO-8859-9, from a 
class to jsp.

Ah, 

RE: Character Encoding Problem

[ohamali]

Hi,

  Another problem related with the charset type is when I use the following code
 
  strErrorMsg = "a message using ISO-8859-9";
  

and post the form, the receiving jsp file does not print the
strErroMsg variable correctly.

How can this problem be solved?

Thanks,

Oner Necip Hamali.
> 
> Kimden: <[EMAIL PROTECTED]>
> Tarih: 2001/07/02 Mon PM 12:16:03 GMT+03:00
> Kime: [EMAIL PROTECTED]
> Konu: İlgi:RE: Character Encoding Problem
> 
> > Kimden: Tõnu Põld <[EMAIL PROTECTED]>
> > Tarih: 2001/07/02 Mon AM 10:48:10 GMT+03:00
> > Kime: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > Konu: RE: Character Encoding Problem
> > 
> > Hi,
> > 
> > You should compile the java classes with ISO-8859-9 encoding.
> > Look at the -encoding flag of the 'javac' compiler.
> > 
> > In compilation the 8-byte characters in strings are converted to unicode
> > characters.
> > By default the encoding is probably ISO-8859-1.
> > 
> > Regards,
> > Tõnu
> > 
> 
> I tried, a few minutes ago, but the problem remains. I don't
> know the usage of -encoding parameter in detail but,
> I think it is related with the string constants in the 
> source files. The main problem is the encoding when I read
> a text file and show its contents in the jsp with something like,
> 
> <%= FileReader.readLine() %>
> 
> And as I mentioned, when I load a file and write it into another file, the encoding 
>is correct. The result of my string manipulation functions are correct. The single, 
>devastating, problem occurs when I pass a string with characters in ISO-8859-9, from 
>a class to jsp.
> 
> Ah,  
> Himm .. It is a stupid thought but is it something to do with dynamic strings vs. 
>static strings. As far as I know when <%@ include.. is used the file is statically 
>included,
> at compile time, but compilation. Also the string constants in jsp files are compiled, but strings read 
>from files are
> read and generated in execution time .. Himmm .. I think I am going paranoic :) ..
> 
> Thanks, anyway .. Has anyone encountered this kind of problem before ??
> 
> Arif ..
> 
> 

RE: Character Encoding Problem

[atumer]

> Kimden: Tõnu Põld <[EMAIL PROTECTED]>
> Tarih: 2001/07/02 Mon AM 11:55:51 GMT+03:00
> Kime: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Konu: RE: ?lgi:RE: Character Encoding Problem
> 
> Just a thought about the  try to place the "<%@page contentType=" in each file you include?

The line is there, in all files :) ..

> 
> 
> When reading bytes from file with FileReader the default character encoding
> is used.
> I think you must specify your own encoding when reading the file.
>

I'll try that. But the same compiled classes and the same jdk version works well with 
Resin JSP Server and the files. The problem occurs with Tomcat.

Thanks,

Arif ..

RE: Character Encoding Problem

[atumer]

> > When reading bytes from file with FileReader the default character encoding
> > is used.
> > I think you must specify your own encoding when reading the file.
> >
> 
> I'll try that. But the same compiled classes and the same jdk version works well 
>with Resin JSP Server and the files. The problem occurs with Tomcat.
> 

Nay, still problems. A lot of ?'s in the visual output. Himpf. The point is, which is 
interesting, if a have an html form with ISO-8859-9 encoded chars, and post it to a 
jsp file, and write the parameters to a system text file, the text is correct!!

The problem seems to occur during displaying strings obtained from inside a class .. 
Any other display problems with other character sets ?? .. Any more idea ?? ..

Let's remember the problem. We cannot display ISO-8859-9 encoded string constants of a 
class, or strings read from a file, in jsp documents in correct encoding.
Usage of <%@ page content-type does not solve
Usage of javac -encoding does not solve
Usage of encodings in file read/writes of java.io routines does not solve

The problem is with Tomcat, no problems with Resin used in the same environment, 
OS/JDK.

Arif ..

RE: Character Encoding Problem

[Tõnu Põld]

Hi,

I still believe your initial bytes are converted to java strings (unicode)
using a wrong encoding.

If you have a string created from bytes using the "ISO-8859-9" encoding, and
if the JSP page has a directive <%@ page content-type="ISO-8859-9"%>, then
it should be OK. 

For debuging you could try to convert your string to another encoding, look
what happens.
For example:

<%@ page content-type="ISO-8859-9"%>
String s = new String( initalString.getBytes("ISO-8859-1"), "ISO-8859-9");
<%= s %>

If this dislays your string correctly, then you have used the "ISO-8859-1"
encoding in creation of a java string from inital bytes!

By the way which version of Tomcat are you using. An older release (3.2.1)
had some bugs with encoding conversion. Try the latest 3.2.2 release.

The request parameters from HTTP post are probably in "ISO-8859-1" encoding
because most browsers do not specify the encoding when submiting a request,
so Tomcat uses the default encoding. To convert them correctly to java
strings encoding, the following could be used (assuming that they really are
"ISO-8859-9"):
String param = new String( initalParam.getBytes("ISO-8859-1"),
"ISO-8859-9");

Regards,
Tõnu



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 3:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Character Encoding Problem
> 
> 
> > > When reading bytes from file with FileReader the default 
> character encoding
> > > is used.
> > > I think you must specify your own encoding when reading the file.
> > >
> > 
> > I'll try that. But the same compiled classes and the same 
> jdk version works well with Resin JSP Server and the files. 
> The problem occurs with Tomcat.
> > 
> 
> Nay, still problems. A lot of ?'s in the visual output. 
> Himpf. The point is, which is interesting, if a have an html 
> form with ISO-8859-9 encoded chars, and post it to a jsp 
> file, and write the parameters to a system text file, the 
> text is correct!!
> 
> The problem seems to occur during displaying strings obtained 
> from inside a class .. Any other display problems with other 
> character sets ?? .. Any more idea ?? ..
> 
> Let's remember the problem. We cannot display ISO-8859-9 
> encoded string constants of a class, or strings read from a 
> file, in jsp documents in correct encoding.
> Usage of <%@ page content-type does not solve
> Usage of javac -encoding does not solve
> Usage of encodings in file read/writes of java.io routines 
> does not solve
> 
> The problem is with Tomcat, no problems with Resin used in 
> the same environment, OS/JDK.
> 
> Arif ..
> 

Re: lame,encoding problem

[Christopher Schultz]

Bartek,

But then when I do something with these
parameters and my mysql database I get then them wrong encoded and
all data read from mysql are wrong encoded .
Hmmm... if you use your Java code to insert some text into the DB, does 
it look okay when you read it back out using the mysql command-line 
tool? I'm wondering if the characters are being mangled on the way into 
of out of the database.

See... the UTF-8 encoding only comes into play when converting bytes 
from the request into Strings on which your Java code operates. Once 
you're in the Java world, everything should be okay. Again, when you 
write the data back out to the response, the UTF-8 comes into play as well.

However, when writing to the db, the strings also need to be converted 
to bytes by some character encoding. It's very possible that either the 
VM and/or MySQL are using incompatible character sets. Check to see what 
the value of the system property "file.encoding" is at runtime.

Then again... unless you really are using multibyte characters, you 
should be okay no matter what. The MySQL JDBC driver should be using the 
same encoding going both to and from the db. But, if it's an encoding 
that doesn't understand multibyte characters (like ISO-8859-1), then you 
might be permanently damaging those characters. Though I use MySQL/Java 
all the time, I'm not sure how to set the character encoding for the 
JDBC driver. Check the MySQL documentation, and let us know what you find.

Hope that helps,
-chris


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: lame,encoding problem

[David OBrien]

The sun JDK 1.4.2 release mucks encoding up...
I went back to 1.4.1 and all was fine.
-Dave


At 07:45 PM 11/23/2003, bwasko wrote:
Hi
I have a strange problem.
On my jsp pages use utf-8 encoding. Because of problems in my struts 
application I use the tomcat-example-encoding-filter and set it in web.xml 
to utf-8 and to processing all requests . It works , tomcat starts 
normally . When I submit a form i can get the request parameters properly 
encoded and properly write them with for example System.out.print().
But then when I do something with these parameters and my mysql database I 
get then them wrong encoded and all data read from mysql are wrong encoded .
What is wrong???
I use MS Windows XP and tomcat 4.1.29
My Locale is pl_PL.
Cheers Bartek Wa¶ko


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: lame,encoding problem

[Christopher Schultz]

David,
The sun JDK 1.4.2 release mucks encoding up...
I went back to 1.4.1 and all was fine.
How does JDK 1.4.2 muck up the encoding? I'm using 1.4.2, my 
"file.encoding" appears to be UTF-8, and I have no problem with any of 
the text that I store in my MySQL database.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: lame,encoding problem

[bwasko]

Hi
I 've tried to execute insert statement that contains my national characters
with the mysql command-line client tool and all looks ok. The strings are
properly written into database. But writing into it with use of jdbc driver
ends with chars like  '??'. I use mysql-connector and i think it causes
these problems.

Cheers Bartek
- Original Message - 
From: "Christopher Schultz" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 4:41 AM
Subject: Re: lame,encoding problem


> Bartek,
>
> > But then when I do something with these
> > parameters and my mysql database I get then them wrong encoded and
> > all data read from mysql are wrong encoded .
>
> Hmmm... if you use your Java code to insert some text into the DB, does
> it look okay when you read it back out using the mysql command-line
> tool? I'm wondering if the characters are being mangled on the way into
> of out of the database.
>
> See... the UTF-8 encoding only comes into play when converting bytes
> from the request into Strings on which your Java code operates. Once
> you're in the Java world, everything should be okay. Again, when you
> write the data back out to the response, the UTF-8 comes into play as
well.
>
> However, when writing to the db, the strings also need to be converted
> to bytes by some character encoding. It's very possible that either the
> VM and/or MySQL are using incompatible character sets. Check to see what
> the value of the system property "file.encoding" is at runtime.
>
> Then again... unless you really are using multibyte characters, you
> should be okay no matter what. The MySQL JDBC driver should be using the
> same encoding going both to and from the db. But, if it's an encoding
> that doesn't understand multibyte characters (like ISO-8859-1), then you
> might be permanently damaging those characters. Though I use MySQL/Java
> all the time, I'm not sure how to set the character encoding for the
> JDBC driver. Check the MySQL documentation, and let us know what you find.
>
> Hope that helps,
> -chris
>
>
>
> -
> 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]

RE: lame,encoding problem

[Galbayar]

jdbc:mysql://127.0.0.1:3306/test/?useUnicode=true

-Original Message-
From: bwasko [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 4:50 PM
To: Tomcat Users List
Subject: Re: lame,encoding problem


Hi
I 've tried to execute insert statement that contains my national characters
with the mysql command-line client tool and all looks ok. The strings are
properly written into database. But writing into it with use of jdbc driver
ends with chars like  '??'. I use mysql-connector and i think it causes
these problems.

Cheers Bartek
- Original Message -
From: "Christopher Schultz" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 4:41 AM
Subject: Re: lame,encoding problem


> Bartek,
>
> > But then when I do something with these
> > parameters and my mysql database I get then them wrong encoded and
> > all data read from mysql are wrong encoded .
>
> Hmmm... if you use your Java code to insert some text into the DB, does
> it look okay when you read it back out using the mysql command-line
> tool? I'm wondering if the characters are being mangled on the way into
> of out of the database.
>
> See... the UTF-8 encoding only comes into play when converting bytes
> from the request into Strings on which your Java code operates. Once
> you're in the Java world, everything should be okay. Again, when you
> write the data back out to the response, the UTF-8 comes into play as
well.
>
> However, when writing to the db, the strings also need to be converted
> to bytes by some character encoding. It's very possible that either the
> VM and/or MySQL are using incompatible character sets. Check to see what
> the value of the system property "file.encoding" is at runtime.
>
> Then again... unless you really are using multibyte characters, you
> should be okay no matter what. The MySQL JDBC driver should be using the
> same encoding going both to and from the db. But, if it's an encoding
> that doesn't understand multibyte characters (like ISO-8859-1), then you
> might be permanently damaging those characters. Though I use MySQL/Java
> all the time, I'm not sure how to set the character encoding for the
> JDBC driver. Check the MySQL documentation, and let us know what you find.
>
> Hope that helps,
> -chris
>
>
>
> -
> 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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: lame,encoding problem

[Galbayar]

jdbc:mysql://127.0.0.1:3306/test?useUnicode=true

-Original Message-
From: Galbayar [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 5:48 PM
To: Tomcat Users List
Subject: RE: lame,encoding problem


jdbc:mysql://127.0.0.1:3306/test/?useUnicode=true

-Original Message-
From: bwasko [mailto:[EMAIL PROTECTED]
Sent: Monday, November 24, 2003 4:50 PM
To: Tomcat Users List
Subject: Re: lame,encoding problem


Hi
I 've tried to execute insert statement that contains my national characters
with the mysql command-line client tool and all looks ok. The strings are
properly written into database. But writing into it with use of jdbc driver
ends with chars like  '??'. I use mysql-connector and i think it causes
these problems.

Cheers Bartek
- Original Message -
From: "Christopher Schultz" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 4:41 AM
Subject: Re: lame,encoding problem


> Bartek,
>
> > But then when I do something with these
> > parameters and my mysql database I get then them wrong encoded and
> > all data read from mysql are wrong encoded .
>
> Hmmm... if you use your Java code to insert some text into the DB, does
> it look okay when you read it back out using the mysql command-line
> tool? I'm wondering if the characters are being mangled on the way into
> of out of the database.
>
> See... the UTF-8 encoding only comes into play when converting bytes
> from the request into Strings on which your Java code operates. Once
> you're in the Java world, everything should be okay. Again, when you
> write the data back out to the response, the UTF-8 comes into play as
well.
>
> However, when writing to the db, the strings also need to be converted
> to bytes by some character encoding. It's very possible that either the
> VM and/or MySQL are using incompatible character sets. Check to see what
> the value of the system property "file.encoding" is at runtime.
>
> Then again... unless you really are using multibyte characters, you
> should be okay no matter what. The MySQL JDBC driver should be using the
> same encoding going both to and from the db. But, if it's an encoding
> that doesn't understand multibyte characters (like ISO-8859-1), then you
> might be permanently damaging those characters. Though I use MySQL/Java
> all the time, I'm not sure how to set the character encoding for the
> JDBC driver. Check the MySQL documentation, and let us know what you find.
>
> Hope that helps,
> -chris
>
>
>
> -
> 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]


-
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]

Re: lame,encoding problem

[bwasko]

I ve also tried connection strings manipulations ?use Unicode and
?characterEncoding . Doesn't work :(
Bartek Wasko
- Original Message - 
From: "Galbayar" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 10:47 AM
Subject: RE: lame,encoding problem


> jdbc:mysql://127.0.0.1:3306/test/?useUnicode=true
>
> -Original Message-
> From: bwasko [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 24, 2003 4:50 PM
> To: Tomcat Users List
> Subject: Re: lame,encoding problem
>
>
> Hi
> I 've tried to execute insert statement that contains my national
characters
> with the mysql command-line client tool and all looks ok. The strings are
> properly written into database. But writing into it with use of jdbc
driver
> ends with chars like  '??'. I use mysql-connector and i think it
causes
> these problems.
>
> Cheers Bartek
> - Original Message -
> From: "Christopher Schultz" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Monday, November 24, 2003 4:41 AM
> Subject: Re: lame,encoding problem
>
>
> > Bartek,
> >
> > > But then when I do something with these
> > > parameters and my mysql database I get then them wrong encoded and
> > > all data read from mysql are wrong encoded .
> >
> > Hmmm... if you use your Java code to insert some text into the DB, does
> > it look okay when you read it back out using the mysql command-line
> > tool? I'm wondering if the characters are being mangled on the way into
> > of out of the database.
> >
> > See... the UTF-8 encoding only comes into play when converting bytes
> > from the request into Strings on which your Java code operates. Once
> > you're in the Java world, everything should be okay. Again, when you
> > write the data back out to the response, the UTF-8 comes into play as
> well.
> >
> > However, when writing to the db, the strings also need to be converted
> > to bytes by some character encoding. It's very possible that either the
> > VM and/or MySQL are using incompatible character sets. Check to see what
> > the value of the system property "file.encoding" is at runtime.
> >
> > Then again... unless you really are using multibyte characters, you
> > should be okay no matter what. The MySQL JDBC driver should be using the
> > same encoding going both to and from the db. But, if it's an encoding
> > that doesn't understand multibyte characters (like ISO-8859-1), then you
> > might be permanently damaging those characters. Though I use MySQL/Java
> > all the time, I'm not sure how to set the character encoding for the
> > JDBC driver. Check the MySQL documentation, and let us know what you
find.
> >
> > Hope that helps,
> > -chris
> >
> >
> >
> > -
> > 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]
>
>
> -
> 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]

RE: Turkish encoding problem

[Yansheng Lin]

try native2ascii your property file first(assuming you saved your files using
Turkish character encoding).  There were some discussions on this topic a few
days ago.  Here is the pointer to the answer given by Adma Hardy:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg119451.html.

Hope that helps.

-Yan

-Original Message-
From: Metin Zavrak [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 24, 2004 3:16 PM
To: Tomcat Users List
Subject: Turkish encoding problem


Hi,
I am working on a project in which I use XML files.
I wrote an JavaServlet which reads an XML and an XSL file and creates an 
HTML file.
My XML and XSL files contain Turkish characters (Turkish encoding is 
ISO-8859-9).
These characters are displayed as a question mark (?).

I have tried many solutions but couldn't fix the problem.
I attached the codes so that you can see what is going on.

I am using   Windows XP
   Java 1.4.2_03
   Xalan-Java 2.5
   Xerces-J 1.4.4
   Tomcat
  






http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="D:\Tomcat\webapps\book\WEB-INF\source\xml\kategor
i.xsd">

isletim sistemleri
100

Unix
100


Linux
101







http://www.w3.org/1999/XSL/Transform";>




:::LeoFibo.NET:::










  
  



   




Leofibo.NET   
  




   
   ARAMA  
   ISBNBaslik
   
   
   
  





   
  

  
  
  
   















]>
http://www.w3.org/1999/XSL/Transform"; version="1.0">












kategori_browse?id=

 :: 

























-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Arabic encoding problem

[Yansheng Lin]

Hi, It's likely that request.getCharacterEncoding() is not null at that
point(most likely iso-8859-1). A better conditional statement: 
if (request.getCharacterEncoding()==null) || !
request.getCharacterEncoding().equals("windows-1256")) {}

Cheers:).

-Yan 

-Original Message-
From: vijaya prasad pala [mailto:[EMAIL PROTECTED] 
Sent: Sunday, March 07, 2004 2:36 AM
To: [EMAIL PROTECTED]
Subject: Arabic encoding problem


Hi

i am reading arabic text from oracle database.
if i am displaying that text in that page it ok.
if i am passing the same arabic string to another page
then in that page it is displaying in ?. 
i tried like this

 if(request.getCharacterEncoding()==null)
request.setCharacterEncoding("windows-1256");
  
  linkString = request.getParameter("linkLine");
  userString = request.getParameter("userLine");

Here my problem is passing string from one page to
another page... 

Thanks in Advance
vijay


__
Do you Yahoo!?
Yahoo! Search - Find what you're looking for faster
http://search.yahoo.com

-
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]

Encoding problem during authentication

[Andrey Grebnev]

Hello,

  I have a problem under following environment:
   - Windows XP SP2
   - JDK 1.4.2_04
   - Tomcat 5.5.9
   - Struts 1.2.4

  I use characterEncodingFilter to setup UTF-8 encoding
into request before
  using the content of the request. When I submit form with
POST
  method it works well. I use FORM based authentication.

  However if I perform the following steps I have the
problems with
  encoding:

  1. Open JSP with HTML form which submit some UTF-8 string
data using POST
  method.
  2. Waiting when the HTTP session is invalidated (session
timeout).
  3. Submit the form.
  4. Because session is invalidated I need to
re-authenticate myself.
  5. After success authentication The processing of the
original request is
  continued.
  6. The data of the form (from first step) is saved in
incorrect
  encoding.

  I suppose that Valve (FormAuthenticator) which
responsible for authentication is
  processed earlier then characterEncodingFilter and the
parameters from
  POST request are parsed using
  DEFAULT_CHARACTER_ENCODING="ISO-8859-1" when the original
request
  information is saved into session.

  I have tried to specify
enctype="application/x-www-form-urlencoded;
  charset=utf-8" attribute for my FORM tag. But e.g.
Mozilla browser
  specify only Content-Type:
application/x-www-form-urlencoded header
  and cut out specified charset.

  Any ideas?

-- 
Best regards,
 Andrey Grebnev

Треть суток на треть дешевле!
МАРК-ИТТ ввёл льготные цены на ночной трафик в Народном Интернете
цены на трафик на 30% ниже дневных в период с 1:00 до 9:00.
600-й - 1.75р, Профессиональный - 1.89р, Деловой - 1.96р, 5-ка - 2,03р, 
Домашний - 2,10р

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Encoding problem with <%@ include %> directive

[Arik Kfir]

Hi all..

This is the first time I'm using a mailing list...
Excuse me if I violate any rules here ;-)

My problem/bug is this: I have a JSP page, 
call it MyPage.jsp. The page has the 
following @page directive:

<%@ page
language="Java"
session="false"
buffer="none"
errorPage="error.jsp"
contentType="text/html;charset=WINDOWS-1255"
%>

Note the encoding in the *contentType* attribute - 
its a Hebrew encoding. In the middle of the page 
I have put the following statement:

<%@ include file="MyIncludePage.jsp" %>

The MyIncludePage.jsp page has the same @page 
statement (with the same encoding) and includes
some Hebrew characters in its body. Now here comes the 
interesting part: when I run MyIncludePage.jsp
on its own in the browser, my Hebrew text returns
fine from the server. HOWEVER when I run MyPage.jsp,
the Hebrew characters that are *included* from
MyIncludePage.jsp into MyPage.jsp are transformed
into question marks ("?").

Now, I suspect that for some reason, Tomcat doesn't
consider the encoding when it does executes an include
statement, but only on the request level.

I should say that I use Tomcat 3.2.1 on a Windows 2000
Professional system.

Best regards, and thanks,
Arik Kfir.

Encoding problem with <%@ include %> directive

[Arik Kfir]

Hi all..

I have a JSP page, call it *MyPage.jsp*. The page has the following @page
directive:

<%@ page language="Java" session="false" buffer="none" errorPage="error.jsp"
contentType="text/html;charset=WINDOWS-1255" %>

Note the encoding in the *contentType* attribute - its a Hebrew encoding. In
the middle of the page
I have put the following statement:

<%@ include file="MyIncludePage.jsp" %>

The MyIncludePage.jsp page has the same @page statement (with the same
encoding) and includes
some Hebrew characters in its body. When I run MyIncludePage.jsp on its own
in the browser,
my Hebrew text returns fine from the server. HOWEVER when I run MyPage.jsp,
the Hebrew
characters that are *included* from *MyIncludePage.jsp* into MyPage.jsp are
transformed
into question marks ("?").

Now, I suspect that for some reason, Tomcat doesn't consider the encoding
when it does
executes an include statement, but only on the request level. I should say
that I
use Tomcat 3.2.1 on a Windows 2000 Professional system with JDK 1.3.

Best regards, and thanks,
Arik Kfir.

Character encoding problem: strange rash

[John Wadkin]

All,

Tomcat 4.0.1
Apache 1.3
WARP
Solaris 8
JDK 1.2/1.3

Does anyone know why a servlet would suddenly start displaying non-breaking
spaces ( ) as question marks (?) when the JDK/SDK is upgraded from 1.2
to 1.3? Very odd behaviour! Like a rash - question marks all over the place
:)
The servlet was written for a version of the Servlet API <2.3, so it doesn't
set the character encoding. BUT I don't see how this would have any bearing
on the problem, since the JDK has nothing to do with the Servlet API?

Thanks,

John

--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Re[2]: Encoding problem (?)

[Alexander Höglind]

Okey, I missed that one, but "*" means any url-character and that includes "/" (root). 

Cheers,
Alexander Höglind
[EMAIL PROTECTED]

- Original Message - 
From: "Jacob Kjome" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2002 8:43 PM
Subject: Re[2]: Encoding problem (?)


> Hello Alexander,
> 
> That isn't true,
> 
> How about this?
> 
> 
> 
> jsp
> *.jsp
> 
> 
> That is the standard way to map any file ending in .jsp and this is
> pulled straight from Tomcat-4.x.x conf/web.xml.  Do you see a
> prepended "/"?  I don't.
> 
> Jake
> 
> Thursday, April 25, 2002, 1:39:09 PM, you wrote:
> 
> AH> Hi Massimo,
> AH> Maybe this solves your problem.
> AH> Any servlet-mapping or filter-mapping URL must begin with a "/".  
>/MyURL
> 
> AH> Alexander Höglind
> AH> [EMAIL PROTECTED]
> 
> AH> - Original Message - 
> AH> From: "Ferrari Massimo" <[EMAIL PROTECTED]>
> AH> To: <[EMAIL PROTECTED]>
> AH> Sent: Friday, April 19, 2002 11:41 AM
> AH> Subject: Encoding problem (?)
> 
> 
> >> Hi all,
> >> I have troubles trying to start timcat 4.0.2 on win2k.
> >> I get this error
> >> 
> >> ERROR reading java.io.ByteArrayInputStream@704baa
> >> At Line 20 /web-app/servlet-mapping/
> >> 
> >> when tomcat tries to read my web.xml file (attached)
> >> I tried to convert this file to UNIX, UTF, ... but without success.
> >> Thank you in advance
> >> Massimo
> >> 
> >> 
> 
> 
> AH> 
> 
> 
> >> --
> >> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> >> For additional commands: <mailto:[EMAIL PROTECTED]>
> >> Troubles with the list: <mailto:[EMAIL PROTECTED]>
> 
> 
> AH> --
> AH> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> AH> For additional commands: <mailto:[EMAIL PROTECTED]>
> AH> Troubles with the list: <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> -- 
> Best regards,
>  Jacobmailto:[EMAIL PROTECTED]
> 
> 
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: ?lgi:RE: Character Encoding Problem

[Tõnu Põld]

Just a thought about the  -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 11:16 AM
> To: [EMAIL PROTECTED]
> Subject: ?lgi:RE: Character Encoding Problem
> 
> 
> > Kimden: Tõnu Põld <[EMAIL PROTECTED]>
> > Tarih: 2001/07/02 Mon AM 10:48:10 GMT+03:00
> > Kime: "'[EMAIL PROTECTED]'" 
> <[EMAIL PROTECTED]>
> > Konu: RE: Character Encoding Problem
> > 
> > Hi,
> > 
> > You should compile the java classes with ISO-8859-9 encoding.
> > Look at the -encoding flag of the 'javac' compiler.
> > 
> > In compilation the 8-byte characters in strings are 
> converted to unicode
> > characters.
> > By default the encoding is probably ISO-8859-1.
> > 
> > Regards,
> > Tõnu
> > 
> 
> I tried, a few minutes ago, but the problem remains. I don't
> know the usage of -encoding parameter in detail but,
> I think it is related with the string constants in the 
> source files. The main problem is the encoding when I read
> a text file and show its contents in the jsp with something like,
> 
> <%= FileReader.readLine() %>
> 
> And as I mentioned, when I load a file and write it into 
> another file, the encoding is correct. The result of my 
> string manipulation functions are correct. The single, 
> devastating, problem occurs when I pass a string with 
> characters in ISO-8859-9, from a class to jsp.
> 
> Ah,  
> Himm .. It is a stupid thought but is it something to do with 
> dynamic strings vs. static strings. As far as I know when <%@ 
> include.. is used the file is statically included,
> at compile time, but  dynamically after compilation. Also the string constants in 
> jsp files are compiled, but strings read from files are
> read and generated in execution time .. Himmm .. I think I am 
> going paranoic :) ..
> 
> Thanks, anyway .. Has anyone encountered this kind of problem 
> before ??
> 
> Arif ..
> 

Encoding problem in Opera browser

[Evgeniy Strokin]

I use TC 3.2.3 (Actually in TC 4b7 he same problem)
I have all pages in UTF-8 encoding.
I trying get values from parameters.
I have this code:
String param=_request.getParameter(name);
param=new String(param.getBytes("iso-8859-1"),"UTF-8");
In IE and NS every things fine.
But from Opera I getting value shorter (for example  from IE and ?? from
Opera)
and after
param=new String(param.getBytes("iso-8859-1"),"UTF-8");
all not Latin symbols cut.
Please help.


NetZero Platinum
Sign Up Today - Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

Character Encoding problem (umlauts, etc).

[Robert Priest]

> I have a servlet that catches a request for a file.
> 
> But if that file has characters such as an umlaut in it (for example: ä),
> the path info is all wrong.
> 
> For example:  I am requesting file : 
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
> 
> but what is coming across in the request is:
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"
> 
> 
> I have tried:
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("ISO-8859-1"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("Unicode"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UTF8"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UnicodeLittle"));
> 
> 
> But none of them are returning correctly.
> 
> Does anyone know what the correct know what is the correct unicode
> encoding I should have?
> 
> Any other suggestions?
> 
> I know this problem has been solved before so If you could point me in the
> direction of the solution on the web that is fine.
> 
> THanks in advance.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tag file encoding problem

[Sebastian Ryszard Kruk]

Dnia 08/30/2004 07:01 PM, UÃÂytkownik John Villar napisaÃÂ:
i don't know much about the ".tag" format however, if it is an XML 
based one, you must define the charset of your xml in the  tag

Sebastian Ryszard Kruk escribiÃ:
Hi,
I have a strange problem - I use tomcat 5.0.14.
When I try to put some strings with polish letters like "ÅciÄga" in 
tag file - it results that during the translation to *.java file - 
this text is being replaced by ÃciÃga - just as it would treat the 
*.tag file as encoded in Latin1 rather than in UTF-8. Polish letters 
in *.jsp files are ok, though.

Any ideas ??
Thanks,
skruk



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
it is not - it is rather a part of JSP page ;-(
--
-
--   Sebastian Ryszard Kruk, M.Sc.
--   mailto: [EMAIL PROTECTED]
--   GG: 335067, Jabber: [EMAIL PROTECTED]
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tag file encoding problem

[John Villar]

then you should use the <%@ page %> directive. search the web it 
has a way to specify encoding

Sebastian Ryszard Kruk escribiÃ:
Dnia 08/30/2004 07:01 PM, UÃÂytkownik John Villar napisaÃÂ:
i don't know much about the ".tag" format however, if it is an 
XML based one, you must define the charset of your xml in the  
tag

Sebastian Ryszard Kruk escribiÃ:
Hi,
I have a strange problem - I use tomcat 5.0.14.
When I try to put some strings with polish letters like "ÅciÄga" in 
tag file - it results that during the translation to *.java file - 
this text is being replaced by ÃciÃga - just as it would treat the 
*.tag file as encoded in Latin1 rather than in UTF-8. Polish letters 
in *.jsp files are ok, though.

Any ideas ??
Thanks,
skruk



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

it is not - it is rather a part of JSP page ;-(
--
John Villar
Gerente de Proyectos
Computadores Flor Hard Soft 2058 C.A.
www.florhard.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tag file encoding problem

[V. Karthik Kumar]

use: 

response.setCharacterEncoding("Whatever"); <-- internally, this is what
the tags translate to...

Before u carry on with out.print() statements...

And one more thing.. there is an option available to add encoding
messages by default; a filter is available by default

filters.setCharacterEncodingFilter

look in the servlets-examples\WEB-INF\web.xml

:)


On Wed, 2004-09-01 at 00:37, John Villar wrote:
> then you should use the <%@ page %> directive. search the web it 
> has a way to specify encoding
> 
> Sebastian Ryszard Kruk escribiÃ:
> 
> > Dnia 08/30/2004 07:01 PM, UÃÂytkownik John Villar napisaÃÂ:
> >
> >> i don't know much about the ".tag" format however, if it is an 
> >> XML based one, you must define the charset of your xml in the  
> >> tag
> >>
> >> Sebastian Ryszard Kruk escribiÃ:
> >>
> >>> Hi,
> >>>
> >>> I have a strange problem - I use tomcat 5.0.14.
> >>>
> >>> When I try to put some strings with polish letters like "ÅciÄga" in 
> >>> tag file - it results that during the translation to *.java file - 
> >>> this text is being replaced by ÃciÃga - just as it would treat the 
> >>> *.tag file as encoded in Latin1 rather than in UTF-8. Polish letters 
> >>> in *.jsp files are ok, though.
> >>>
> >>> Any ideas ??
> >>>
> >>> Thanks,
> >>>
> >>> skruk
> >>
> >>
> >>
> >>
> >>
> >> 
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > it is not - it is rather a part of JSP page ;-(
> >


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.5 character encoding problem

[Michael Schuerig]

Hello!

I've tried my luck with Tomcat 5.5 and found that it behaves different 
than 5.0.27 does as regards character encoding. Somehow the conversion 
from ISO-8859-1 to UTF-8 doesn't work as it should. This may well be 
due to a misconfiguration. See below for the JSP document and the two 
different output pages generated. It looks as if Tomcat 5.5 applies the 
ISO-8859-1 to UTF-8 conversion twice. I'm editing the JSP document with 
Eclipse 3.1M1 and the text file encoding is set to ISO-8859-1.

I'm still pretty new to servlets, JSP, and Tomcat, so I might be 
overlooking something rather obvious.

Michael


test.jspx:
>>>


http://www.w3.org/1999/xhtml";
 xmlns:jsp="http://java.sun.com/JSP/Page";
 xmlns:c="http://java.sun.com/jsp/jstl/core";
 xmlns:fmt="http://java.sun.com/jsp/jstl/fmt";
 lang='de'
>

  http://www.w3.org/TR/xhtml-basic/xhtml1-strict.dtd"; />

  
  

  
Test
  

  

Ã
Ã
Ã
Ã
Ã
Ã
" "

  

>>>

With Tomcat 5.5 (wrong)
http://localhost:8080/myapp/test.jspx:
>>>

http://www.w3.org/TR/xhtml-basic/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; 
lang="de">Test

ÃÂÃÂÂ
ÃÂÃÂ
ÃÂÃÂ
ÃÂÃÂ
ÃÂÃÂ
ÃÂÃÂ
"ÃÂÃÂ"
>>>

With Tomcat 5.0.27 (correct)
http://localhost:8080/myapp/test.jspx:
>>>

http://www.w3.org/TR/xhtml-basic/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; 
lang="de">Test

ÃÂ
ÃÂ
ÃÂ
ÃÂ
ÃÂ
ÃÂ
"ÃÂ"
>>>

-- 
Michael SchuerigI was blessed with a birth and a death and
mailto:[EMAIL PROTECTED] I guess I just want some say in between
http://www.schuerig.de/michael/ --Ani DiFranco, Talk To Me Now

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

OFF-TOPIC: Axis encoding problem

[Reynir Þór Hübner]

Hi,
Can anyone help me with an JWS problem in Axis.
I have a .jws document, and axis installed, and I need to be able to use UTF-16 encoding as I need to be able to transport special language 
characters. The documentation says I should be able to set axis.encoding parameter either in my web.xml or in the server-config.wsdd. I've 
tried both, but I cannot get it to do anything for me, all responses are UTF-8.

thanx,
-reynir
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SSI Servlet Character Encoding Problem

[KEREM ERKAN]

Hi people,
 
I use Tomcat 5.5.9 with Apache 2.0.54 and jk 1.2.10 to serve my websites. I
want to set custom error pages to be served when an error like 404, 500 etc.
occurs. The website uses the iso-8859-9 character set on every page, and the
error pages are encoded with iso-8859-9 too.
 
Only *.jsp pages and servlets are mapped to Tomcat through jk. All other
static content is served by Apache.
 
My error pages are all Server Side Include shtml files. These error files
include some jsp files with:
 

 
I have set up SSI (correctly I hope) on both Apache and Tomcat, and also set
up custom error file handling on both httpd.conf and the default web.xml for
the site I want to customize.
 
On my server.xml file, my site is configured like this:
 
http://www.foo.com> www.foo.com" appBase="/usr/www/foo">
  
  

 
On my default web.xml for tomcat configuration, SSI servlet has these
directives added:
 

  inputEncoding
  iso-8859-9


  outputEncoding
  iso-8859-9

 
When I go to some nonexistent foo.html on my website, Apache handles the
customized error page and everything works fine. On the other hand I have
two problems:
 
One is, if the "isVirtualWebappRelative" variable in web.xml is set to "0",
and I go to a nonexistent "foo.jsp" on my server, jk sends the request to
Tomcat and when Tomcat tries to handle the customized error page, it cannot
find the included files in SSI and an error is written in the Tomcat error
log like:
 
SEVERE: ssi: #include--Couldn't include file: /include/footer.jsp
java.io.IOException: Couldn't get context for path: /include/footer.jsp

The /include folder is in the server root. I think it should be able to find
these pages, as it looks at the server root because of the state of
"isVirtualWebappRelative" variable, am I wrong?
 
When I set "isVirtualWebappRelative" to "1", this problem is solved only for
server root, my servlets (say /servlet) still cannot get the customized page
includes, because this time the SSI includes become "web app relative" and I
have to copy the /include folder into /servlet/include directory to work
around this problem.
 
My second problem is, when I go to this nonexistent "foo.jsp" with
"isVirtualWebappRelative" set to "1", and when Tomcat tries to handle the
error page, the encoding is always UTF-8 regardless of "inputEncoding" or
"outputEncoding" variables. So my error page becomes full of garbled
characters because the encoding should be iso-8859-9.
 
Is there any suggestions about these problems?
 
Best regards,
 
Kerem

Re: Encoding problem in Opera browser

[Craig R. McClanahan]

On Fri, 10 Aug 2001, Evgeniy Strokin wrote:

> I use TC 3.2.3 (Actually in TC 4b7 he same problem)
> I have all pages in UTF-8 encoding.
> I trying get values from parameters.
> I have this code:
> String param=_request.getParameter(name);
> param=new String(param.getBytes("iso-8859-1"),"UTF-8");
> In IE and NS every things fine.
> But from Opera I getting value shorter (for example  from IE and ?? from
> Opera)
> and after
> param=new String(param.getBytes("iso-8859-1"),"UTF-8");
> all not Latin symbols cut.
> Please help.
> 

In Servlet 2.3 (and therefore in Tomcat 4b7 but not 3.2.3) there is a new
request.setCharacterEncoding() call that you can use to tell Tomcat to do
this transformation for you before returning the parameter in the first
place.

Craig

RE: Encoding problem in Opera browser

[Evgeniy Strokin]

Still problem.
In TC4b7 I set request to UTF-8 encoding also (I use
filters.SetCharacterEncodingFilter
encoding in web.xml and request.setCharacterEncoding())
I removed
param=new String(param.getBytes("iso-8859-1"),"UTF-8");
and leaved only
String param=_request.getParameter(name);
Exactly the same result: in IE and NS every things fine from Opera value is
cut.


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 10, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Encoding problem in Opera browser


On Fri, 10 Aug 2001, Evgeniy Strokin wrote:

> I use TC 3.2.3 (Actually in TC 4b7 he same problem)
> I have all pages in UTF-8 encoding.
> I trying get values from parameters.
> I have this code:
> String param=_request.getParameter(name);
> param=new String(param.getBytes("iso-8859-1"),"UTF-8");
> In IE and NS every things fine.
> But from Opera I getting value shorter (for example  from IE and ??
from
> Opera)
> and after
> param=new String(param.getBytes("iso-8859-1"),"UTF-8");
> all not Latin symbols cut.
> Please help.
>

In Servlet 2.3 (and therefore in Tomcat 4b7 but not 3.2.3) there is a new
request.setCharacterEncoding() call that you can use to tell Tomcat to do
this transformation for you before returning the parameter in the first
place.

Craig


NetZero Platinum
Sign Up Today - Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

RE: Encoding problem in Opera browser

[Craig R. McClanahan]

On Fri, 10 Aug 2001, Evgeniy Strokin wrote:

> Still problem.
> In TC4b7 I set request to UTF-8 encoding also (I use
> filters.SetCharacterEncodingFilter
> encoding in web.xml and request.setCharacterEncoding())
> I removed
> param=new String(param.getBytes("iso-8859-1"),"UTF-8");
> and leaved only
> String param=_request.getParameter(name);
> Exactly the same result: in IE and NS every things fine from Opera value is
> cut.
> 

I don't use Opera, so I don't know if this is a stupid question, but ...
are you sure Opera is really encoding the parameters in UTF-8 like you
expect it to?

Craig

Input from a FORM - encoding problem

[Nikola Milutinovic]

Hi all.

I have a HTML FORM that I'd like to use to update data in my database. DB (PostgreSQL 
+ Unicode) is configured and correctly loaded with Unicode data. Translations from 
UTF-8 -> Win-1250 works like a charm (and so does UTF-8 -> ISO-8859-2).

In other words, displaying the data is OK.

Now I want to update fields and there is a problem. If I enter some of win-1250 chars 
in a textfield it gets translated to "?".

A simple investigation shows that the loathed Win1250 -> '?' occurs within the 
HTTPRequest object creation.

How do I specify that the data coming from a FORM is Win1250 encoded?
Do I do that in HTML FORM that submits the data (most likely)?
Or do I do that in the JSP/Servlet accepting the data (highly unlikely)?

I'm looking at HTML 4.01 specification, but so far I'm unlucky - nothing seams to 
work.

Nix.

RE: Character Encoding problem (umlauts, etc).

[Robert Priest]

This is in a JSP page (which of course becomes a servlet).

Do I have to set the encoding in Tomcat perhaps?



-Original Message-
From: Robert Priest [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 5:16 PM
To: '[EMAIL PROTECTED]'
Subject: Character Encoding problem (umlauts, etc).


> I have a servlet that catches a request for a file.
> 
> But if that file has characters such as an umlaut in it (for example: ä),
> the path info is all wrong.
> 
> For example:  I am requesting file : 
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
> 
> but what is coming across in the request is:
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"
> 
> 
> I have tried:
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("ISO-8859-1"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("Unicode"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UTF8"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UnicodeLittle"));
> 
> 
> But none of them are returning correctly.
> 
> Does anyone know what the correct know what is the correct unicode
> encoding I should have?
> 
> Any other suggestions?
> 
> I know this problem has been solved before so If you could point me in the
> direction of the solution on the web that is fine.
> 
> THanks in advance.

-
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]

RE: Character Encoding problem (umlauts, etc).

[Jeff Tulley]

The FAQ ( http://jakarta.apache.org/tomcat/faq ) has a link to a thread on "How to 
UTF-8 your site", which I think might be similar.  
http://marc.theaimsgroup.com/?l=tomcat-user&m=105524426515137&w=2
is the link to the thread itself.  Try some of the things there and see if they work 
for you. (specifically, starting Tomcat with a "-Dfile.encoding=UTF-8" switch)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

>>> [EMAIL PROTECTED] 9/4/03 3:24:58 PM >>>
This is in a JSP page (which of course becomes a servlet).

Do I have to set the encoding in Tomcat perhaps?



-Original Message-
From: Robert Priest [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 04, 2003 5:16 PM
To: '[EMAIL PROTECTED]'
Subject: Character Encoding problem (umlauts, etc).


> I have a servlet that catches a request for a file.
> 
> But if that file has characters such as an umlaut in it (for example: ä),
> the path info is all wrong.
> 
> For example:  I am requesting file : 
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
> 
> but what is coming across in the request is:
> 
> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"
> 
> 
> I have tried:
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("ISO-8859-1"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("Unicode"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UTF8"));
> String requestPathInfo5 = new
> String(request.getPathInfo().getBytes("UnicodeLittle"));
> 
> 
> But none of them are returning correctly.
> 
> Does anyone know what the correct know what is the correct unicode
> encoding I should have?
> 
> Any other suggestions?
> 
> I know this problem has been solved before so If you could point me in the
> direction of the solution on the web that is fine.
> 
> THanks in advance.

-
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] 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character Encoding problem (umlauts, etc).

[Anton Tagunov]

Hello Robert!

Robert Priest <[EMAIL PROTECTED]> wrote:
RP> I am requesting file :
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
RP> but what is coming across in the request is:
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"

Probably your browser is sending it that way?
I guess it is a bad idea anyways to type anything nasty
in the browser URL input line.

You may try to spy your interaction between browser and
server, I have described how to do it in one of the sections
of my ancient http://tagunov.tripod.com, try to find it there,
then you'll know for sure what bytes are sent by browser.

I guess that it is generally a bad idea to have anything
nasty in the url at all. The closest you could get would be
to encode it all as %AD and etc. But then you should be
sure what encoding this is (utf-8 or anything).

So, if these are links from your HTML page, why don't you
encode all in the url directly on the server side and
have 

but then why don't you get rid of these nasty umlauts at all?

Why not use only normal latin letters, or, in case you heavily use
numeric ids already, use only numeric ids?

Anton


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Character Encoding problem (umlauts, etc).

[Robert Priest]

Thanks for the information Anton. But just getting rid of umlauts or other
international characters is not an option when you have clients that use
your software in other countries, that have those special characters. We
cannot rename user files or changed that data. That would be very, very, bad
:)

-Original Message-
From: Anton Tagunov [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 06, 2003 5:46 AM
To: Tomcat Users List
Subject: Re: Character Encoding problem (umlauts, etc).


Hello Robert!

Robert Priest <[EMAIL PROTECTED]> wrote:
RP> I am requesting file :
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
RP> but what is coming across in the request is:
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"

Probably your browser is sending it that way?
I guess it is a bad idea anyways to type anything nasty
in the browser URL input line.

You may try to spy your interaction between browser and
server, I have described how to do it in one of the sections
of my ancient http://tagunov.tripod.com, try to find it there,
then you'll know for sure what bytes are sent by browser.

I guess that it is generally a bad idea to have anything
nasty in the url at all. The closest you could get would be
to encode it all as %AD and etc. But then you should be
sure what encoding this is (utf-8 or anything).

So, if these are links from your HTML page, why don't you
encode all in the url directly on the server side and
have 

but then why don't you get rid of these nasty umlauts at all?

Why not use only normal latin letters, or, in case you heavily use
numeric ids already, use only numeric ids?

Anton


-
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]

Re: Character Encoding problem (umlauts, etc).

[Thomas Kellerer]

Robert Priest schrieb:

I have a servlet that catches a request for a file.

How is the request sent?

If sent via an HTML form, you need to include the accept-charset="UTF-8" 
attribute into your  tag

Thomas



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Character Encoding problem (umlauts, etc).

[Bodycombe, Andrew]

This problem can usually be fixed by changing the file.encoding system
property.
Set CATALINA_OPTS to "-Dfile.encoding=utf-8" (or iso-8859-1 or whatever
character set you like) and restart tomcat

Hope this helps
Andy

-Original Message-
From: Robert Priest [mailto:[EMAIL PROTECTED] 
Sent: 08 September 2003 14:18
To: 'Tomcat Users List'
Subject: RE: Character Encoding problem (umlauts, etc).


Thanks for the information Anton. But just getting rid of umlauts or other
international characters is not an option when you have clients that use
your software in other countries, that have those special characters. We
cannot rename user files or changed that data. That would be very, very, bad
:)

-Original Message-
From: Anton Tagunov [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 06, 2003 5:46 AM
To: Tomcat Users List
Subject: Re: Character Encoding problem (umlauts, etc).


Hello Robert!

Robert Priest <[EMAIL PROTECTED]> wrote:
RP> I am requesting file :
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/äää.txt"
RP> but what is coming across in the request is:
RP> "/38CF278C0186B466222FC48571080B83/51/dms00051/???.txt"

Probably your browser is sending it that way?
I guess it is a bad idea anyways to type anything nasty
in the browser URL input line.

You may try to spy your interaction between browser and
server, I have described how to do it in one of the sections
of my ancient http://tagunov.tripod.com, try to find it there,
then you'll know for sure what bytes are sent by browser.

I guess that it is generally a bad idea to have anything
nasty in the url at all. The closest you could get would be
to encode it all as %AD and etc. But then you should be
sure what encoding this is (utf-8 or anything).

So, if these are links from your HTML page, why don't you
encode all in the url directly on the server side and
have 

but then why don't you get rid of these nasty umlauts at all?

Why not use only normal latin letters, or, in case you heavily use
numeric ids already, use only numeric ids?

Anton


-
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

encoding-problem with tomcat, jk2, apache

[Stefan Burkard]

hello tomcat-users

i've set up a cocoon-page with tomcat, apache and jk2. everything works 
fine as long as i just use languages with standard-encoding iso-8859-1.

now i'm on the way to implement the russian version of the site and 
therefore i need to display russian (cyrillic) characters.

if i connect on tomcat-standalone with port 8080, the russian characters 
are displayed correct.
but if i connect via apache and jk2, alle cyrillic characters go wrong. 
i think apache delivers the page with iso-8859-1 instead of utf-8.

does anybody know if this is a problem of apache or jk2 and how to solve 
it???

thanks
stefan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.0.28 form post encoding problem

[Krzysztof Cieniuch]

Hi I've got problem (again)  with encoding.
Yes I've read all bugs  23929 25360 etc.
No I didn't read www.anassina.com/struts/i18n/i18n.html because I can't
reach that site don't know why server down or my connection broken???

I've got two jsp pages index.jsp and out.jsp
On index.jsp I have simple form with one text input field (the name of this
text field is "user")
on out.jsp  page  I read that input with line like this
request.getParameter("user")
and of course when I use some national characters i.e not iso-8859-1 then I
get ??? on the out.jsp page
when i use
new
String(request.getParameter("user").getBytes("ISO-8859-1"),"ISO-8859-2");
everything is ok
I've tried everything :
-setting encoding
   -- in html meta tag
   -- in jsp page tag
   -- i use method Post in that  form

nothing works the browser allways sends data encoded in ISO-8859-1
so using through all my pages syntax like this
new
String(request.getParameter("user").getBytes("ISO-8859-1"),"ISO-8859-2");
is the only solution ??
I would like to use jsp and struts tags and then this is not an option
bean:write tag also gives ??? on national characters
I've changed server.xml connector  part and added URIencoding="ISO-8859-2"
and useBodyEncodingForURI=true this either doesn't help
and since I'm sending form data in body part of the request how should this
help anyhow

HELP the lost newbi :-)))

KC


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JSP encoding problem solution proposal (fwd)

[Craig R. McClanahan]

Since the topic of character encoding on requests came up on TOMCAT-USER
as well, I thought I'd forward a response I did on TOMCAT-DEV
earlier.  Read Andrey's message (at the bottom) first for this to make any
sense.

Craig


-- Forwarded message --
Date: Wed, 8 Aug 2001 09:52:53 -0700 (PDT)
From: Craig R. McClanahan <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Tomcat-Dev <[EMAIL PROTECTED]>
Subject: Re: JSP encoding problem solution proposal

Andrey has done a good job of describing the problem with calling
request.setCharacterEncoding() in JSP pages.  As an alternative to adding
a parameter to the JSP servlet (which would not be portable to other
containers), I'd like to offer a standards-based approach to this.

The basic approach I'm going to suggest is to use a Filter (also new in
the Servlet 2.3 API) to do the setCharacterEncoding() call for you.  This
has many advantages:

* It's portable across all 2.3-based containers

* You can use different rules for different portions of your webapp

* The rules you implement do not have to be as simple as "all requests
  use this character set" -- you can base the decision on other aspects
  of the request (like who the user is, objects in the session, what
  user agent they are using, and so on).

* The rules can be implemented (and updated later) without changing
  anything about your servlets and JSP pages, because it's done
  in a separate component.

As it happens, I recently added a simple Filter implementation that does
this to the examples webapp in Tomcat 4.  Check out
"/WEB-INF/classes/filters/SetCharacterEncodingFilter.java", which you are
free to use as the basis for setting character filtering in your own
apps.  The implementation provided is very simple (use an initialization
parameter to set the encoding unconditionally), but you can easily
subclass to make more sophisticated policy decisions.

Filters are your friend :-).

Craig



On Wed, 8 Aug 2001, Andrey Aristarkhov wrote:

> Hi All!
> 
> Different encodings support in Servlet/JSP is an ancient well-known problem.
> The setCharacterEncoding() method of HttpServletRequest allows to change
> request
> encoding before reading parameters. Thus, servlet is able to change encoding
> in
> accordance with its needs. (Small lyrical digression: what does this
> encoding mean?
> I'll post my thoughts about it separately)
> Howevet the problem still exists in JSP (there were several postings about
> the problem in
> this maillist). The purpose of this mail is to propose a solution for
> encodings support in JSP.
> 
> Problem description
> ===
> A JSP programmer is not able to change request encoding for incoming JSP
> request, since
> "This method [setCharacterEncoding] must be called prior to parsing any post
> data or
> reading any input from the request. Calling this method once data has been
> read will
> not affect the encoding." (Servlet 2.3 Spec). This happens because request
> parameters
> being read inside org.pache.jasper.servlet.JspServlet, before calling
> generated JSP-servlet.
> As a result we have the following behaviour of compiled JSP for non-English
> environments:
> 1) incoming request being read using 'ISO-8859-1'
> 2) getParameter() method returns a value in 'ISO-8859-1', but JSP-servlet
> suppose the
>return value has JVM default encoding (say "KOI8-R") -- here is ???
> instead of
>real parameter value. Here is a problem.
> 
> Problem solution
> 
> There should be a configurable optional parameter for JspServlet (say
> 'requestEncoding') to
> change request encoding. According to this parameter JspServlet should call
> setCharacterEncoding()
> before processing request. It does not conflict with JSP 1.2 Spec, since
> there are now any
> words about default encoding of incoming request over there.
> 
> I have made neccessary changes to implement this feature in
> tomcat-4.0-20010807. It works fine
> with different Cyrillic encodings. (Suppose the same result for the rest of
> non-Latin1 encodings).
> I clearly understand that proposed solution is not a panacea and it's a
> subject to discuss.
> 
> 
> Regards,
> Andrey Aristarkhov
> 
> 
> Diffs are followed (also as attachments). I have also attached a sample JSP
> for encoding testing.
> 
> 
> file: org/apache/jasper/EmbededServletOptions.java
> 
> 147a148,152
> >  * Java platform encoding for incoming request.
> >  */
> > private String requestEncoding;
> >
> > /**
> 219a225,228
> > public String getRequestEncoding() {
> > return requestEncoding;
> > }
> >
> 320

Re: Input from a FORM - encoding problem

[David Cassidy]

try this ...


FORM attribute

accept-charset = charset list [CI]
This attribute specifies the list of character encodings for input data that is 
accepted by the server processing this form. The value is a space- and/or 
comma-delimited list of charset values. The client must interpret this list as an
exclusive-or list, i.e., the server is able to accept any single character encoding 
per entity received.

The default value for this attribute is the reserved string "UNKNOWN". User agents 
may interpret this value as the character encoding that was used to transmit the 
document containing this FORM element.


http://www.w3.org/TR/html401/interact/forms.html#h-17.3


Let us know ...

Thanks

D




Nikola Milutinovic wrote:

> Hi all.
>
> I have a HTML FORM that I'd like to use to update data in my database. DB 
>(PostgreSQL + Unicode) is configured and correctly loaded with Unicode data. 
>Translations from UTF-8 -> Win-1250 works like a charm (and so does UTF-8 -> 
>ISO-8859-2).
>
> In other words, displaying the data is OK.
>
> Now I want to update fields and there is a problem. If I enter some of win-1250 
>chars in a textfield it gets translated to "?".
>
> A simple investigation shows that the loathed Win1250 -> '?' occurs within the 
>HTTPRequest object creation.
>
> How do I specify that the data coming from a FORM is Win1250 encoded?
> Do I do that in HTML FORM that submits the data (most likely)?
> Or do I do that in the JSP/Servlet accepting the data (highly unlikely)?
>
> I'm looking at HTML 4.01 specification, but so far I'm unlucky - nothing seams to 
>work.
>
> Nix.


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

RE: Input from a FORM - encoding problem

[Arnold Shore]

I'm using something like the ff, which works for me with IE6 and IIS:
mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 8:45 AM
To: Tomcat Users List
Subject: Input from a FORM - encoding problem


... Do I do that in HTML FORM that submits the data (most likely)?
Or do I do that in the JSP/Servlet accepting the data (highly unlikely)?

I'm looking at HTML 4.01 specification, but so far I'm unlucky - nothing
seams to work.

Nix.


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Input from a FORM - encoding problem

[Nikola Milutinovic]

> try this ...
> 
> 
> FORM attribute
> 
> accept-charset = charset list [CI]
> This attribute specifies the list of character encodings for input data that is 
>accepted by the server processing this form. The value is a space- and/or 
>comma-delimited list of charset values. The client must interpret this list as an
> exclusive-or list, i.e., the server is able to accept any single character encoding 
>per entity received.

Nothing yet. I've tried it. I'll try ISO-8859-2 tomorrow.

How doeas it work anyway? What does HTTP request have in headers for this encoding?

Nix.

Re: Input from a FORM - encoding problem

[Nikola Milutinovic]

> 
> FORM attribute
> 
> accept-charset = charset list [CI]
> This attribute specifies the list of character encodings for input data that is 
>accepted by the server processing this form. The value is a space- and/or 
>comma-delimited list of charset values. The client must interpret this list as an
> exclusive-or list, i.e., the server is able to accept any single character encoding 
>per entity received.

This bit is a "bit unclear" to me. If I specify several encodings, how will the 
browser know which one was actually used? How will the server know which one was used?

Nix.

Re: Input from a FORM - encoding problem

[Attila Szegedi]

Don't bother fiddling with  attributes. I've done this before to no avail.

Right now, no matter what you specify as an encoding in a HTML page, most browsers 
(all favorite IE and NN flavors) ignore it altogether and encode the form data using 
the encoding in which the page containing the form was sent to them. Worse yet, they 
*don't* specify the encoding of characters in the form data when sending them back via 
a POST request, so you must know on the server side what was the encoding of the page 
that contained the form. Servlet 2.3 spec is meant to contain a solution for this, but 
I don't know how is it (or isn't) implemented in Tomcat 4.x.

As if all of the above weren't enough, Tomcat 3.x gives yet another stab to 
internationalization efforts: it will blindly interpret all form data as being 
iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are lost. Again, I 
don't know how Tomcat 4.x line handles this. 

Being a Hungarian, I'm just as interested in entering 8859-2 characters in my pages, 
and not seeing ? marks on the server side, so I'm transcoding all form data strings on 
the fly. The off-the-wall solution looks like this:

param = new String(param.getBytes("8859_1"), "8859_2");

altough this tends to be slow (running through Java char-to-byte, then through 
byte-to-char machinery). I have developed a fast 8859-1 to 8859-2 transcoder that 
addresses speed issues; contact me in private mail and I can send it to you.

Cheers,
  Attila.
--
Attila Szegedi
home: http://www.szegedi.org

- Original Message - 
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: 2002. február 18. 15:17
Subject: Re: Input from a FORM - encoding problem


> > 
> > FORM attribute
> > 
> > accept-charset = charset list [CI]
> > This attribute specifies the list of character encodings for input data that 
>is accepted by the server processing this form. The value is a space- and/or 
>comma-delimited list of charset values. The client must interpret this list as an
> > exclusive-or list, i.e., the server is able to accept any single character 
>encoding per entity received.
> 
> This bit is a "bit unclear" to me. If I specify several encodings, how will the 
>browser know which one was actually used? How will the server know which one was used?
> 
> Nix.
> 


smime.p7s
Description: application/pkcs7-signature

RE: Input from a FORM - encoding problem

[Arnold Shore]

Re "Don't bother fiddling with  attributes. I've done this before to
no avail":

I'm accepting Arabic, Hebrew, Russian, and Chinese doing exactly that, with
IE 6 and using Unicode encodings. (Will be trying NN and Opera shortly.) And
yes, I'm also using that encoding on the page.

It's going into a database, with subsequent retrieval and display.  Works
correctly for the stuff I've tried.

Arnold Shore
Annapolis, MD USA

-Original Message-
From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 9:39 AM
To: Tomcat Users List
Subject: Re: Input from a FORM - encoding problem


Don't bother fiddling with  attributes. I've done this before to no
avail.

Right now, no matter what you specify as an encoding in a HTML page, most
browsers (all favorite IE and NN flavors) ignore it altogether and encode
the form data using the encoding in which the page containing the form was
sent to them. Worse yet, they *don't* specify the encoding of characters in
the form data when sending them back via a POST request, so you must know on
the server side what was the encoding of the page that contained the form.
Servlet 2.3 spec is meant to contain a solution for this, but I don't know
how is it (or isn't) implemented in Tomcat 4.x.

As if all of the above weren't enough, Tomcat 3.x gives yet another stab to
internationalization efforts: it will blindly interpret all form data as
being iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are
lost. Again, I don't know how Tomcat 4.x line handles this.

Being a Hungarian, I'm just as interested in entering 8859-2 characters in
my pages, and not seeing ? marks on the server side, so I'm transcoding all
form data strings on the fly. The off-the-wall solution looks like this:

param = new String(param.getBytes("8859_1"), "8859_2");

altough this tends to be slow (running through Java char-to-byte, then
through byte-to-char machinery). I have developed a fast 8859-1 to 8859-2
transcoder that addresses speed issues; contact me in private mail and I can
send it to you.

Cheers,
  Attila.
--
Attila Szegedi
home: http://www.szegedi.org

- Original Message -
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: 2002. február 18. 15:17
Subject: Re: Input from a FORM - encoding problem


> > 
> > FORM attribute
> >
> > accept-charset = charset list [CI]
> > This attribute specifies the list of character encodings for input
data that is accepted by the server processing this form. The value is a
space- and/or comma-delimited list of charset values. The client must
interpret this list as an
> > exclusive-or list, i.e., the server is able to accept any single
character encoding per entity received.
>
> This bit is a "bit unclear" to me. If I specify several encodings, how
will the browser know which one was actually used? How will the server know
which one was used?
>
> Nix.
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Input from a FORM - encoding problem

[Nikola Milutinovic]

Attila Szegedi wrote:

> Don't bother fiddling with  attributes. I've done this before to no avail.
> 
> Right now, no matter what you specify as an encoding in a HTML page, most

> browsers (all favorite IE and NN flavors) ignore it altogether and encode

> the form data using the encoding in which the page containing the form was

> sent to them. Worse yet, they *don't* specify the encoding of characters

> in the form data when sending them back via a POST request, so you must

> know on the server side what was the encoding of the page that contained

> the form. Servlet 2.3 spec is meant to contain a solution for this, but I

> don't know how is it (or isn't) implemented in Tomcat 4.x.


And how is it supposed to be specified? HTTP headers? Which ones?


> As if all of the above weren't enough, Tomcat 3.x gives yet another stab to

> internationalization efforts: it will blindly interpret all form data as

> being iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are

> lost. Again, I don't know how Tomcat 4.x line handles this.


I guess I'll have to dig into the code. (sigh) Oh well, at least I HAVE access 
to the source code.


> Being a Hungarian, I'm just as interested in entering 8859-2 characters in my

> pages, and not seeing ? marks on the server side, so I'm transcoding all form

> data strings on the fly. The off-the-wall solution looks like this:
> 
> param = new String(param.getBytes("8859_1"), "8859_2");


Where do you place this? Is it like:

param = request.getParameter( "name" );
param = new String(param.getBytes("8859_1"), "8859_2");

Basically, my question would be: once inside the JSP page, can I get parameters 
and re-code them some way or are they "destroyed" (transfigured to those pesky 
"?"s) upon construction oh HHTPResponse object?


> altough this tends to be slow (running through Java char-to-byte, then through

> byte-to-char machinery). I have developed a fast 8859-1 to 8859-2 transcoder

> that addresses speed issues; contact me in private mail and I can send it to you.


Sure. Send it, please.


BTW, I'm using Tomcat 4.01, so, if need be, I could employ some sort of filter,

but I'd like a proper solution. Tomcat 4 is supposed to be a reference Servlet

container, after all.


Nix.


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Input from a FORM - encoding problem

[Attila Szegedi]

- Original Message -
From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: 2002. február 18. 18:19
Subject: Re: Input from a FORM - encoding problem


> Attila Szegedi wrote:
> > Don't bother fiddling with  attributes. I've done this before to
no avail.
> > Right now, no matter what you specify as an encoding in a HTML page,
most
> > browsers (all favorite IE and NN flavors) ignore it altogether and
encode
> > the form data using the encoding in which the page containing the form
was
> > sent to them. Worse yet, they *don't* specify the encoding of characters
> > in the form data when sending them back via a POST request, so you must
> > know on the server side what was the encoding of the page that contained
> > the form. Servlet 2.3 spec is meant to contain a solution for this, but
I
> > don't know how is it (or isn't) implemented in Tomcat 4.x.
>
> And how is it supposed to be specified? HTTP headers? Which ones?
>

request.setCharacterEncoding(String encoding)

See http://www.servlets.com/soapbox/servlet23.html (Jason Hunter's article)
for more info.

> > As if all of the above weren't enough, Tomcat 3.x gives yet another stab
to
> > internationalization efforts: it will blindly interpret all form data as
> > being iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are
> > lost. Again, I don't know how Tomcat 4.x line handles this.
>
> I guess I'll have to dig into the code. (sigh) Oh well, at least I HAVE
access
> to the source code.
>
>
> > Being a Hungarian, I'm just as interested in entering 8859-2 characters
in my
> > pages, and not seeing ? marks on the server side, so I'm transcoding all
form
> > data strings on the fly. The off-the-wall solution looks like this:
> > param = new String(param.getBytes("8859_1"), "8859_2");
>
> Where do you place this? Is it like:
>
> param = request.getParameter( "name" );
> param = new String(param.getBytes("8859_1"), "8859_2");
>
> Basically, my question would be: once inside the JSP page, can I get
parameters
> and re-code them some way or are they "destroyed" (transfigured to those
pesky
> "?"s) upon construction oh HHTPResponse object?
>

There's a good chance they are not destroyed. I guess question marks are the
artifact of later transformation of the string to bytes (like when
generating a response). In the request, the byte value of your characters
should be preserved and thus transcoding should be possible.

>
> > altough this tends to be slow (running through Java char-to-byte, then
through
> > byte-to-char machinery). I have developed a fast 8859-1 to 8859-2
transcoder
> > that addresses speed issues; contact me in private mail and I can send
it to you.
>
> Sure. Send it, please.
>
>
> BTW, I'm using Tomcat 4.01, so, if need be, I could employ some sort of
filter,
> but I'd like a proper solution. Tomcat 4 is supposed to be a reference
Servlet
> container, after all.

Then try using request.setCharacterEncoding(String encoding) method before
you jump the gun and start coding the filter.

--
Attila Szegedi
home: http://www.szegedi.org


>
> Nix.
>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>
>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Input from a FORM - encoding problem

[Attila Szegedi]

OK: he might try. I admit I've not used IE6, only IEs up to 5.5 and NN up to
4.72, but it's a fact that:

- these browsers never appended a charset declaration to the Content-Type
header (i.e. "Content-Type: application/x-form-urlencoded" and not
"Content-Type: application/x-form-urlencoded; charset=iso-8859-2" so it was
up to the server side to figure out what the charset was.

- Tomcat 3.2.x blindly decoded form data as ISO-8859-1 (in fact, it is the
code in javax.servlet.http.HttpUtils#parsePostData() method which contains
the following much revealing comment:

// XXX we shouldn't assume that the only kind of POST body
// is FORM data encoded using ASCII or ISO Latin/1 ... or
// that the body should always be treated as FORM data.


So, even if your browser acts to the spec, Tomcat 3.2.x certainly does not.
I must underline that I don't know if 3.3.x or 4.x Tomcats rely on this
(flawed) code or not. Tomcat 4.x definitely should not, since it is supposed
to implement request.setCharacterEncoding()...

Cheers,
  Attila.

--
Attila Szegedi
home: http://www.szegedi.org


- Original Message -
From: "Arnold Shore" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: 2002. február 18. 16:58
Subject: RE: Input from a FORM - encoding problem


> Re "Don't bother fiddling with  attributes. I've done this before to
> no avail":
>
> I'm accepting Arabic, Hebrew, Russian, and Chinese doing exactly that,
with
> IE 6 and using Unicode encodings. (Will be trying NN and Opera shortly.)
And
> yes, I'm also using that encoding on the page.
>
> It's going into a database, with subsequent retrieval and display.  Works
> correctly for the stuff I've tried.
>
> Arnold Shore
> Annapolis, MD USA
>
> -Original Message-----
> From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 9:39 AM
> To: Tomcat Users List
> Subject: Re: Input from a FORM - encoding problem
>
>
> Don't bother fiddling with  attributes. I've done this before to no
> avail.
>
> Right now, no matter what you specify as an encoding in a HTML page, most
> browsers (all favorite IE and NN flavors) ignore it altogether and encode
> the form data using the encoding in which the page containing the form was
> sent to them. Worse yet, they *don't* specify the encoding of characters
in
> the form data when sending them back via a POST request, so you must know
on
> the server side what was the encoding of the page that contained the form.
> Servlet 2.3 spec is meant to contain a solution for this, but I don't know
> how is it (or isn't) implemented in Tomcat 4.x.
>
> As if all of the above weren't enough, Tomcat 3.x gives yet another stab
to
> internationalization efforts: it will blindly interpret all form data as
> being iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are
> lost. Again, I don't know how Tomcat 4.x line handles this.
>
> Being a Hungarian, I'm just as interested in entering 8859-2 characters in
> my pages, and not seeing ? marks on the server side, so I'm transcoding
all
> form data strings on the fly. The off-the-wall solution looks like this:
>
> param = new String(param.getBytes("8859_1"), "8859_2");
>
> altough this tends to be slow (running through Java char-to-byte, then
> through byte-to-char machinery). I have developed a fast 8859-1 to 8859-2
> transcoder that addresses speed issues; contact me in private mail and I
can
> send it to you.
>
> Cheers,
>   Attila.
> --
> Attila Szegedi
> home: http://www.szegedi.org
>
> - Original Message -
> From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: 2002. február 18. 15:17
> Subject: Re: Input from a FORM - encoding problem
>
>
> > > 
> > > FORM attribute
> > >
> > > accept-charset = charset list [CI]
> > > This attribute specifies the list of character encodings for input
> data that is accepted by the server processing this form. The value is a
> space- and/or comma-delimited list of charset values. The client must
> interpret this list as an
> > > exclusive-or list, i.e., the server is able to accept any single
> character encoding per entity received.
> >
> > This bit is a "bit unclear" to me. If I specify several encodings, how
> will the browser know which one was actually used? How will the server
know
> which one was used?
> >
> > Nix.
> >
>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>
>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Input from a FORM - encoding problem

[Satoshi Okamoto]

if its servlet, try this..

response.setContentType("text/html;charset=UR ENCODING TYPE");
PrintWriter out = new PrintWriter( new
OutputStreamWriter(response.getOutputStream(), "UR ENCODING TYPE"));

-Original Message-
From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 19, 2002 5:16 PM
To: Tomcat Users List
Subject: Re: Input from a FORM - encoding problem


OK: he might try. I admit I've not used IE6, only IEs up to 5.5 and NN up to
4.72, but it's a fact that:

- these browsers never appended a charset declaration to the Content-Type
header (i.e. "Content-Type: application/x-form-urlencoded" and not
"Content-Type: application/x-form-urlencoded; charset=iso-8859-2" so it was
up to the server side to figure out what the charset was.

- Tomcat 3.2.x blindly decoded form data as ISO-8859-1 (in fact, it is the
code in javax.servlet.http.HttpUtils#parsePostData() method which contains
the following much revealing comment:

// XXX we shouldn't assume that the only kind of POST body
// is FORM data encoded using ASCII or ISO Latin/1 ... or
// that the body should always be treated as FORM data.


So, even if your browser acts to the spec, Tomcat 3.2.x certainly does not.
I must underline that I don't know if 3.3.x or 4.x Tomcats rely on this
(flawed) code or not. Tomcat 4.x definitely should not, since it is supposed
to implement request.setCharacterEncoding()...

Cheers,
  Attila.

--
Attila Szegedi
home: http://www.szegedi.org


- Original Message -
From: "Arnold Shore" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: 2002. febru? 18. 16:58
Subject: RE: Input from a FORM - encoding problem


> Re "Don't bother fiddling with  attributes. I've done this before to
> no avail":
>
> I'm accepting Arabic, Hebrew, Russian, and Chinese doing exactly that,
with
> IE 6 and using Unicode encodings. (Will be trying NN and Opera shortly.)
And
> yes, I'm also using that encoding on the page.
>
> It's going into a database, with subsequent retrieval and display.  Works
> correctly for the stuff I've tried.
>
> Arnold Shore
> Annapolis, MD USA
>
> -Original Message-
> From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 9:39 AM
> To: Tomcat Users List
> Subject: Re: Input from a FORM - encoding problem
>
>
> Don't bother fiddling with  attributes. I've done this before to no
> avail.
>
> Right now, no matter what you specify as an encoding in a HTML page, most
> browsers (all favorite IE and NN flavors) ignore it altogether and encode
> the form data using the encoding in which the page containing the form was
> sent to them. Worse yet, they *don't* specify the encoding of characters
in
> the form data when sending them back via a POST request, so you must know
on
> the server side what was the encoding of the page that contained the form.
> Servlet 2.3 spec is meant to contain a solution for this, but I don't know
> how is it (or isn't) implemented in Tomcat 4.x.
>
> As if all of the above weren't enough, Tomcat 3.x gives yet another stab
to
> internationalization efforts: it will blindly interpret all form data as
> being iso-8859-1 (~ Cp1252), so your iso-8859-2 (~Cp1250) characters are
> lost. Again, I don't know how Tomcat 4.x line handles this.
>
> Being a Hungarian, I'm just as interested in entering 8859-2 characters in
> my pages, and not seeing ? marks on the server side, so I'm transcoding
all
> form data strings on the fly. The off-the-wall solution looks like this:
>
> param = new String(param.getBytes("8859_1"), "8859_2");
>
> altough this tends to be slow (running through Java char-to-byte, then
> through byte-to-char machinery). I have developed a fast 8859-1 to 8859-2
> transcoder that addresses speed issues; contact me in private mail and I
can
> send it to you.
>
> Cheers,
>   Attila.
> --
> Attila Szegedi
> home: http://www.szegedi.org
>
> - Original Message -
> From: "Nikola Milutinovic" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: 2002. febru? 18. 15:17
> Subject: Re: Input from a FORM - encoding problem
>
>
> > > 
> > > FORM attribute
> > >
> > > accept-charset = charset list [CI]
> > > This attribute specifies the list of character encodings for input
> data that is accepted by the server processing this form. The value is a
> space- and/or comma-delimited list of charset values. The client must
> interpret this list as an
> > > exclusive-or list, i.e., the server is able to

RE: Input from a FORM - encoding problem

[Larry Isaacs]

To address the encoding of input data, the Servlet 2.3 spec
provides request.setCharacterEncoding() which is supported
by Tomcat 4.x.  The comment shown below is one reason why
Tomcat 4.x implements its own parameter parsing and doesn't
use HttpUtils.parsePostData().

Since Tomcat 3.3 implements the Servlet 2.2 spec, it isn't
allowed to provide request.setCharacterEncoding().  However,
it does provide a couple of work arounds.  First, the default
behavior for DecodeInterceptor is to remember the encoding of
the last response sent to the browser if a session is present.
In the absence of any better alternative, it will use this
"remembered" encoding as the default input encoding for
the next request on that session.

DecodeInterceptor also allows the encoding to be
incorporated in the URL as a URI parameter.  The name
of the URI parameter defaults to "charset", but may
be configured.  Thus, the following URL would specify
UTF-8 as the input encoding:

http://localhost:8080/myapp/mypage.jsp;charset=UTF-8?myparm=parm1

The ";charset=UTF-8" would be silently removed from the request
URI so it isn't seen by servlets or JSP.  The small amount of
documentation on this is found here:

<http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#DecodeInterceptor>

Obviously, both of these workarounds are Tomcat 3.3 specific
and would not be portable.  The Servlet 2.2 spec provides no
portable means of addressing input encoding.  You must use
a Servlet 2.3 compliant container such as Tomcat 4.x to get
the portable setCharacterEncoding() approach.

Cheers,
Larry

> -Original Message-
> From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 19, 2002 3:16 AM
> To: Tomcat Users List
> Subject: Re: Input from a FORM - encoding problem
> 
> 
> OK: he might try. I admit I've not used IE6, only IEs up to 
> 5.5 and NN up to
> 4.72, but it's a fact that:
> 
> - these browsers never appended a charset declaration to the 
> Content-Type
> header (i.e. "Content-Type: application/x-form-urlencoded" and not
> "Content-Type: application/x-form-urlencoded; 
> charset=iso-8859-2" so it was
> up to the server side to figure out what the charset was.
> 
> - Tomcat 3.2.x blindly decoded form data as ISO-8859-1 (in 
> fact, it is the
> code in javax.servlet.http.HttpUtils#parsePostData() method 
> which contains
> the following much revealing comment:
> 
> // XXX we shouldn't assume that the only kind of POST body
> // is FORM data encoded using ASCII or ISO Latin/1 ... or
> // that the body should always be treated as FORM data.
> 
> 
> So, even if your browser acts to the spec, Tomcat 3.2.x 
> certainly does not.
> I must underline that I don't know if 3.3.x or 4.x Tomcats 
> rely on this
> (flawed) code or not. Tomcat 4.x definitely should not, since 
> it is supposed
> to implement request.setCharacterEncoding()...
> 
> Cheers,
>   Attila.
> 
> --
> Attila Szegedi
> home: http://www.szegedi.org
> 
> 
> - Original Message -
> From: "Arnold Shore" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: 2002. február 18. 16:58
> Subject: RE: Input from a FORM - encoding problem
> 
> 
> > Re "Don't bother fiddling with  attributes. I've done 
> this before to
> > no avail":
> >
> > I'm accepting Arabic, Hebrew, Russian, and Chinese doing 
> exactly that,
> with
> > IE 6 and using Unicode encodings. (Will be trying NN and 
> Opera shortly.)
> And
> > yes, I'm also using that encoding on the page.
> >
> > It's going into a database, with subsequent retrieval and 
> display.  Works
> > correctly for the stuff I've tried.
> >
> > Arnold Shore
> > Annapolis, MD USA
> >
> > -Original Message-
> > From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, February 18, 2002 9:39 AM
> > To: Tomcat Users List
> > Subject: Re: Input from a FORM - encoding problem
> >
> >
> > Don't bother fiddling with  attributes. I've done 
> this before to no
> > avail.
> >
> > Right now, no matter what you specify as an encoding in a 
> HTML page, most
> > browsers (all favorite IE and NN flavors) ignore it 
> altogether and encode
> > the form data using the encoding in which the page 
> containing the form was
> > sent to them. Worse yet, they *don't* specify the encoding 
> of characters
> in
> > the form data when sending them back via a POST request, so 
> you must know
> on
> > the server side what was the encodin

Re[2]: Character Encoding problem (umlauts, etc).

[Anton Tagunov]

Hello Robert!

RP> Thanks for the information Anton. But just getting rid of umlauts or other
RP> international characters is not an option when you have clients that use
RP> your software in other countries, that have those special characters. We
RP> cannot rename user files or changed that data. That would be very, very, bad
RP> :)

Well, getting rid of them was only my second suggestion.
The first one was that we should make sure they all
get %xy encoded in the url.

So, first of all, have you detected if it
is your browser or Tomcat to blame?

I advice you to spy the traffic and see for yourself what
you browser is sending.

Is the browser sending non-ascii chars as '?'-s?
Is the browser sending them as raw 8-bit text?
Is the browser %xy-encoding them?

(The last will be the effect we want.
All other don't meet our needs).

As I've said before the methods to spy these (the methods that I
have know, there should be others :-) are on my page
at tagunov.tripod.com. If you can supply this info -- what is
the browser actually sending -- we will be able to move further
on with your needs.

Good luck!

Anton


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: encoding-problem with tomcat, jk2, apache

[Yansheng Lin]

Hi Stefan, you figured out this problem yet.  I would like to know what was
causing the problem:).  Did you take a look at the header?  Compare the headers
generated when running tomcat standalone with running apache-tomcat to see the
difference.  (I used a Encoding Filter for my i18n application, so far all the
development had been done on a localhost).  

Good luck!

-Yan

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
Sent: Tuesday, February 03, 2004 10:41 AM
To: [EMAIL PROTECTED]
Subject: encoding-problem with tomcat, jk2, apache


hello tomcat-users

i've set up a cocoon-page with tomcat, apache and jk2. everything works 
fine as long as i just use languages with standard-encoding iso-8859-1.

now i'm on the way to implement the russian version of the site and 
therefore i need to display russian (cyrillic) characters.

if i connect on tomcat-standalone with port 8080, the russian characters 
are displayed correct.
but if i connect via apache and jk2, alle cyrillic characters go wrong. 
i think apache delivers the page with iso-8859-1 instead of utf-8.

does anybody know if this is a problem of apache or jk2 and how to solve 
it???

thanks
stefan



-
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]

Re: encoding-problem with tomcat, jk2, apache

[Stefan Burkard]

hi folks

ok, i've found a tool that shows the whole http-header of my requests:

if i connect directly on tomcat (port 8080) there is a 
content-type-attribute in the header that says just "text/html".

if i connect via apache/mod_jk2 the attribute has the data "text/html; 
charset=ISO-8859-1" what is completely wrong. it should be utf-8, not 
iso-8859-1.

cocoon automatically inserts the code
 into 
the html-page.

so the resulting question: why has apache/jk2 the wrong encoding? is 
there a default-encoding that is used if nothing other is specified?

greetings
stefan
Yansheng Lin wrote:
Hi Stefan, you figured out this problem yet.  I would like to know what was
causing the problem:).  Did you take a look at the header?  Compare the headers
generated when running tomcat standalone with running apache-tomcat to see the
difference.  (I used a Encoding Filter for my i18n application, so far all the
development had been done on a localhost).  

Good luck!

-Yan

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
Sent: Tuesday, February 03, 2004 10:41 AM
To: [EMAIL PROTECTED]
Subject: encoding-problem with tomcat, jk2, apache
hello tomcat-users

i've set up a cocoon-page with tomcat, apache and jk2. everything works 
fine as long as i just use languages with standard-encoding iso-8859-1.

now i'm on the way to implement the russian version of the site and 
therefore i need to display russian (cyrillic) characters.

if i connect on tomcat-standalone with port 8080, the russian characters 
are displayed correct.
but if i connect via apache and jk2, alle cyrillic characters go wrong. 
i think apache delivers the page with iso-8859-1 instead of utf-8.

does anybody know if this is a problem of apache or jk2 and how to solve 
it???

thanks
stefan


-
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]

RE: encoding-problem with tomcat, jk2, apache

[Edson Alves Pereira]

You must check your java´s file.encoding property, maybe its setted
to ISO-8859-1
> --
> De:   Stefan Burkard[SMTP:[EMAIL PROTECTED]
> Responder:Tomcat Users List
> Enviada:  quinta-feira, 5 de fevereiro de 2004 9:18
> Para: [EMAIL PROTECTED]
> Assunto:  Re: encoding-problem with tomcat, jk2, apache
> 
> hi folks
> 
> ok, i've found a tool that shows the whole http-header of my requests:
> 
> if i connect directly on tomcat (port 8080) there is a 
> content-type-attribute in the header that says just "text/html".
> 
> if i connect via apache/mod_jk2 the attribute has the data "text/html; 
> charset=ISO-8859-1" what is completely wrong. it should be utf-8, not 
> iso-8859-1.
> 
> cocoon automatically inserts the code
>  into 
> the html-page.
> 
> so the resulting question: why has apache/jk2 the wrong encoding? is 
> there a default-encoding that is used if nothing other is specified?
> 
> greetings
> stefan
> 
> 
> Yansheng Lin wrote:
> > Hi Stefan, you figured out this problem yet.  I would like to know what
> was
> > causing the problem:).  Did you take a look at the header?  Compare the
> headers
> > generated when running tomcat standalone with running apache-tomcat to
> see the
> > difference.  (I used a Encoding Filter for my i18n application, so far
> all the
> > development had been done on a localhost).  
> > 
> > Good luck!
> > 
> > -Yan
> > 
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
> > Sent: Tuesday, February 03, 2004 10:41 AM
> > To: [EMAIL PROTECTED]
> > Subject: encoding-problem with tomcat, jk2, apache
> > 
> > 
> > hello tomcat-users
> > 
> > i've set up a cocoon-page with tomcat, apache and jk2. everything works 
> > fine as long as i just use languages with standard-encoding iso-8859-1.
> > 
> > now i'm on the way to implement the russian version of the site and 
> > therefore i need to display russian (cyrillic) characters.
> > 
> > if i connect on tomcat-standalone with port 8080, the russian characters
> 
> > are displayed correct.
> > but if i connect via apache and jk2, alle cyrillic characters go wrong. 
> > i think apache delivers the page with iso-8859-1 instead of utf-8.
> > 
> > does anybody know if this is a problem of apache or jk2 and how to solve
> 
> > it???
> > 
> > thanks
> > stefan
> > 
> > 
> > 
> > -
> > 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]
> 

RE: encoding-problem with tomcat, jk2, apache

[Yansheng Lin]

Oh hi, I researched on the following problme last night.  And like you said, I
could display my Japanese UTF-8 encoded file with Tomcat correctly, but not with
Apache-Tomcat-jk2.  Somehow the charset was still iso-8859-1.  I couldn't figure
out why apache didn't use the UTF-8 encoding defined in httpd.conf:
AddCharset UTF-8   .utf8

So my quick fix was to change the default charset to UTF-8:
AddDefaultCharset UTF-8

After that I could see in my header, the charset is utf-8.  And I could view the
Japanese hiragan's with Apache.  But since all my pages were display under
utf-8, the font was kind of screwed up(utf-8 has less font support).  So I don't
think I found the solution to your problem.  And I couldn't spend more time on
that. Let me know if you get this one figured out.  

Have fun!

-Yan

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
Sent: Thursday, February 05, 2004 5:18 AM
To: [EMAIL PROTECTED]
Subject: Re: encoding-problem with tomcat, jk2, apache


hi folks

ok, i've found a tool that shows the whole http-header of my requests:

if i connect directly on tomcat (port 8080) there is a 
content-type-attribute in the header that says just "text/html".

if i connect via apache/mod_jk2 the attribute has the data "text/html; 
charset=ISO-8859-1" what is completely wrong. it should be utf-8, not 
iso-8859-1.

cocoon automatically inserts the code
 into 
the html-page.

so the resulting question: why has apache/jk2 the wrong encoding? is 
there a default-encoding that is used if nothing other is specified?

greetings
stefan


Yansheng Lin wrote:
> Hi Stefan, you figured out this problem yet.  I would like to know what was
> causing the problem:).  Did you take a look at the header?  Compare the
headers
> generated when running tomcat standalone with running apache-tomcat to see the
> difference.  (I used a Encoding Filter for my i18n application, so far all the
> development had been done on a localhost).  
> 
> Good luck!
> 
> -Yan
> 
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
> Sent: Tuesday, February 03, 2004 10:41 AM
> To: [EMAIL PROTECTED]
> Subject: encoding-problem with tomcat, jk2, apache
> 
> 
> hello tomcat-users
> 
> i've set up a cocoon-page with tomcat, apache and jk2. everything works 
> fine as long as i just use languages with standard-encoding iso-8859-1.
> 
> now i'm on the way to implement the russian version of the site and 
> therefore i need to display russian (cyrillic) characters.
> 
> if i connect on tomcat-standalone with port 8080, the russian characters 
> are displayed correct.
> but if i connect via apache and jk2, alle cyrillic characters go wrong. 
> i think apache delivers the page with iso-8859-1 instead of utf-8.
> 
> does anybody know if this is a problem of apache or jk2 and how to solve 
> it???
> 
> thanks
> stefan
> 
> 
> 
> -
> 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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: encoding-problem with tomcat, jk2, apache

[Yan Lin]

(SORRY IF THIS IS A DUPLICATE, MY MESSAGE DIDN'T GO
THROUGH?  I AM USING A DIFFERENT ACCOUNT.)

---
Oh hi, I researched on the following problme last
night.  And like you said, I could display my Japanese
UTF-8 encoded file with Tomcat correctly, but not with
Apache-Tomcat-jk2.  Somehow the charset was still
iso-8859-1.  I couldn't figure out why apache didn't
use the UTF-8 encoding defined in httpd.conf:
AddCharset UTF-8   .utf8

So my quick fix was to change the default charset to
UTF-8:
AddDefaultCharset UTF-8

After that I could see in my header, the charset is
utf-8.  And I could view the Japanese hiragan's with
Apache.  But since all my pages were display under
utf-8, the font was kind of screwed up(utf-8 has less
font support).  So I don't think I found the solution
to your problem.  And I couldn't spend more time on
that. Let me know if you get this one figured out.  

Have fun!

-Yan
-

> > --
> > De: Stefan Burkard[SMTP:[EMAIL PROTECTED]
> > Responder:  Tomcat Users List
> > Enviada:quinta-feira, 5 de fevereiro de 2004
> 9:18
> > Para:   [EMAIL PROTECTED]
> > Assunto:Re: encoding-problem with tomcat, jk2,
> apache
> > 
> > hi folks
> > 
> > ok, i've found a tool that shows the whole
> http-header of my requests:
> > 
> > if i connect directly on tomcat (port 8080) there
> is a 
> > content-type-attribute in the header that says
> just "text/html".
> > 
> > if i connect via apache/mod_jk2 the attribute has
> the data "text/html; 
> > charset=ISO-8859-1" what is completely wrong. it
> should be utf-8, not 
> > iso-8859-1.
> > 
> > cocoon automatically inserts the code
> >  content="text/html; charset=UTF-8"> into 
> > the html-page.
> > 
> > so the resulting question: why has apache/jk2 the
> wrong encoding? is 
> > there a default-encoding that is used if nothing
> other is specified?
> > 
> > greetings
> > stefan
> > 
> > 
> > Yansheng Lin wrote:
> > > Hi Stefan, you figured out this problem yet.  I
> would like to know what
> > was
> > > causing the problem:).  Did you take a look at
> the header?  Compare the
> > headers
> > > generated when running tomcat standalone with
> running apache-tomcat to
> > see the
> > > difference.  (I used a Encoding Filter for my
> i18n application, so far
> > all the
> > > development had been done on a localhost).  
> > > 
> > > Good luck!
> > > 
> > > -Yan
> > > 
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf
> Of Stefan Burkard
> > > Sent: Tuesday, February 03, 2004 10:41 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: encoding-problem with tomcat, jk2,
> apache
> > > 
> > > 
> > > hello tomcat-users
> > > 
> > > i've set up a cocoon-page with tomcat, apache
> and jk2. everything works 
> > > fine as long as i just use languages with
> standard-encoding iso-8859-1.
> > > 
> > > now i'm on the way to implement the russian
> version of the site and 
> > > therefore i need to display russian (cyrillic)
> characters.
> > > 
> > > if i connect on tomcat-standalone with port
> 8080, the russian characters
> > 
> > > are displayed correct.
> > > but if i connect via apache and jk2, alle
> cyrillic characters go wrong. 
> > > i think apache delivers the page with iso-8859-1
> instead of utf-8.
> > > 
> > > does anybody know if this is a problem of apache
> or jk2 and how to solve
> > 
> > > it???
> > > 
> > > thanks
> > > stefan
> > > 
> > > 
> > > 
> > >
>
-
> > > 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]
> > 
> 


__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: encoding-problem with tomcat, jk2, apache

[Stefan Burkard]

isn't this file.encoding about how the java-vm reads and writes files in 
the filesystem? my problem is just in delivery through apache. tomcat 
itself displays everything correct.

but i did another test in the meantime:
-> when i edit the "addDefaultCharset"-directive of apache2 to UTF-8 it 
works fine with apache/jk2! but i can't change this value because of the 
risk to break other websites on the same server.

so i think i should be able to tell tomcat that he sould deliver this 
pages in utf-8. how i explained in postings below, it just says 
"text/html" in the header - no encoding. and therefore apache adds its 
standardencoding of iso-8859-1

can anybody tell me how to tell tomcat to deliver pages in a specific 
encoding?

greetings
stefan
Edson Alves Pereira wrote:
You must check your java´s file.encoding property, maybe its setted
to ISO-8859-1
--
De: Stefan Burkard[SMTP:[EMAIL PROTECTED]
Responder:  Tomcat Users List
Enviada:quinta-feira, 5 de fevereiro de 2004 9:18
Para:   [EMAIL PROTECTED]
Assunto:Re: encoding-problem with tomcat, jk2, apache
hi folks

ok, i've found a tool that shows the whole http-header of my requests:

if i connect directly on tomcat (port 8080) there is a 
content-type-attribute in the header that says just "text/html".

if i connect via apache/mod_jk2 the attribute has the data "text/html; 
charset=ISO-8859-1" what is completely wrong. it should be utf-8, not 
iso-8859-1.

cocoon automatically inserts the code
 into 
the html-page.

so the resulting question: why has apache/jk2 the wrong encoding? is 
there a default-encoding that is used if nothing other is specified?

greetings
stefan
Yansheng Lin wrote:

Hi Stefan, you figured out this problem yet.  I would like to know what
was

causing the problem:).  Did you take a look at the header?  Compare the
headers

generated when running tomcat standalone with running apache-tomcat to
see the

difference.  (I used a Encoding Filter for my i18n application, so far
all the

development had been done on a localhost).  

Good luck!

-Yan

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Burkard
Sent: Tuesday, February 03, 2004 10:41 AM
To: [EMAIL PROTECTED]
Subject: encoding-problem with tomcat, jk2, apache
hello tomcat-users

i've set up a cocoon-page with tomcat, apache and jk2. everything works 
fine as long as i just use languages with standard-encoding iso-8859-1.

now i'm on the way to implement the russian version of the site and 
therefore i need to display russian (cyrillic) characters.

if i connect on tomcat-standalone with port 8080, the russian characters

are displayed correct.
but if i connect via apache and jk2, alle cyrillic characters go wrong. 
i think apache delivers the page with iso-8859-1 instead of utf-8.

does anybody know if this is a problem of apache or jk2 and how to solve

it???

thanks
stefan


-
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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.0.28 form post encoding problem

[Martin Schaefer]

Again (there was a similar problem today), it might help to run tomcat
with -Dfile.encoding=ISO-8859-2
Or better use UTF-8 if applicable...


Krzysztof Cieniuch <[EMAIL PROTECTED]> schrieb am 17.09.2004, 16:42:36:
> Hi I've got problem (again)  with encoding.
> Yes I've read all bugs  23929 25360 etc.
> No I didn't read www.anassina.com/struts/i18n/i18n.html because I can't
> reach that site don't know why server down or my connection broken???
> 
> I've got two jsp pages index.jsp and out.jsp
> On index.jsp I have simple form with one text input field (the name of this
> text field is "user")
> on out.jsp  page  I read that input with line like this
> request.getParameter("user")
> and of course when I use some national characters i.e not iso-8859-1 then I
> get ??? on the out.jsp page
> when i use
> new
> String(request.getParameter("user").getBytes("ISO-8859-1"),"ISO-8859-2");
> everything is ok
> I've tried everything :
> -setting encoding
>-- in html meta tag
>-- in jsp page tag
>-- i use method Post in that  form
> 
> nothing works the browser allways sends data encoded in ISO-8859-1
> so using through all my pages syntax like this
> new
> String(request.getParameter("user").getBytes("ISO-8859-1"),"ISO-8859-2");
> is the only solution ??
> I would like to use jsp and struts tags and then this is not an option
> bean:write tag also gives ??? on national characters
> I've changed server.xml connector  part and added URIencoding="ISO-8859-2"
> and useBodyEncodingForURI=true this either doesn't help
> and since I'm sending form data in body part of the request how should this
> help anyhow
> 
> HELP the lost newbi :-)))
> 
> KC
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Martin Schaefer
NAXOS Software Solutions GmbH i.G.
Herrenstr. 1
69502 Hemsbach
Germany
 
Phone:+49 (0) 6201 49298-2
Mobile: +49 (0) 172 6269246
Fax: +49 (0) 6201 49298-1
Mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.0.28 form post encoding problem

[Krzysztof Cieniuch]

- Original Message - 
From: "Martin Schaefer" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 4:54 PM
Subject: Re: Tomcat 5.0.28 form post encoding problem


>
> Again (there was a similar problem today), it might help to run tomcat
> with -Dfile.encoding=ISO-8859-2
> Or better use UTF-8 if applicable...
>
>

That didn't help what now ?? Any hint how to debug this problem what check
first ???

KC


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

charector encoding Problem while running servlet in tomcat

[Sibi Joseph]

hi all

I have a servlet which outputs some chinese content to the browser. The webserver i 
used is Tomcat3.2.3. 

if i try browsing chinese sites with chinese char encoding on a english version of 
windows 2000 the pages comes well without specifying any encoding. 

When i used the same servlet in the Chinese Version of windows 2000, i had to set the 
characterset in the servletresponse (ie. hsResponse.setContentType 
"text/plain;charset=gb2312") to display the page correctly in the browser. 


If i specify the encoding scheme like above pages (both  chinese and english) are 
displayed properly in windows 2000 chinese version but chinese pages will not display 
properly in the english version of windows 2000. 

There was no problems in displaying pages with english content in both versions of 
windows (both when the encoding is specified and when it is not).

Now my question is

1) why does this happen?

2) Is there any way of getting the default encoding of a machine and set the servlets 
encoding scheme accordingly. 


NOTE:

The default encoding scheme in english version of windows 2000 was found to be Cp1252 
and GBK in Chinese version


thanks in advance

sibi

Re: Input from a FORM - encoding problem SOLVED

[Nikola Milutinovic]

The solution was to set the character encoding on the request (not on the response) 
object. Aparently, the parameters of the request are fetched on method call, which is 
a nice thing :-)

Thanks to all who helped.

And, by the way, IE6 doesn't honour "enctype" of the FORM, just splashes it's default, 
which doesn't include encoding info.

Nix.

Please Help Me ; encoding problem at JSP compil.

[CLAVIER Remi FTRD/RTA/LAN]

When I try to execute a JSP file, I have aan error like this.
>>org.apache.jasper.JasperException: Unable to compile class for
JSPC:\tomcat\webapps\examples\WEB->>INF\classes\DALNet\VisuWeb.java:1: The
source file encoding may be different with this platform encoding. Please
use ->>encoding option to adjust file encoding, or apply native2ascii
utility to make source file ASCII encoding.

When I compile the java file used by my JSP using javac, I've not this kind
of error...
When I use the entire site in another Java Server Page, I'not this error
(Resin is Used from months without this kind of error message)..
It sure the my java source files are written using the full french
alphabet... and I want to continue to use it!!!

But how can I said to the compiler  to use the correct encoding and avoid
this compilation error.

Thanks for help.

Rémi Clavier
France Télécom R&D / RTA/  D2M
Technopole Anticipa
2, Avenue Pierre Marzin Téléphone : (+33 )  (0) 2 96 05 2220
22307 Lannion Cedex Fax :   (+33 )  (0) 2 96 05 1252
FRANCE
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

encoding problem: tomcat requires restart after computer reboot

[Μιχαλίδης Κώστας]

Hi all,

i'm having a strange problem to which i ran out of ideas on how to get it
fixed.
I'm running Tomcat 4.0 as a windows-service on Win2K Server (SP3).

The problem is that JSP pages with foreign content (iso-8859-7 encoding,
Greek) 
are not displayed correctly immediately AFTER the computer has been
restarted.
To fix it all i need to do is to restart the Tomcat service, 
after which everything works as expected, pages display "normal" Greek.
This is problematic after, lets say, a power failure where the
machine reboots and requires operator interaction to restart the Tomcat
service.

I found that during installation of Windows on a fresh machine, under no 
circumstances must one select Greek locale during regional settings setup.
If Greek is selected this cannot be undone and the only whay to make Tomcat
work correctly is to re-install Windows OS on a fresh machine.
Also, if at any point after succesfull installation the locale is changed to

Greek the same problem occurs.
Changing the locale back to English does not fix the problem.

Has anybody seen anything like this?
What can i do to avoid a clean install?

Thanks to all / Costa Mihalidis (Athens, Greece)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to solve the character encoding problem with JSP

[Andre Tampold]

Hello all Tomcat users!

I'm new to Tomcat. Installed it yesterday and it seems to me running very
well.

Only one question is arised, which probably is answered already, but I did
not found answer for that from archive.

Currently in production we have JavaWebServer2.0 / Win NT, JDK1.3 and this
works very well for solving encoding problem with JSP:


///
//
//  How to solve the character encoding problem with JSP
//  
//
// 1. Comment out this line in generated file's _jspService method:
// JspWriter out = null;

// 2. Insert this line where you commented out number 1:
// PrintWriter out = response.getWriter();

// 3. Comment out this line in generated file's _jspService method:
// out = pageContext.getOut();

// 4. At the end of the _jspService method you find:
// } catch (Throwable t) {
//  * if (out.getBufferSize() != 0)
//  * out.clear();
//  Lines marked with * shall be commented out.
//
// 5. After lines mentioned in point 4 you find:
//  HandleErrorPageException("...errorpage.jsp", t, out);
//Change it to:
//  HandleErrorPageException("...errorpage.jsp", t,
pageContext.getOut());

///

Actually there are some Lexicon files in Cp1251, Cp1257 and UTF-8 encodings,
which need to come through JSP to browser. With JavaWebServer2.0 this is ok,
if we do as described in steps 1.-5.

How to do it with Tomcat? I did the same but it seems to me no effect at
all. Only  marks or unreadable characters. What is missing?

Thanks in advance for any kind of info/URL/help,

Andre Tampõld
Software Development @ EMK

Encoding problem with jikes with tomcat-4.1.18 under Windows

[Zsolt Koppany]

Hi,

I have configured tomcat (-Dbuild.compiler=jikes) to use jikes (1.18) under
Windows but I get an error because of encoding problems. I would like to
work with jikes because that is much faster than the built-in compiler. How
can I fix this issue?

Zsolt



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Encoding problem with jikes with tomcat-4.1.18 under Windows

[Zsolt Koppany]

Hi,

I have configured tomcat (-Dbuild.compiler=jikes) to use jikes (1.18) under
Windows-XP but I get an error because of encoding problems. I would like to
work with jikes because that is much faster than the built-in compiler. How
can I fix this issue?


Zsolt Koppany
Intland Software GmbH
mailto:[EMAIL PROTECTED]
Schulze-Delitzsch-Strasse 16
D-70565 Stuttgart
Phone: +49-711-7221873
Fax:   +49-711-7871017





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache Webserver and Tomcat: encoding problem with UTF-8

[Gregor Kappler]

Hi, I have the following problem with mod_jk on apache 1.3.26 (SLES8):
we have a Tomcat 3.3.1a, and changed the default request charset (ISO 
8859-1) to utf-8 via
  in server.xml.
The generated HTML always has UTF-8 encoding.
As long we work with tomcat alone, everything works fine:
When we get the GET/POST Request of a form with some non ASCII 
characters, they are correctly transfered (even when resent to the 
client as value in the field of a form).

But I get a problem when using the connector with apache webserver. The 
connection is working, and we can do nearly everything via apaches port 
80. While on tomcat port 8080 everything still works, on port 80 we 
always get broken special characters at the server. It seems, that the 
apache webserver assumes wrong encoding of the URI or wrong exspected 
encoding of the tomcat and passes some converted characters -- while it 
should not do any conversions at all!

Are there any configurations of the apache webserver that solve this 
Problem?
It would be nice if somebody could help me,

Gregor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

UTF-8 encoding problem with file included using jsp:include

[Camilla Clifford]

Hello,

I have a jsp page with the following code at the top of the page, in 
order to display the page contents in UTF-8:

<%@ page contentType="text/html; charset=UTF-8" %>
<% response.setContentType("text/html; charset=UTF-8"); %>
In this page is a jsp:include tag that includes a static html file, the 
name of which is determined at runtime. This included file contains 
UTF-8 encoded characters, however these are not being displayed 
correctly in my browser  (mozilla 1.5/debian), but as generic 'unknown 
unicode' chars. If I use an include directive instead however, the 
characters are displayed correctly. If I change the extension of the 
included file to .jsp so that it's compiled (just to see what happends) 
the characters still don't display because the .java file generated by 
Jasper has a response.setContentType("iso-8859-1") line inserted into 
it, which I've been unable to figure out how to change.

It seems likely that somewhere along the line, the content type of the 
included file  (html or jsp) is being set and this setting is taking 
precedence over the page directives I have in the including page.  I've 
tried setting everything I can think of to UTF-8 (file encoding, 
response and request objects), I've checked that the JSP compiler should 
be compiling using UTF-8  (I'm using tomcat 4.1.29) (even though this 
shouldn't really affect and included html file) but I can't seem to get 
the included file encoded correctly.

Does anyone know what setting is responsible for the 
response.setContentType line inserted by jasper, or have any further 
ideas that I could investigate ?

Many thanks,
..camilla
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]