Well, I'd love to try an experiment -- disabling the conversion of user-input characters in "Code" blocks on user-submission, into HTML entities. Seems like that shouldn't be "that" hard.

BTW -- when I say website directing conversion -- I mean by claiming it is using a specific encoding. Certainly Win-1251 was never a default standard -- ISO-8859-1, maybe, but not Win-1251 -- so that has to be specified as an encoding by the website on each page. That's what I mean by "directing conversion". The fact that multiple people can read UTF-8 encoded Unicode characters (basically ignoring the website's encoding directive) leads me to believe that most browsers would automatically work -- and it is only the fact that PM, first converts user-input into html-entities that the problem exists -- because it is only in code-blocks that PM won't convert html-entities or inhibits browser conversion back into their character equivalents.

That 2nd conversion makes UTF-8 displayable in normal text or "pre" blocks, but is disabled for "code" blocks. The best solution there would be to not mangle user-input in "code" blocks in the first place into html entities -- because they won't be converted back into displayable characters -- it's a one-way conversion that is causing the display bug -- so since "code" blocks aren't supposed to be formatted anyway -- it seems having the website reformat user input in those blocks is the root of the problem, since any conversion done in that 1st stage will be guaranteed to be one-way in code blocks.