In theory, it's a better (= fewer possible nasty surprises) solution.

I see more possible nasty surprises. Can you elaborate?

Huh? Can you elaborate?

The theoretical danger is that by matching individual bytes instead of characters, you might inadvertently match bytes that actually belong to other characters. And by changing just a few bytes instead of the whole sequence making up a character, you might even be creating invalid UTF8.

Of course, one of the reasons for the popularity of UTF8 (as opposed to Windows native "2 bytes for each character") is that it's resyncing, it's always possible to recognize start and continuation bytes for multibyte characters, so this problem isn't as stringent as it could have been using other multibyte character representations.

There are no whitespace characters with a character code of 128 or above, nbsp (160) is the only almost-whitespace character I know of in that situation. So for this particular application, you're probably in the clear.

Still, there's danger lurking in treating byte sequences in a different manner than intended — thus, treating UTF8 as a byte sequence.

utf8 sequences are completely distinguishable; the bytes \302\240 are not a subset of any other utf8 character. This is true for any utf8 sequence.

The possibilities for surprise I saw were perl ending up making other changes if the file contained invalid utf8 or characters not represented in the shortest possible sequence of bytes, or perl giving warnings.