Is the string that is passed to "_checkit" supposed to be a (perl-internal) UTF8 string? Has STDOUT been set to use UTF8 encoding before "_checkit" is called?

When the error message from a failed eval matches /U\+(\S+)/, what is the full text of the error message? (Do you get error messages that don't match that regex, and if so, what are they?) Please be explicit.

The point is that I don't understand what sort of error you're "catching". There probably is a better way to catch it, but since I don't know what you're dealing with, I don't know what to suggest.

A few lines of code that reads a few lines of relevant __DATA__ and calls "_checkit" would answer most or all of my questions.

Here is an example:

print Dumper $text;
$VAR1 = {
          'string' => "Text\x{daed}",
};
print $text->{'string'};
'Unicode surrogate U+DAED is illegal in UTF-8 at line 5.
[download]

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;
}
[download]

(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.)

It's because printing wide characters causes Perl to try to encode them into bytes (maybe through an :encoding(...) IOLayer). When you pass a character which cannot be represented in target encoding, an exception is raised. You can also try encode with different error handling modes (your current one is similar to FB_CROAK).

Did I guess the error message ($@) you receive correctly? If not, please provide an example.