This would be the case perhaps, but for fairly inconsistent and buggy support for UTF8 in Perl; I've found that there are enough problems where things "Just Don't Work" (tm) that one is quickly forced to start debugging at a pretty low level when writing any kind of non-trivial UTF8 code in Perl.
At the moment, I'm trying to figure out why I can't transfer UTF-8 encoded XML across a data path that involves LWP, CGI.pm, and application/x-www-form-urlencoded form data. There's really no way to debug this without digging into the precise data formats that one can grab at various points in the system.
(And apart from that, the Perl docs make it very clear that the internals are UTF8, so it's fairly difficult to ignore it.)
>$str above is a perl string that contains one character,
>and ord(that_character) is 0x39a.
That we agree upon.
>Whether perl happens to remember that fact by storing the
>two bytes 0xCE and 0x9A somewhere in memory shouldn't normally concern you.
It *shouldn't* concern me, but I seem to have to worry this stuff rather more often than I'd like.
>I don't understand what you are trying to say there.
I was pointing out that your claim that the strings in your example code are different doesn't make sense to me; if you use, say, unpack("H*", ..) to dump out the contents of the string both before and after encode_utf8, you find that they are byte-for-byte identical.
You showed some code that merely demonstrated that the length function was interpreting the contents either as characters or bytes (presumably because one has the utf8 flag on and the other doesn't).
In reply to Re^6: What does Encode::encode_utf8 do to UTF-8 data ?
by scollyer
in thread What does Encode::encode_utf8 do to UTF-8 data ?
by scollyer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |