TStcltk 発言

山本です。
今、sourceforgeの方にpostしようとしているところです。

Keiichi Takahashi <bitwalk@...>"さんは書きました：
> >もっとも簡単なのは「abcあいう」をISO-2022-JPに変換してみることです。
> >
> >Tclの場合: 
> >binary scan [encoding convertto iso2022-jp abc\u3042\u3044\u3046] H* ret
> >puts $ret

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

perlとJcode.pmは使えますか?
使えるようでしたら次のスクリプトを試してみてください。

use Jcode;
print unpack( 'H*', Jcode->new( 'abcあいう' )->jis ), "\n";

これの出力結果は「6162631b24422422242424261b2842」となります。
これが正解です。

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

それはおかしいです。
いえ、出力内容は妥当なのですが、Tcl8.3.4の出力ではありません。
そのbinaryには田口さんのパッチが当たっていると思われます。

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

ActiveTcl8.3.4.2でもこの「1b2842...」の結果になります。

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

なぜ、「1b2442...」の方が悪いのかといいますと、
RFC1468のDescriptionに書かれている次の次項に違反するからです。
1. The text starts in ASCII [ASCII], and switches to Japanese characters
   through an escape sequence.
2. Also, the text must end in ASCII.

前述にあるperlの出力結果は、これを明示しています。
・ASCIIで始まるため、escape sequenceは付かない
・ASCIIで終わるため、ESC)Bが末尾に付く


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