PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3047
*** shadow/3047 Wed Aug 8 12:01:07 2001
--- shadow/3047.tmp.9627 Wed Aug 8 16:03:19 2001
***************
*** 2,9 ****
| Xalan failing to escape non UTF-8 characters |
+----------------------------------------------------------------------------+
| Bug #: 3047 Product: XalanJ2 |
! | Status: NEW Version: 2.1.0 |
! | Resolution: Platform: Sun |
| Severity: Major OS/Version: Solaris |
| Priority: Other Component: Xalan |
+----------------------------------------------------------------------------+
--- 2,9 ----
| Xalan failing to escape non UTF-8 characters |
+----------------------------------------------------------------------------+
| Bug #: 3047 Product: XalanJ2 |
! | Status: RESOLVED Version: 2.1.0 |
! | Resolution: INVALID Platform: Sun |
| Severity: Major OS/Version: Solaris |
| Priority: Other Component: Xalan |
+----------------------------------------------------------------------------+
***************
*** 54,56 ****
--- 54,69 ----
So I would expect to see the two bytes 195 and 188, in order, written to your
UTF-8 output. If that isn't what we're doing, that would indeed be a bug.
+
+
+ ------- Additional Comments From [EMAIL PROTECTED] 2001-08-08 16:03 -------
+ What Joe said is correct. There is no need or requirement to escape the
+ character 252. We used to do this way back when, but had lots of complaints,
+ mainly because it is the wrong thing to do.
+
+ A test with the latest CVS code outputs 0xC3 0xBC, exactly as Joe specified.
+
+ We should only escape characters if they can't be represented in the given
+ encoding or they somehow get in the way of the markup. Note that via the
+ XMLEntities.res file you should be able to control escaping for specific
+ characters.
\ No newline at end of file
