Re^6: What does Encode::encode_utf8 do to UTF-8 data ?

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

Comment on Re^6: What does Encode::encode_utf8 do to UTF-8 data ?

Replies are listed 'Best First'.
Re^7: What does Encode::encode_utf8 do to UTF-8 data ? by dave_the_m (Monsignor) on Oct 03, 2005 at 18:54 UTC
>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; In 5.6 perhaps; 5.8.x is relatively bugless. (And apart from that, the Perl docs make it very clear that the internals are UTF8, so it's fairly difficult to ignore it.) I cannot stress this enough: if you are concerning yourself with perl's internal representation of a string, you are almost certianly looking in the wrong place for your problem. 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. Forget H. That is just misleading you. That is peeking into the internal details of how a string happens to be stored at moment in time. Almost all Perl-level string handling functions work on characters not bytes: length(), regular expressions etc. Think at all times in terms of characters, not bytes. Perl regards those two strings as completely different. For example: `use Encode; # create a string with one character my $a = "\x{100}"; # create a string with two characters my $b = Encode::encode_utf8($a); # Equivalent to $b = "\x80\xc4"; print $b; # outputs the two bytes C4 80 binmode(STDOUT, ":utf8"); print $a; # outputs the two bytes C4 80 print $b; # outputs the four bytes C3 84 C2 80` [download] The only issue is in terms of the initial input and final out to/from external sources (eg sockets). At these interfaces there has to be a convertion to/from chararacters aka codepoints, into whatever encoding is expected at the other end. This is done either by setting the encoding on the socket, by the module doing the reading/writing, or explicitly by an Encode function. 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). This is crucial. Until you understand why that sentence is wrong, you will continue living in a world of pain. The encode_utf8() function is not diddling with the internal format of a string, it is creating a completly new string that has a different number of characters in it, and that will behave differently with respect to all Perl string handling functions such as m// index(), chop(), lc() etc. Dave.	[reply] [d/l]
Re^8: What does Encode::encode_utf8 do to UTF-8 data ? by scollyer (Sexton) on Oct 03, 2005 at 20:04 UTC
I wrote a lengthy reply to this but it got lost somewhere; in summary: 1) Although it may not appear so, I do indeed understand how Perl functions handle strings of chars; we seem to disagree about the importance of understanding internals, however. 2) My problem arises when getting data to/from a script, via various CPAN modules and data transformations. And here, there is really no getting away from the need to understand precisely what data transformations are taking place, and where. Steve Collyer	[reply]