Path: titcca!ccut!jm
From: jm@ccut.cc.u-tokyo.ac.jp (Jun Matsukata)
Newsgroups: fj.kanji
Subject: Re: ISO 646 IRV is illegal in junet?
Message-ID: < 14562@ccut.cc.u-tokyo.ac.jp> 
Date: 27 Feb 90 23:22:26 GMT
References: < 1002@tujoho.ecei.tohoku.ac.jp>  < 13890@ccut.cc.u-tokyo.ac.jp>  < 1098@tujoho.ecei.tohoku.ac.jp> 
Sender: news@ccut.cc.u-tokyo.ac.jp
Distribution: fj
Organization: Computer Center, University of Tokyo, Japan.
Lines: 98

松方＠国文研です。

In article < 1098@tujoho.ecei.tohoku.ac.jp>  sone@ecei.tohoku.ac.jp
 (Hideaki SONE 曽根＠東北大さん) writes：
> 　まったく盛り上がらないのは、不必要なのやら、賛成なのやら。
　特殊な文字の取扱いに関して盛り上がってきたようですが、本題の方は、
反応があまりないようですね。
　ここでは、本題について述べ、特殊な文字の取扱いetc.は、別途
ポストします。

>>In article < 1002@tujoho.ecei.tohoku.ac.jp> 
> >   sone@ecei.tohoku.ac.jp (Hideaki SONE) writes:
> > > まとめ：　ＩＡ　Ｎｏ５(ISO 646 IRV) を呼び出す ESC ( @ なども英字
> > > 移行（漢字終了）コードとして認めるべきと思う。
> 　他にも、１バイトコード呼出のうち、モザイク文字や特殊な文字セットは
> 別としても、４列目に“ＡＢＣ”が並ぶものはみんな許しましょう。

　１バイトコード呼び出しの機能を、次の２つ分けて考えるとわかりやすい
と思います。
　（１）それより先のコードが１バイトコードであることを示す。
　　　　漢字コードを使用する場合、２バイトコードの終了を示すという
　　　　役割を担います。
　（２）特定の１バイトコード系を選択する。

　受信した時の混乱をきたすのは、（１）に関係していることが多いと思い
ます。特に、２バイトコードの終了が認識できない場合がやっかいです。

　（２）に関しては、端末でサポートしていないものを選択した場合は、
他のもので代用するしかありません。

> ＪＩＳとＡＳＣＩＩの場合の“¥”と“＼”、あるいは２バイトの２種類の
> 漢字コード表に対する現実と同じく、無視してもほとんど許されると思います。
> モザイク系が来ても、どうせ正しく表示できないのならＪＩＳやＡＳＣＩＩで
> 表示するしかないでしょう。

のとおりだと思います。


　このことを踏まえて考えてみると．．．

（案１）
　受信側は、さしあたって使いそうな１バイトコード呼び出しに対応する。
　１バイトコード中に、未知のコード呼び出しが出現しても比較的、害が
すくないと思います。
　送信側は、２バイトコードの終了は、限られたものを使用する。

　すなわち、
　　　　ESC ( B, ESC ( J
        （ただし、受信側では、ESC ( Hにも対応する）
　　　　必要なら、ESC ( @
に限定するのです。
  ESC ( @ は、IA No.5 の無国籍な性格上、新たに追加したいところ
ですが、実際の（情報処理用の）端末で、サポートしているものが少ない
ことがやっかいです。

（案２）
　漢字の呼び出し以外のあらゆるコード呼び出しが出現したら、漢字の
２バイトコードの状態を終了する。

（案３）
　ESC ( ? 型の１バイトコード呼び出しが出現したら、漢字の２バイト
コードの状態を終了する。


　さて、この問題に関していくつかわからない点があります。

　１）１バイトコード呼び出し文字列には、具体的にどのようなものがある
　　　のか？ESC(?（?=@ABC...）の形のものだけなのか。将来増えることが
　　　ないのか。
　２）１バイトコードにはどんなものがあるのか？
　　　ASCII、JIS、IA No.5 のようなもの以外にどんなものがあるのでしょ
　　　うか。−−−これは、各自で資料をあたるべきかもしれませんね。
  ３）半角のカタカナのような問題を生じることはないか。


> 　ひとまず、次のように対応してはいかがでしょうか。
１．> ☆ネットワークの中継関係で、どれが来ても保存して通過させる
２．> ☆メール・ニュースのリーダ関係で、どれが来ても可能な限り表示する
３．> ☆リーダ関係の表示が対応できない場合、当分は配達経路で変換してしまう
４．> ★これらをＸ月１日を目標にして、リーダやフィルタのパッチをお願いする
> 
> > >   ESC ( @ で来ると、実害があります。メーリングリストとニュースの
> > > 接続実験をしていましたが、これで投稿した記事を読むとGNUSが死にます。
> 
> 　少なくとも、こういう状況だけは無くしたい。

　１は、既に対応ずみ？
　２は、ＰＤＳ使用のところは、対応が早いでしょう。
　３は、送信元か、それに近いところでやるのがいいと思います。
　４までいけば、万々歳ですが、なかなか大変そうです。

　当面は、送信元で対策してもらうのが現実的かもしれません。
　（これでは、反対しているのと同じか？）

−　松方　純　（国文学研究資料館）