Re: Encoding problem

2009-10-05 Thread Yannis Haralambous
It works! Thank you so much Michael!!Long live Toronto!Le 5 oct. 2009 à 21:14, Michael Glavassevich a écrit :Try calling flush() on the Writer. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Yannis Haralambous

Re: Encoding problem

2009-10-05 Thread Michael Glavassevich
Try calling flush() on the Writer. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Yannis Haralambous wrote on 10/05/2009 02:13:00 PM: > Le 5 oct. 2009 à 17:23, Michael Glavassevich a écrit : > > Wrap System.out in an OutputSt

Re: Encoding problem

2009-10-05 Thread Yannis Haralambous
Le 5 oct. 2009 à 17:23, Michael Glavassevich a écrit : Wrap System.out in an OutputStreamWriter: Writer writer = new OutputStreamWriter(System.out, "UTF-8"); and call the write() methods on this Writer. Always do this when you want a specific encoding. Relying on the default encoding is a b

Re: Encoding problem

2009-10-05 Thread Michael Glavassevich
Wrap System.out in an OutputStreamWriter: Writer writer = new OutputStreamWriter(System.out, "UTF-8"); and call the write() methods on this Writer. Always do this when you want a specific encoding. Relying on the default encoding is a bug waiting to happen even if you think you can control it.

Re: Encoding problem

2009-10-05 Thread Yannis Haralambous
thank for you answerbut still there are some things I don't understand:1) the locale of my system is:LANG="fr_FR.UTF-8"LC_COLLATE="fr_FR.UTF-8"LC_CTYPE="fr_FR.UTF-8"LC_MESSAGES="fr_FR.UTF-8"LC_MONETARY="fr_FR.UTF-8"LC_NUMERIC="fr_FR.UTF-8"LC_TIME="fr_FR.UTF-8"LC_ALL=so, clearly, UTF-8 is the defaul

Re: Encoding problem

2009-10-05 Thread keshlam
ested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html) Michael Glavassevich 10/05/2009 09:33 AM Please respond to j-users@xerces.apache.org To j-users@xerces.apache.org cc Sub

Re: Encoding problem

2009-10-05 Thread Michael Glavassevich
FYI: I meant PrintStream.print() [1] though the PrintWriter variant also uses the default encoding. [1] http://java.sun.com/javase/6/docs/api/java/io/PrintStream.html#print (java.lang.String) Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@

Re: Encoding problem

2009-10-05 Thread Michael Glavassevich
kesh...@us.ibm.com wrote on 10/05/2009 09:19:32 AM: > > There is no stylesheet, I'm not using any XSLT file. It is simply > SAX reading the XML file and writing to standard output. > > Sorry; I'm used to thinking in terms of Xalan rather than Xerces and > gave the wrong answer. > > Can you confirm

Re: Encoding problem

2009-10-05 Thread keshlam
> There is no stylesheet, I'm not using any XSLT file. It is simply SAX reading the XML file and writing to standard output. Sorry; I'm used to thinking in terms of Xalan rather than Xerces and gave the wrong answer. Can you confirm whether the problem is occurring in the parser or on the the

Re: Encoding problem

2009-10-05 Thread Yannis Haralambous
There is no stylesheet, I'm not using any XSLT file. It is simply SAX reading the XML file and writing to standard output.Maybe I'm missing some crucial information?Le 5 oct. 2009 à 14:41, kesh...@us.ibm.com a écrit :To guarantee UTF-8 output (assuming the processor is writing directly out to the f

Re: Encoding problem

2009-10-05 Thread keshlam
To guarantee UTF-8 output (assuming the processor is writing directly out to the file rather than producing a SAX or DOM output which other code then writes out), specify the encoding in the stylesheet's directive. Though I'd be sorta surprised if UTF-8 isn't the default... __

Encoding problem

2009-10-05 Thread Yannis Haralambous
Hi, I have the following problem: I wrote a minimal class implementing SAX (I attach it to this message). In this class I do the very simple: public void characters(char[] ch, int start, int length) throws SAXException { String s = new String(ch, start, length); Syste

Re: Identifying a character encoding problem

2006-09-15 Thread Stanimir Stamenkov
/Michael Glavassevich/: It wouldn't hurt to wrap it in the SAXException. Note that current implementations of SAXException don't support [1] the JDK 1.4 exception chaining mechanism so you should be calling getException() to get the cause. Could I file an enhancement request in the Apache J

Re: Identifying a character encoding problem

2006-09-14 Thread Michael Glavassevich
Stanimir Stamenkov <[EMAIL PROTECTED]> wrote on 09/14/2006 04:27:46 AM: > (I've send the previous incomplete message by accident, sorry.) > > /Michael Glavassevich/: > > > SAXException [1] is thrown because character encoding errors are fatal > > errors (as defined by the XML spec) and SAX say

Re: Identifying a character encoding problem

2006-09-14 Thread Stanimir Stamenkov
(I've send the previous incomplete message by accident, sorry.) /Michael Glavassevich/: SAXException [1] is thrown because character encoding errors are fatal errors (as defined by the XML spec) and SAX says fatal errors are reported to the application using that exception. Thanks. I'm now c

Re: Identifying a character encoding problem

2006-09-14 Thread Stanimir Stamenkov
/Michael Glavassevich/: SAXException [1] is thrown because character encoding errors are fatal errors (as defined by the XML spec) and SAX says fatal errors are reported to the application using that exception. Thanks. I'm now clear why encoding errors are reported as SAXExceptions but again

Re: Identifying a character encoding problem

2006-09-13 Thread Michael Glavassevich
t; Even before I've been trying to find a convenient way to identify > whether a parsing has stopped because of a character encoding > problem. I'm attaching a sample (the main application entry is in > "ParsingText.java"): it tries to parse an "UTF-8" encod

Identifying a character encoding problem

2006-09-13 Thread Stanimir Stamenkov
Even before I've been trying to find a convenient way to identify whether a parsing has stopped because of a character encoding problem. I'm attaching a sample (the main application entry is in "ParsingText.java"): it tries to parse an "UTF-8" encoding mislabe