The problem is that the perlmonks website serves the pages as Content-Type: text/plain; charset=ISO-8859-1 (even though, technically, – is at codepoint 0x96 in Windows-1252, but not in ISO-8859-1, where 0x96 is a control character), so any bytes that get saved use that encoding; but saying use utf8 tells perl to interpret bytes in the source code as UTF-8 -- so it tries to interpret the ISO-8850-1 or Windows-1252 bytes as UTF-8, and fails on codepoints above 127.

You have put me on the right track. I have found gvim commands to tell it that input is in CP1252 and output should be in utf-8. This converts the 96 to e28093 (u-2013 EN DASH). The resulting file runs in perl and pastes pack into perlmonks correctly. The character still does not display correctly in gvim or the windows command prompt. The best solution probably it to download notepad++, but it seems like overkill to learn another editor to solve such a rare problem.
Bill

The best solution probably it to download notepad++, but it seems like overkill to learn another editor to solve such a rare problem.

As much as it pains me to say it (given my Notepad++ fandom), it does seem like overkill. But iconv.exe comes with my Strawberry perl... and if it does with yours, then it can handle the translation. (Or gnuwin32's iconv). I believe one of the following two would properly translate the CP1252 encoding of the emdash into UTF-8.

iconv -f ISO-8859-1 -t utf-8 savedfile > outfile.pl
iconv -f CP1252 -t utf-8 savedfile > outfile.pl
[download]

(Of course, the other fix is to not use utf8; after you download the script; perl will default to your native Windows encoding {if I understand things correctly}, so that should work -- at least, it did for me from that same downloaded source code.)

if you use utf8 only for strings and not for variable names, you could convert your special characters to \N{...} notation, such als "\N{EN DASH}"

Of course, it's your decision whether "Bj\N{LATIN SMALL LETTER O WITH DIAERESIS}rk" is more readable than something like "Bj�rk" or not ;-)

N.B.: For the \N escape to work in Perl older than 5.16, you need an explicit use charnames;

At least I'm able to reproduce this error. Never got hit by this problem as I usually select & copy code and paste it into a new file.

That indicates a scalar which become corrupted when Perl or XS code improperly decoded a string.

For example, use utf8; doesn't validate if the source code is actually valid UTF-8, and produces corrupt scalars if it's not.

$ not_utf8="$( printf "\x96" )"

$ perl -e"use utf8; q{$not_utf8}"
Malformed UTF-8 character: \x96 (unexpected continuation byte 0x96, wi
+th no preceding start byte) at -e line 1.
Malformed UTF-8 character (fatal) at -e line 1.
[download]

(Fortunately, use utf8; catches the problem and bails.)

Are you using use utf8; with a source file that isn't encoded using UTF-8?

The likely culprit is a U+2013 EN DASH ("–") encoded using cp1252.

Using the :utf8 encoding layer can also produce corrupt scalars.

$ printf "\x96" | perl -nle'
   use open ":std", ":utf8";
   printf "%vX\n", $_;
'
Malformed UTF-8 character: \x96 (unexpected continuation byte 0x96, wi
+th no preceding start byte) in printf at -e line 1, <> line 1.
0
[download]

That's why :encoding(UTF-8) should be used instead.

I wish that I had recognized that your "likely suspect" was the key to the whole mystery.
Bill

I do understand that some of your suggestions were 'workarounds' to make this particular program work with a different character. This was my first choice until I had a better understanding of the real problem.