Note that if you modify line 8 to
in reply to Re^2: Unicode strings internals
in thread [SOLVED] Unicode strings internals
the output changes to
my $ascii_but_utf = '123';
This is because that UTF is on is just a historical artifact of your initialization.
SV = PV(0x22ae1d0) at 0x2300b20
REFCNT = 1
FLAGS = (PADMY,POK,pPOK)
PV = 0x22d21f0 "123\321\204\321\204\321\204\321\204"\0
CUR = 11
LEN = 16
If we take a look at the two output files generated by these two cases, you'll note that both contain 11 bytes, despite the fact that the byte dump of the UTF-upgraded case should have output 19 bytes. This is because the internal representation of high-bit, 1-byte characters under Perl's implementation of UTF is multi-byte even though they cleanly map to 1-byte characters on output. You wouldn't expect these 1-byte characters to output a wide-character warning any more that you'd expect an ASCII character to.
Second case does look like UTF-8 character string,
You're thinking of that wrong; it could be a UTF character string, or a UTF-8 byte string. When dealing with non-ASCII characters in Perl, rare is the case when you should actually be thinking about Perl's internal representation.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.