I made a patch for this bug:

http://s3.amazonaws.com/arnaud.lb/php_htmlentities_utf.patch

The internal get_next_char() function returns a status of FAILURE 
when it encounters a invalid or incomplete sequence, which causes 
the htmlspecialchars and htmlentities functions to return an empty 
string.

This patch modify the behavior of these functions to skip invalid 
sequences, without discarding the whole string. This involves a very 
few changes and makes the behavior of theses functions more 
consistent with previous PHP versions.

It also adds a few tests to htmlentities-utf.phpt.

See also bugs 43294 and 43549 which seem to be the same thing.

This is really starting to bite now. Please can this be fixed, or suggest how we can reliably process incoming user data in UTF8 given this behaviour change!

This seems to be breaking PEAR::Text_Wiki completely when using UTF-8: http://pear.php.net/bugs/bug.php?id=13136

Hi,
I've got the same Bug, posted on #43740.
Please fix it.

Thanks!

  is also affected in 5.2, for example:

$str = 'Hello' . chr(160) . 'there';
print(htmlentities($str, ENT_COMPAT, 'UTF-8'));

Instead of printing "Hello there", it prints nothing (empty string). The same for htmlspecialchars().

Both functions work fine in 5.1

I even don't think this is a valid bug in the first place. You passed a 
string that is encoded in ISO-8859-15 to htmlspecialchars() while 
specifying UTF-8 to force the string to be treated as "UTF-8". One 
should never depend on the past wrond behaviour with which invalid byte 
sequences pass through. Besides, you can always work around it by giving 
ISO-8859-15 to the third argument.

Not considering this as a bug (or rather a regression) is a major flaw IMO.
htmlspecialchars() is *THE* tool that developers are encouraged to use when escaping output of data that comes from an unknown source. By nature you can't always rely on this data to be perfectly valid. People copy and paste from Word to HTML forms and do all kind of weird stuff to get data into a website.
Simply discarding the complete data just because it's not a completely valid character stream is going break all kind of websites with user generated content.

Actually "The tool" to use for incoming data is the filter extension..

Arnaud, fix it yourself.

Added ENT_IGNORE as a compatibility flag to skip invalid multibyte sequences instead of returning an empty string (as iconv's //IGNORE). These functions will still never return an invalid or incomplete multibyte sequence.
Example: htmlspecialchars("...", ENT_QUOTES | ENT_COMPAT, "utf-8");

It seems "Fixed in CVS and need to be documented" does not changes the status if it is set to "Assigned" :/

Noted addition of ENT_IGNORE in the manual entries for htmlspecialchars and htmlentities.

I'm still having this problem - running php 5.2.15

Ah... I realized I need 5.3

echo "test = " . htmlentities("some text", ENT_QUOTES | ENT_IGNORE, 'UTF-8', false);
returns: test = 

echo "test = " . htmlentities("some text", ENT_QUOTES | ENT_IGNORE, 'UTF-8');
returns: test = some text

The latter is the expected result, but why does adding the fourth parameter, to prevent double-encoding, cause this function (and also htmlspecialchars) to return the empty string?  How can this be prevented?

I have a form that I want to redisplay to users until all their input has been corrected, preserving their responses in the fields so they can start from what worked.  The users are international, with names containing lots of accent marks and utf-8 characters, and some of the input is mathematical, with Greek characters and such, so I want to assume the input is utf-8 to preserve all of this, without messing it up on multiple passes.  Thanks for your help.

I can't reproduce that:

<?php
echo htmlentities("some\x80 text&gt;", ENT_QUOTES | ENT_IGNORE, 'UTF-8', false), "\n";
echo htmlentities("some\x80 text&lt;", ENT_QUOTES | ENT_IGNORE, 'UTF-8');

gives the expected

some text&gt;
some text&amp;lt;

cataphract, thanks for looking at this.
When I try your tests, neither line generates any output.  I am using PHP Version 5.3.5-1ubuntu7.2.  Any ideas where I should look for a problem?  Could this be a server configuration issue?  Thanks.

My humble apologies...
I am working on two servers and I got confused as to which was which.  The problem you could not reproduce was because I was actually running PHP Version 4.3.9.  On PHP Version 5.3.5 it works as expected.  I regret wasting your time with my error.