TStcltk 発言

ビットウォークの高橋です。

>>>ChangeLogとencodingパッケージを確認したところ、
>>>iso2022(-jp).encのエスケープシーケンスも修正されていました。
>>>残るは、RFC1468の規約違反の修正、つまり田口さんのパッチを
>>>適用して、encoding.testの結果内容を修正すれば、
>>>現時点で判明しているISO2022-JP関連のバグは全てfixできそうです。
>>>
>
>fixできました。http://www3.ocn.ne.jp/~yamako/tcl/ で公開しています。
>

ご苦労さまです。後程試させて頂きます。


>
>もっとも簡単なのは「abcあいう」をISO-2022-JPに変換してみることです。
>
>Tclの場合: 
>binary scan [encoding convertto iso2022-jp abc\u3042\u3044\u3046] H* ret
>puts $ret
>
>比較検証用に作ったJava(JDK1.3.1 on Mac OS X)の場合:
>public class Enc {
>    public static void main( String[] args ) {
>        String s = new String( "abc\u3042\u3044\u3046" );
>        try {
>        byte[] bs = s.getBytes( "ISO2022JP" );
>        String s2 = new String();
>        for( int i = 0; i < bs.length; i++ ) {
>            s2 += "0123456789abcdef".charAt(bs[i]>>4);
>            s2 += "0123456789abcdef".charAt(bs[i]&15);
>        }
>        System.out.println( s2 );
>        } catch( Exception e ) {e.printStackTrace();}
>    }
>}
>
>この両者を比較してみてください。
>

ありがとうございます。そうか…コードにして見れば良いのですね。
残念ながら今Javaの環境が使えないのでとりあえずTclだけで見てみました。

リリースされたTcl8.3.4ですと「abcあいう」は
6162631b24422422242424261b2842

本日更新したCVSの8.4a4では
1b28426162631b2442242224242426

となります。確かに8.3.4の方は変ですが、8.4a4の方はというと、私の理解では
正しそうなんですが…。

1b2842でアスキーが始まり、
61(a) 62(b) 63(c)

1b2442でJIS208が始まり、
2422(あ) 2424(い) 2426(う)

-- 
Keiichi Takahashi, bitWalk Co.,Ltd.
mailto:bitwalk@...
http://members10.tsukaeru.net/bitwalk/