in reply to Re^2: Unicode strings internals
in thread [SOLVED] Unicode strings internals
the output changes tomy $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 ALL OK
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: Unicode strings internals
by vsespb (Chaplain) on May 10, 2013 at 18:49 UTC | |
by kennethk (Abbot) on May 10, 2013 at 21:06 UTC | |
by vsespb (Chaplain) on May 10, 2013 at 21:30 UTC | |
by kennethk (Abbot) on May 10, 2013 at 22:13 UTC | |
by vsespb (Chaplain) on May 10, 2013 at 22:32 UTC |