Re: iso-2022-jp snags.

2002-04-12 00:58:56
Dan Kogai <dankogai(_at_)dan(_dot_)co(_dot_)jp> 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.


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 
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;

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.

Nick Ing-Simmons

<Prev in Thread] Current Thread [Next in Thread>