Thanks, Bjoern. I looked at Cmdline.java and this was the first thing that jumped out at me. I'm sure I'll be able to reproduce it on my machine. If this is a bug, I think it is mostly a bug with the documentation but probably Scott and Joe should comment on this since I haven't really thought it through.
It seems to me when you ask for a Writer output, you're asking for a specific encoding. The one argument constructor for FileWriter assumes an encoding of the java system property file.encoding and that's what you used. This overrides the encoding requested in the XSLT. I do think this merits a FAQ entry but I wouldn't change XalanJ. What do you think? Gary Bjoern Martin wrote: > > I think I got it (at least it works now for me). I used readers and > writers in my project. Now I switched to streams for testing - and it > works ?!? > After this strange experience I wrote a very slim sample program. It > first uses java.io.FileReader and java.io.FileWriter to read/write the > data and then - in a second run - uses java.io.FileInputStream and > java.io.FileOutputStream to do the same job. The input files are > in.xml and style.xsl, the output files are out1.xml (for > reader/writer) and out2.xml (for streams). It's all documented in the > source. > On my computer out1.xml has the error with the '�' char within a UTF-8 > doc (which is not possible for UTF-8), out2.xml works out ok. > > Q: Can you reproduce this problem on your machine? If so, I'll submit > a bug report. > > Regards. > > -- > Bjoern Martin [EMAIL PROTECTED] > > ------------------------------------------------------------------------ > Name: style.xsl > style.xsl Type: BizTalk Schema (text/xml) > Encoding: Base64 > > Name: in.xml > in.xml Type: BizTalk Schema (text/xml) > Encoding: Quoted-Printable > > Name: ReaderVsStream.class > ReaderVsStream.class Type: unspecified type (application/octet-stream) > Encoding: Base64 > > Name: ReaderVsStream.java > ReaderVsStream.java Type: unspecified type (application/octet-stream) > Encoding: Base64
