Build: Bugzilla 2.17 at b.m.o Reproducible: Always Steps to reproduce: 1) Load http://bugzilla.mozilla.org/buglist.cgi?bug_id=136650&format=rdf using a tool that allows you to examine byte values eg. using the Web-sniffer http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fbugzilla.mozilla.org%2Fbuglist.cgi%3Fbug_id%3D136650%26format%3Drdf Actual results: The returned XML document contains the byte 0xC4 preceded by an ASCII space. This is not a legal UTF-8 byte sequence. Since neither the HTTP headers nor the XML declaration declare a character encoding and the document doesn't have a BOM, the character encoding of the document is supposed to be UTF-8 as per the XML spec. This is a *fatal error* in the XML sense. From the XML spec: "It is a fatal error when an XML processor encounters an entity with an encoding that it is unable to process. It is a fatal error if an XML entity is determined (via default, encoding declaration, or higher-level protocol) to be in a certain encoding but contains octet sequences that are not legal in that encoding. It is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16." Expected results: Expected the output to be legal UTF-8. Additional information: The basic problem is that Bugzilla is not character encoding aware and takes in any byte sequences and then spits them out as they came in. In the tag soup context ISO-8859-1 or Windows-1252 is usually implied.

This is basically bug 126266. In a patch I have which moves us to CGI.pm output, this is now a one-liner to fix the output side, and mark data as UTF8. the harder bit is converting existing data - see that bug for detals *** This bug has been marked as a duplicate of 126266 ***