Am 04.05.2010 um 11:09 schrieb Gisle Aas:
> I regret that I let \C sneak into the URI module. Now we have an interface
> that depends on the internal UTF-8 flag of the stings passed in.
Does it? How so? If it's a byte string, well, it's a byte string, and \C
doesn't change that. If, on the other hand, it's a text string, \C forces byte
semantics upon it. Isn't that what you want to do in that function? (Okay,
there's no spec for that function, so I don't really know what you want to do.)
But doesn't the function return the same result regardless of the UTF-8 flag
being set or not? As demonstrated by this test script:
use strict;
use warnings;
use utf8; # source in UTF-8
use Encode;
binmode STDOUT, ':utf8'; # terminal UTF-8
my $text = 'Käse'; # all characters below 256
my $bytes = encode_utf8 $text;
my $text2 = 'Jiří'; # some characters above 255
my $bytes2 = encode_utf8 $text2;
printf "%x %s\n", ord $_, $_ for
$text,
$text =~ m/(\C)/g,
$bytes,
$bytes =~ m/(\C)/g,
$text2,
$text2 =~ m/(\C)/g,
$bytes2,
$bytes2 =~ m/(\C)/g;
> This makes it very hard to explain, makes it not do what you want when
> different type of strings are combined and makes it hard to fix in ways that
> don't break some code.
Could you provide an example of how this might not do what you want when
different types of strings are combined?
> My plan for fixing this is to introduce URI::IRI with an interface that
> encode all non-URI characters as percent-encoded UTF-8 and live with the
> inconsistency for URI (until Perl redefine what \C means).
--
Michael.Ludwig (#) XING.com
