Very old fj.kanji discussion  525/622 

No. 525/622 Index Prev Next

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が死にます。
>
> 　少なくとも、こういう状況だけは無くしたい。
１は、既に対応ずみ？
２は、ＰＤＳ使用のところは、対応が早いでしょう。
３は、送信元か、それに近いところでやるのがいいと思います。
４までいけば、万々歳ですが、なかなか大変そうです。
当面は、送信元で対策してもらうのが現実的かもしれません。
（これでは、反対しているのと同じか？）
−　松方　純　（国文学研究資料館）

Next
Continue < 42639@wsserva.ws.sony.co.jp>
< 4385@koudai.cs.titech.ac.jp>
< 4937@tansei.cc.u-tokyo.JUNET>
< 42642@wsserva.ws.sony.co.jp>
< 1757@kyo-sr.ntt.JUNET>