Path: titcca!icot!nttlab!kyu-cs!hi
From: hi@kyushu-u.junet (Masaki HIRABARU)
Newsgroups: fj.junet,fj.kanji
Subject: Re: Kanji ESCAPE used in JUNET
Message-ID: < 321@kyu-cs.csce.kyushu-u.junet> 
Date: 25 May 87 04:09:30 GMT
References:   
Followup-To: fj.kanji
Distribution: fj
Organization: Dept. of Comp. Sci. and Comm. Eng., Kyushu Univ., Fukuoka, Japan
Lines: 123

まず、私の前提を申しておきましょう。

前提１．将来においても、２種類の JIS 端末は生き続けるだろう
　　　　か？
前提２．利用者にはネットワーク上とローカルの漢字コードが異
　　　　なるということを意識させたくない。

齊藤さんに答えます。

>  まず，言いたいのは，ESC$BとESC$@は僕は，区別したいという
>  ことです．もちろん，区別して表示できるディスプレイは全く
>  持ってはいませんが．．．現状がそうだからといって，それに
>  合わせてしまうのは，悲しいとは思いませんか？

状況１．区別して投稿する人は少ない。
状況２．区別して投稿したくても、ソフトにその機能がない。
つまり、区別されることを保証するような合意は、現状では、逆
に危険であると思うのです。もちろん、この合意は意図どうりに
表示されるかどうかを保証したものではありません。将来、その
様になった場合のことを想定してしての事だと思います。しかし、
将来のことを思うのなら、将来はどちらか一つに統一する方が好
ましいのではないでしょうか？

>    メイルとニュースでは状況が違うので，まずメイルから．
>  メイルではこの制限は絶対に守るべきだと考えます．

上に書いた様な理由で、将来日の目を見ますでしょうか？将来にお
いても、区別するのが特殊なケースとなるようでしたら、やっぱり
統一するか、保証しない方が良いと思うのです。

>    ニュースに関してはローカルに格納する場所と，中継のた
>  めに格納する場所が共用なので，難しくなります．

まあ、バッチ式に中継にしなければなんとかならないこともあり
ませんが。

>    それから，ＪＩＳ漢字のｓｈａｒファイルは，８ビット
>  漢字コードに変換してしまうと，展開するときに，エラー
>  になってしまいます．いまの所，バイトカウントをチェック
>  するｓｈａｒしか見たことがないのですが，チェックサム付き
>  のｓｈａｒが出現したら，それは漢字のテキストには使えな
>  いことになってしまいます．

漢字対応 shar が必要な訳ですね。

>    そんなに厳しい制約でしょうか？僕はそうだとは思わない
>  のですけども．

JUNET の上で配布されている Bnews のコード変換は最低限の部
分しかしていないことも不満の一つです。例えば spool の下は
普通の利用者は見ないので JIS のままで良いのですが、save
した記事が JIS のままなのはいやなのです。つまり、利用者は
明示的にコード変換を施さない限り、ローカルコードと JIS コ
ードの２種類のファイルを持つことになります。これはメイル
についても同様です。

この様に、利用者インタフェースの部分を探しだして、コード
変換ルーチンを埋め込むよりは、外界とのインターフェース部
分（通常こちらの方が狭い）で、コード変換したほうが簡単で
しょう。特にメイルに関しては、ソースが無いと結構大変だと
思うのです。私の見解としては、エスケープの情報を保存する
ために現在の方法は採用されたのであって、この合意がなけれ
ばローカルコードに変換してしまう方が楽である。

>  ・メイルに関しては守ってほしい．

ニュースと同様に扱いたい。でも、譲歩可。

>  ・末端サイト／ドメインでは，他に影響は及ばないことだし，自
>    由にしてもらって結構．

文句なし。

>  ・ＪＵＮＥＴで配布しているＢｎｅｗｓは，変換せずに格納する
>    ようになっている．

了解。

>  ・ローカルコードに変換してから格納する場合，ニュースシステ
>    ムの改造が必要である．改造してしまうと，news.software.b等
>    で配布されるニュースシステムへのパッチがreject される可能
>    性が増す．

現在の JUNET 用のものより reject の可能性は減るはず。

>  ・ローカル漢字コードに変換してから格納したいのなら，まず，
>    ニュースシステムの改造という初期投資を覚悟せねばならないし，
>    以後，ずっと，他のサイトよりは維持管理に手間がかかる．それ
>    相応の覚悟とうでに自信のある人にしか”どうぞおやりなさい”
>    とは言えない．

私のやった経験では、こちらの方が楽。（以前にもそういう投稿があ
ったと思う。）利用者にまったく明示的なコード変換を要求しないと
いう前提を容易に達成できる。もちろん、齊藤さんの主張する方法と
共存できるわけですから、単に合意を廃止するだけで良い。

>      念のため，僕がこのような主張をする背景を説明しておきますと，
>    阪大内のニュース受信サイトはＯＡ９０，Ｓｕｐｅｒｍａｔｅ，
>    Ｖａｘ−７５０，ＲＴ／ＰＣと，漢字ＵＮＩＸ／非漢字ＵＮＩＸ，
>    ＢＳＤ／ＳｙｓｔｅｍＶ，アスキー端末／新ＪＩＳ端末／旧ＪＩＳ
>    端末／シフトＪＩＳ端末が入り乱れた状況で，僕はどこへ持って行っ
>    ても動くようにプログラムを書いたり，改造したりせねばならない
>    わけです．この様な状況で，/usr/spool/news の下は，どの機械で
>    も，７ビットＪＩＳというのは，非常に都合が良いのです．

どのマシンもローカルコードを無視して JIS コードのみを使用している
場合を除いて、移植性に関しては齊藤さんの主張する方法と私の主張す
る方法は同等だと思います。

結論です。
前提２は手間をかければなんとかなりますし、長々と書いた技術的な問題
も十分譲歩できる範囲のものです。要は、前提１の疑問にあります。将来
において区別する必要があるだろうか、統一したほうがいいのじゃないだ
ろうか？あるいは、保証しないようにしたほうがいいのじゃないだろうか。

平原＠九大
−−

フォロウは fj.kanji へ移行することを希望いたします。
一応議論の対象は、二つの漢字コードと二つのローマ文字コードというこ
とでいいですよね。まさか将来、アラビア文字やハングル文字まで扱おう
なんて考えている人もいるのだろうか。
−−