Not a bug of your machine or browser; this is a problem of the webserver in its metadata. The transport layer indicates to the client another encoding in HTTP headers, and it prevails to what the document encodes. In this case, the webserver should be able to transform the source document to match what it indicates in HTTP headers, or should better identidy its local file contents to send the correct HTTP header).
Send a bug report to the site admin to fix its web server settings, possibly per directory, or using a naming scheme for webpages that are encoded differently, e.g. "http://www.example.net/path/to/file.UTF-8.html"; will request the content of a file named "file.UTF-8.html" with an explicit extension "*.UTF-8.html" which can be mapped by the server using another HTTP header for the effective UTF-8 encoding (instead of using cp-1252). My opinion however is that new contents should always be encoded in UTF-8, and older contents may be linked to another effective archiving directory where it can be mapped to the older encoding without having to reencode the old content. 2012/11/26 Marc Durdin <[email protected]> > Somewhat ironically, both Firefox and Internet Explorer, on my machine > at least, detect this page is encoded with ISO-8859-1 and cp-1252 > respectively, instead of UTF-8. It seems they both ignore the XML prolog > which is the only place where the encoding is stated.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *John H. Jenkins > *Sent:* Tuesday, 27 November 2012 1:15 AM > *To:* Unicode Mailing List > *Subject:* Re: xkcd: LTR**** > > ** ** > > Or, if one prefers:**** > > ** ** > > http://www.井作恆.net/XKCD/1137.html**** > > ** ** > > On 2012年11月21日, at 上午10:22, Deborah Goldsmith <[email protected]> wrote:* > *** > > > > **** > > > http://xkcd.com/1137/ > > > **** > > Finally, an xkcd for Unicoders. :-)**** > > > > **** > > Debbie**** > > > > **** > > ** ** >
