TStcltk 発言

清々しい春の青空の下、暗い部屋でパッチを作っていた山本です。

"Keiichi Takahashi <bitwalk@...>"さんは書きました：
> >...で、tclIO.c(core-8-3-1-branch版)を見てみると、
> >#define ENCODING_LINESIZE   50
> >と、今度は増えていたり(笑)。
> >午前中、誤って8.4版を取ったときは
> >確かに20になっていたんですけど(笑)。
> 
> Tcl/TkのSourceForgeにあるCVSは頻繁に更新されていますが、特に最近は更新頻
> 度が高いですね。

8.4版のソースをもう一度取り出しましたが、こちらは
相変わらず 20 のままです。タイムスタンプを見ると、
core-8-3-1branch版の方が5,6分新しいようですが、
どっちなんでしょうね。

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

fixできました。http://www3.ocn.ne.jp/~yamako/tcl/ で公開しています。

> なにか、目に見えてちゃんと動いていないことが解る手頃なサンプルがないもの
> でしょうか。JeffのいるActiveStateでは、日本語フォントが表示できるOSの動
> くPC（たぶん、日本語版Windows 2000 Pro.とSuSE Linuxだと思います）がある
> ので、「目に見える」不具合があれば、結構迅速に対応してくれそうです。自分
> ではJIS->EUC-JPの変換の実績しかなく、適当なものが作れないのです。

もっとも簡単なのは「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();}
    }
}

この両者を比較してみてください。

--
Koichi Yamamoto, 
http://www3.ocn.ne.jp/~yamako/