No, you're not alone. I just have to go back and review the entire thread
before I comment. Sorry, I've had a busy last couple of days.
-scott
Bjoern Martin
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
lsruhe.de> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Re: Reader buggy for
transformation? (Was: Re: Force
07/13/2001 03:10 encoding of result doc)
AM
Please respond
to bjoern.martin
> 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.
Are they reading on this list? Or are we alone here? :)
> 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 just added the line
System.setProperty("file.encoding", "UTF-8");
in the beginning of the sample app, but nothing changed, as the line
System.out.println(out1.getEncoding());
added after the file's written still returns "cp1252" :(
> I do think this merits a FAQ entry but I wouldn't change XalanJ.
> What do you think?
That would be sufficient, as this only occurs if you change the
encoding. Just to check I used an UTF-8 input and UTF-8 style,
creating UTF-8 output - worked fine with the streams and FileWriter,
though I still get encoding "cp1252" for the FileWriter. Now, if I
change the output encoding to "iso-8859-1" in <xsl:output />, the
streams do the job and output the utf-8 'ä' as iso-8859-1 '�', but
the FileWriter doesn't!
So if the FAQ entry would state that changing the encoding is only
safe with streams set for the StreamResult, everything's fine.
Regards.
--
Bjoern Martin [EMAIL PROTECTED]
