It's the UTF-8 encoding (0xC2 0xA0) of the non-breaking space (which is not included in the "whitespace" set of chars¹ — thus your regex didn't match).

___

¹ update: at least not the iso-latin-1 encoding of the character, i.e. 0xA0  (for backwards compatibility, Perl assumes iso-latin-1 by default):

print "\xa0" =~ /\s/ ? "space" : "no space";   # no space
[download]

But see below.  Apparently, the 0xc2 part ("Â") somehow got lost in your case... — simply (incorrectly) treating the UTF-8 sequence as iso-latin-1 should have left you with two characters.

If one has 5.10 or later, one can use /\h/ which will match a non-breaking space, regardless whether the string is encoded in UTF8 or not.

What you said is very misleading.

$ perl -le'
    $_ = "\xc2\xa0";
    print /^\h$/ ? "h" : "not h";
'
not h
[download]

Of course, you are referring to the internal encoding.

$ perl -le'
    $_ = "\xA0";

    utf8::downgrade $_;
    print /^\s$/ ? "s" : "not s";
    print /^\h$/ ? "h" : "not h";

    utf8::upgrade  $_;
    print /^\s$/ ? "s" : "not s";
    print /^\h$/ ? "h" : "not h";
'
not s
h
s
h
[download]

Unfortunately, that's irrelevant in the OP's case since he needs to decode his UTF-8 first, and will make the internal encoding UTF-8.

Thanx for this nugget.

Leading to the confusing situation that \s (all whitespace) matches less than [\h\v] (both horizontal and vertical WS) :).

0xa0 is an unbreakable space in e.g. latin1. c2 would be LATIN CAPITAL LETTER A WITH CIRCUMFLEX assuming latin1. Some pc charsets use chars in that region for e.g. dos-style line-drawing. Badly done pasting might have added these chars?

Update: just checked UTF-8: Almut's correct: looks like you've submissions in UTF8 which accidentally use the wrong space char. Probably the submitter is preparing his file in word or something similar unsuitable.

One sane approach is whitelisting as already suggested by Silas, e.g. just stripping non-alphanumerics-non-minus with e.g. s![^a-z0-9\-]!!gio. Note that this will also eat up space and line ends in $_. Which works, as we stick to the common subset of ASCII, which is also valid for submissions in UTF-8 and latin1. If you also see other charsets, things like GNU recode might help if enlightening submitters fails.