It's possible for UTF8-encoded text to contain code points in the range U+D800 - U+DFFF (Surrogate Pair Area), but this is always a sign that something bad was done to the data when it was converted into UTF8 encoding.
I don't recall offhand what particular mistake(s) in transcoding would cause these code points to show up in UTF8 data, but there's a chance that your data originated in some 16-bit (fixed-width) encoding that was incorrectly converted to UTF8, and there may be better ways of "fixing" the problem than just deleting these odd characters.
Still, if your experience with the data in question indicates that deletion is the "right thing" to do, it's easy to detect and "fix" the problem:
# Assuming $string is utf-8 endcoded:
if ( my @badch = ( $string =~ /[\x{d800}-\x{dfff}]/g )) {
warn sprintf( "%d surrogate code point(s) found\n", scalar @badch
+);
$string =~ tr/\x{d800}-\x{dfff}//d;
}
(Update - forgot to mention: you can read more about surrogate-pair characters in perlunicode. It may be that your UTF8 data started out as UTF16, but was incorrectly treated as if it were UCS2 when it was converted to UTF8. Converting to UTF8 in the correct way would yield different results.) | 