in reply to Re^2: What does Encode::encode_utf8 do to UTF-8 data ?
in thread What does Encode::encode_utf8 do to UTF-8 data ?

However, in my example, the contents of the string passed to encode_utf8 were not code points - there were already in UTF8, and were therefore left unaltered by encode_utf8.
No. The string passed to encode_utf8 did contain codepoints; that's what Perl strings are. And the function returned something that was different from the original string, as can be seem below: 
use strict;
use warnings;

use Encode;
use charnames qw(greek);

for ("ABCD", "ABC\N{delta}", "\N{alpha}\N{beta}\N{gamma}\N{delta}") {
    printf "orig len=%d, enc len=%d\n",
    length($_),
    length(Encode::encode_utf8($_));
}
__END__
$ perl /tmp/p
orig len=4, enc len=4
orig len=4, enc len=5
orig len=4, enc len=8

[download]
How the string is internally represented in Perl is (almost always) completely irrelevant. Perl sees strings as a list of codepoints; typically if all the codepoints are < 256, perl stores them using one byte per codepoint; if any are >= 256, it stores them all as a variable number of bytes using (as it happens) utf8 encoding internally.

Regardless of a string's internal coding, Encode::encode_utf8() returns a string consisting of a codepoint for each the octets of what would be the utf8 representation of the original string, ragardless of how that original string was actually stored internally.

Dave.

Replies are listed 'Best First'.
Re^4: What does Encode::encode_utf8 do to UTF-8 data ?
by scollyer (Sexton) on Oct 03, 2005 at 13:59 UTC
    >No. The string passed to encode_utf8 did contain codepoints; that's what Perl strings are.

    Hmm, this doesn't make sense to me: AFAIK Perl strings never store code points, but rather store the UTF-8 encoding of the code points e.g. the string with a Greek uppercase Kappa, whose code point is 039A: 

    $str = "\x{039A}";

    [download]
    does not contain, in hex, 039A, but rather in hex, CE9A, the UTF8 encoding of that code point.

    >And the function returned something that was different from the original string, as can be seem below:

    What your example seems to demonstrate, AFAICS, is the character v. byte o/p of length, when presented with strings where the UTF-8 flag is switched on/off.

    So for the final string, containing alpha, beta, gamma, and delta, it has a length of 4 characters, when Perl knows that it contains valid UTF-8, but a length of 8 when Perl is assuming the old byte=character semantics. However, both the strings are byte-for-byte identical.

    Or, if I'm wrong here, I'm very confused.

    Steve Collyer

[reply]
[d/l]
      Hmm, this doesn't make sense to me: AFAIK Perl strings never store code points, but rather store the UTF-8 encoding of the code points e.g. the string with a Greek uppercase Kappa, whose code point is 039A: $str = "\x{039A}"; does not contain, in hex, 039A, but rather in hex, CE9A, the UTF8 encoding of that code point. /
      You are getting diverted by how perl happens internally to store a string. This is almost always completely irrelevant, may change between perl versions, and is just confusing you. $str above is a perl string that contains one character, and ord(that_character) is 0x39a. Whether perl happens to remember that fact by storing the two bytes 0xCE and 0x9A somewhere in memory shouldn't normally concern you.
      What your example seems to demonstrate, AFAICS, is the character v. byte o/p of length, when presented with strings where the UTF-8 flag is switched on/off. /
      Again, forget the internals, don't worry about the internal UTF8 flag. The length function always returns the number of characters in a string, not the number of bytes.
      So for the final string, containing alpha, beta, gamma, and delta, it has a length of 4 characters, when Perl knows that it contains valid UTF-8, but a length of 8 when Perl is assuming the old byte=character semantics. However, both the strings are byte-for-byte identical. /
      I don't understand what you are trying to say there.

      Perhaps it would help if you viewed the encode_utf8() function as being equivalent the one I include below. Does that make things any clearer? Note that my perl version of this function knows nothing about the internal representation of its arg, or whether it has its UTF8 flag set etc. 

      sub encode_utf8 {
    my $e;
    for (map ord, split //, $_[0]) {
        if ($_ < 128) {
            $e .= chr($_);
        }
        elsif ($_ < 1024) {
            $e .= chr(0xC0 + ($_ >> 6)); 
            $e .= chr(0x80 + ($_ & 63)); 
        }
        elsif (...)
            ...
        }
    }
    return $e;
}

      [download]

      Dave.

[reply]
[d/l]
        >You are getting diverted by how perl happens internally to store a string.
        >This is almost always completely irrelevant

        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).

[reply]

In Section Seekers of Perl Wisdom