Tadamasa Teranishi
yw3t-****@asahi*****
2006年 5月 2日 (火) 12:41:16 JST
寺西です。 Tomoyuki Asakawa wrote: > > ISO-2022-JPを決めるとき、EUCに変換した時に、困らない様にと > いう、ご都合主義できめられてる事がISO-2022の不幸だとおもて > います。 これが ISO-2022-JP(JUNETコード)の目的のひとつだっただろうと思いますが。 > 7ビットに押さえるという目的なら、GLに、よびだせばよかった > のです。 > 当時の実装としてそういうものもあったのですから。 7bitに抑えるだけでは不十分だったからでしょう。 > 純粋なISO-2022原理主義者だった私から言えば,SJISも > EUCも内部コードです。 > 内部コードで外部コードを規定すべきではない。ISO-2022-JPは > EUCの7ビット版になってしまってる。 JUNETコードは、7bitに抑えて、(すくなくとも当時は主流の)UNIX 間の やり取りに使うためのものだったので、EUC-JP の 7bit版とでもいう ような設計は妥当だったと思います。 # まだ、EUC-JP で半角カナも使えませんでしたし。 既に普及しているJUNETコードをほぼそのまま ISO-2022-JP として RFC化したわけですから。(その当時は EUC-JP でも半角カナが使えなくも なかったわけですが) # RFC化する時にJUNETコードを拡張しておくべきだったという考えも # あるでしょうけど。 > 内部コードで外部コードを規定すべきではない。 のかもしれませんが、そこには外部コードは内部コードの制限を受けない マキシマムなものであるべきだという考えがあるのだろうと思います。 しかし、外部コードをミニマムなものにして様々な環境で使えるように したという考えも間違いではないだろうと思います。 ISO-2022-JP はそういう考えです。 どっちが正しいというものではないと思います。 ISO-2022-JP でまずい点はネーミングであって、あたかも ISO-2022 と 互換性があるかのような誤解を与えることですが、サブセットに過ぎません。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-****@asahi***** http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E