3809 2005-07-02 04:33:37 -0700 Should default to UTF-8 or UTF-16 for application/xml documents with omitted charset and encoding declaration 2019-02-06 09:04:18 -0800 1 1 1 Unclassified WebKit DOM 312.x Mac OS X 10.3 RESOLVED FIXED http://hsivonen.iki.fi/test/mobile/latin.xhtml P2 Major --- 1 hsivonen darin ap cdumez oldest_to_newest 13672 0 hsivonen 2005-07-02 04:33:38 -0700 Steps to reproduce: 1) Make Safari load (either in content area or through XMLHttpRequest) an XML document that does not have an XML declaration that declares the character encoding AND does not have a BOM AND is encoded in UTF-8 AND contains characters from outside the ASCII range AND is served as either application/xml or application/xhtml+xml AND has no charset parameter on the HTTP layer. (Although the above looks very specific, the conditions commonly hold true.) 2) Observe. Actual results: The bytes are decoded as characters according to the Default Encoding in Appearance preferences. Expected results: Expected the bytes to be decoded as characters according to UTF-8 as per section 3.2 of RFC 3023, which defers to XML 1.0 section 4.3.3. Additional information: Besides the obvious implications of this bug, there are two less obvious implications: 1) Safari cannot properly consume Canonical XML. 2) Safari cannot properly consume XML documents it has produced itself via XMLHttpRequest POST! 15041 1 oliver 2005-07-21 16:26:05 -0700 Would you be able to attach a test document, cheers, Oliver 19157 2 hsivonen 2005-09-09 01:14:22 -0700 What reduction is needed beyond the case that has been in the URL field all along? 19158 3 oliver 2005-09-09 01:25:10 -0700 Behaviour is wrong (confirmed against ffx) 19232 4 3827 ap 2005-09-09 12:49:23 -0700 Created attachment 3827 proposed patch Well, the XML spec is pretty explicit about files that do not have an encoding declaration in the text declaration - they should be UTF-8 or UTF-16, unless a higher-level protocol defines a charset (4.3.3). 19233 5 ap 2005-09-09 12:50:57 -0700 The file from bug URL can serve as a test case (without a link to the next test, of course). 19244 6 3827 darin 2005-09-09 15:36:48 -0700 Comment on attachment 3827 proposed patch Is there any other browser that has this behavior? The comments above lead me to believe this is not working this way in Firefox. 19254 7 hsivonen 2005-09-09 23:55:57 -0700 Gecko used to have this same bug (at least in content area--not sure about XMLHttpRequest), but it has been fixed. 19273 8 ap 2005-09-10 03:22:28 -0700 Henri, which Gecko bugfix are you referring to? I see that Firefox 1.0.5 renders the test as expected, but I couldn't find anything in Bugzilla. I found <https://bugzilla.mozilla.org/show_bug.cgi?id=247024>, but it talks about a different issue: documents transferred with MIME type text/xml should default to us-ascii, not utf-8. I'm not sure if WebKit has the same problem, but if it has, that should be in a separate report IMO. 19430 9 3827 darin 2005-09-11 21:57:43 -0700 Comment on attachment 3827 proposed patch I thought about it a lot, and I think it's fine to land the fix just like this. 1503145 10 lforschler 2019-02-06 09:04:18 -0800 Mass moving XML DOM bugs to the "DOM" Component. 3827 2005-09-09 12:49:23 -0700 2005-09-11 21:57:43 -0700 proposed patch xmlnocharset.txt text/plain 741 ap SW5kZXg6IGRlY29kZXIuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvcm9vdC9XZWJDb3Jl L2todG1sL21pc2MvZGVjb2Rlci5jcHAsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDIKZGlmZiAt cCAtdSAtcjEuNDIgZGVjb2Rlci5jcHAKLS0tIGRlY29kZXIuY3BwCTEgU2VwIDIwMDUgMDU6Mzc6 MTcgLTAwMDAJMS40MgorKysgZGVjb2Rlci5jcHAJOSBTZXAgMjAwNSAxOTo0NjoxMSAtMDAwMApA QCAtNTIzLDYgKzUyMyw5IEBAIFFTdHJpbmcgRGVjb2Rlcjo6ZGVjb2RlKGNvbnN0IGNoYXIgKmRh dGEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXRFbmNvZGluZyhzdHIubWlkKHBvcywg bGVuKSwgRW5jb2RpbmdGcm9tWE1MSGVhZGVyKTsKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpZiAobV90eXBlID09IEVuY29kaW5nRnJvbVhNTEhlYWRlcikKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZ290byBmb3VuZDsKKyAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxz ZSB7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2V0RW5jb2RpbmcoIlVURi04IiwgRW5j b2RpbmdGcm9tWE1MSGVhZGVyKTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIGZv dW5kOwogICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICB9CiAK