After some debugging, there are 2 distinct problems:

1. Some comments on PHP pages are badly encoded. They contain invalid characters, which prevent the W3C validator (or iconv) from parsing the page. There such problems among the 420 Kb of "http://php.net/manual/en/function.array-merge.php".

2. The problem with "zero-width spaces" that get printed is probably related to CSS, not to encoding bugs. At least with Opera 15, disabling the following line fixes the display:
body, input, textarea { 
    font-family: "Source Sans Pro", "Helvetica", "Arial", sans-serif;
}

Your second problem sounds like: https://github.com/php/web-php/pull/32

As for the 1st one; I have deleted the note that had the invalid character point.

Can you recheck in like 60minutes and see if it works?

| As for the 1st one; I have deleted the note that had the 
| invalid character point.

Actually, at least the comment by rafmavCHEZlibre_in_france is most
likely encoded as ISO-8859-1.  The offending character is an é, 
which is quite common in several languages.  There might be a lot 
more of these comments. Instead of deleting them, it might be 
worth transcoding them to UTF-8.

Removing one comment did not change the encoding problem. Here is the direct link to the W3C HTML validator on one of the offending pages:
http://validator.w3.org/check?uri=http%3A%2F%2Fphp.net%2Fmanual%2Fen%2Ffunction.array-merge.php&charset=%28detect+automatically%29&doctype=Inline&group=0

I can't imagine that a handful of latin-1 encoded characters in the user submitted data are causing your browser to present you weird data or broken navigation.

If a browser shall display a page in UTF-8 encoding, and there are
unrecognized code points, it will substitute them by the Unicode
replacement character U+FFFD[1].

You can see that yourself if you visit the array_search man page[2],
and search for "greetz Udo". Just below this text is an "ANSI" 
encoded non-breaking space character (0xA0), which is displayed as
<?>.

[1] <http://www.fileformat.info/info/unicode/char/0fffd/index.htm>
[2] <http://php.net/manual/en/function.array-search.php>

thanks for the explaination, but I'm still missing the actual bug here.

Is this ticket for making sure all user contributed notes are utf-8?

I have not opened the ticket, but it seems reasonable to convert
all old user contributed notes to UTF-8; the newer ones seem to be
anyway.

As I wrote in the first note:
| The problem with "zero-width spaces" that get printed is probably related to CSS, not to encoding bugs.

Sorry, my bad, I thought that the encoding bugs that cause the W3C validator to refuse to validate the page also caused the display error. As I wrote, I later discovered that they were separated problem. See bug 66196 for the display error.

I still think that serving well encoded pages would be better, even if it means deleting (or applying iconv) to old comments.

The mentioned user notes have been removed in the meantime; there
might be others with non UTF-8 encoding, but these can be handled
on a case by case basis.