EDIT: I completely missed the point, and so everything in this post is irrelevant. Ignore me.I assume you're refering to
this post?
So while poking around, I noticed something interesting. The Antiquity theme includes this line in the header:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
This is, according to the
HTML 4 standard, the correct way to indicate character encoding. Meanwhile, the Century and Rift themes include this line instead:
<meta charset="iso-8859-1">
This is a new notation defined in the
HTML 5 standard that was not present in HTML 4, but most browsers should support HTML 5 nowadays. However, the HTML 5 standard also specifies:
The charset attribute specifies the character encoding used by the document. This is a character encoding declaration. If the attribute is present, its value must be an ASCII case-insensitive match for the string "utf-8".
The Encoding standard requires use of the UTF-8 character encoding and requires use of the "utf-8" encoding label to identify it. Those requirements necessitate that the document's character encoding declaration, if it exists, specifies an encoding label using an ASCII case-insensitive match for "utf-8". Regardless of whether a character encoding declaration is present or not, the actual character encoding used to encode the document must be UTF-8.
Which just leaves me wondering what the heck? Why bothering adding a new way of specifying the character encoding that allows only one possible value? Was there some intermediate form of the standard in which other encodings were permitted? Regardless, websites which use non-UTF-8 character encodings remain common on the internet, so practical browsers (including mine - the post displays correctly for me) will make some effort to implement them regardless of what the HTML standard says.
In any case, examination of the page in a hex editor shows that the "æ" is, in fact, encoded in its ISO-8859-1 representation. This makes it even weirder that it displays as "æ" for you, since that is what it would display if a UTF-8-encoded character in the page were misinterpreted by your browser as ISO-8859-1, which clearly cannot be the case (I checked the page, and nowhere in it does the UTF-8 encoding of "æ" appear).
My best guess, in light of this evidence, is that you have some sort of browser script that reads the page, modifies it, and inserts the modified text back into the page, but mangles the character encoding during the "insert the modified text back into the page" stage. Are you using any NationStates browser plugins? If so, try turning them off and seeing which one causes the problem.
Or did I get the wrong link? If so, please link to the actual page that has the problem.