Dan Kogai <[EMAIL PROTECTED]> writes:
>On Friday, April 12, 2002, at 02:30 , Nick Ing-Simmons wrote:
>> Having hacked RFC2047 support into tkmail I have now seen some
>> non-latin1 characters in a "real" perl/Tk app.
>>
>> There seem to be a few snags with mime's iso-2022-jp:
>>
>> - It failed to demand load given upper-case form ISO-2022-JP
>
>What's Encode->VERSION say? Here is the current status on this one.
1.33
>
>I wrote a ad hoc script as follows,
>
>use Encode;
>my $jp = "ISO-2022-JP";
>Encode::encode($jp, "foo"); # should croak if you are right, NI-S
>print join("\n", map{"\$INC{$_} == $INC{$_}"} grep m,^Encode/,o, keys
>%INC);
>printf "$jp => %s\n", find_encoding($jp)->name;
>for (my $i = 0; $i < length($jp); $i++){
> my $alias = $jp;
> my $char = substr($alias,$i,1);
> substr($alias, $i, 1) = lc($char);
> printf "$alias => %s\n", find_encoding($alias)->name;
>}
>__END__
Hmm, that works for me as well, but Tk is still complaining.
Will investigate.
>
>Well now that we have raw encodings we don't have to trepass EUC to
>decode iso-2022-jp (saves tr//) but there must be a way to tell which
>character set a given character belongs when you encode to iso-2022-jp.
>EUC still comes in handy there.
>
>At any rate, I wanted to clean up 7bit-jis, ISO-2022-JP and
>ISO-2022-JP1 anyway. I'll make this the assignment of today.
Thanks - will try and see if I can get test data.
>
>Dan
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
