Path: titcca!nttlab!ouicsu!icssm!icsts1!saitoh
From: saitoh@icsts1.osaka-u.junet (SAITOH Akinori)
Newsgroups: fj.kanji
Subject: Re: Hankaku kana
Message-ID: < 1741@icsts1.osaka-u.junet> 
Date: 8 Apr 88 11:12:22 GMT
References: < 882@kaba.JUNET>  < 1532@srava.sra.JUNET> 
Distribution: fj
Organization: tokura-lab., Osaka Univ., Japan
Lines: 137

In article < 1532@srava.sra.JUNET> , kameyama@srava.sra.JUNET (Toyohisa Kameyama) writes:
>  亀山です.
> In article < 3223@flab.flab.fujitsu.JUNET>  ichikawa@flab.flab.fujitsu.JUNET (I.Ichikawa) writes:
>  >    ２）ただしこの協約は、特定個人間で使用するコードを制限するものではない
>  これって本当に保証できるのでしょうか?
保証は一切ありません。保証っていったいだれがするのですか？
全国の全ノードのポストマスターに念書を書けとでもおっしゃる
のですか！！？？
と、いうふうにかくと喧嘩を売ってしまうので、冷静に書いていきますね。
つい熱くなってしまった。反省、反省。

--------------------------------------------
これはあくまでも僕の理解です。
その範囲で、ＪＵＮＥＴ漢字コードの約束の意図と意義、それから
現状を書いてみます。

こういう誤解やトラブルが多発するようなら、手引きにはもっと明
確に書いておくべきであったかもしれません。
大体”制限しない”とは書いてありますが、だれもどこでも
”伝達を保証する”とは言ってないし、書いていませんよ。
今、手もとで手引きを参照していますから、手引きに関しては間違
いありません。

西村さんも書いておられましたが、ＪＵＮＥＴの漢字コード規約は、
努力目標に近いものです。

まず、各ホストでの努力目標：メールの場合
1. コントロールコード以外のＡＳＣＩＩコードと、ＪＵＮＥＴ漢字
   コード規約にある漢字コードはは伝達を保証する。

これは、”メールアドレスに＠を使えるようにする”のと
同じくらい強い拘束力を持つ努力目標です。
普通にしていればこれは保証できます。

2. ＪＵＮＥＴ漢字コード規約を満たした漢字テキストならば、
   読めるように、フィルタ、ページャを整備する。

この結果、
    ＪＵＮＥＴ漢字コードを守っている限り、見ず知らずの人でも、
			  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    （漢字ターミナルetc さえ持っていれば）メールを正しく読んで
						  ^^^^^^^^^^^^
    もらえる。
    ^^^^^^^^
ということが実現できるわけです。

逆にいうと、
    勝手なコードを使いたければ自由に使ってかまわない。
    でも、正しく届くかもしれないし、とどかないかもしれない。
    届いても読んでもらえないかもしれない。
    それを覚悟の上、使うこと。
ということになります。
>  ESC (I を使用する以外の方法では, 中継サイトで変換しないという保証は
>  あるのでしょうか?

a) ナマの８ビット。
  4.3のＳＭＴＰを通過した時点で、0x7Fでマスクがかけられます。

b) ^N/^O, ESC-(-I
  普通は通ります。256バイトごとに改行があれば、あとは 7bit
  スルーのはずですから。
  ただし、ローカル漢字コードと、ＪＵＮＥＴ漢字コードの
  相互変換を、/bin/rmail, /usr/bin/uux を改造して行なっている
  ホストを通過したときにはどうなるかわかりません。
  （だからこういうことはして欲しくないのだけれど、よそのサイ
  トの運営に口出しはできないし、だいたいどこがやっているかも
  わからないのでどうしようもない）

次にニュースの場合。
これは”見ず知らずの人へのメール”と同等だと思います。
ローカルなニュースグループ以外で、勝手なコードを使うと、
ひんしゅくを買うことになるでしょう。

普通にインストールすると、
1. ,,,,,,,'!','"', , ,'|','}',
   '~' は伝達を保証する。これは文字コードではなく、バイト列と
   して見たときに、どれを通すかということです。どちらかといえば、
   \010,\011,\012,\014,\015,\033,\040〜\176 は通すといったほうが
   いいかな。
2. コード変換はポストするとき（エディタの漢字コード-> ＪＵＮＥ
  Ｔ漢字）と、ニュースリーダで読む時（ＪＵＮＥＴ漢字-> 端末の
  漢字コード）にのみ起きる。

ということで、8bitナマと、SI/SOはダメ。
ESC-(-Iは通るということになります。

ところが、自分のところの利用者の便利を第一に考えるホストでは、
記事をスプールに入れるときに、コード変換をかけてローカル漢字
コードにしてしまします。こいうホストを通過した記事は、ESC-$-@
とESC-$-B 、 ESC-(-JとESC-(-Bの区別は保存されないことになり
ます。これはまだ罪がないというか大きな害はありませんが、
ESC-(-Iはどうなるかわかりません。つかわれているフィルタ次第で
す。

>  PS. 1
>  繰り返しお尋ねしますが, DEC 漢字コードでは 1 byte カタカナは扱えるのでしょうか?
>  扱えないとすると tabnsei と ulisvax では 1 byte カタカナの news/mail は
>  読めない可能性がありますが...
というか、これらマシンのコンソールとＤＥＣコード端末では  でしょうか。

>  PS. 2
>  ``1 byte カタカナ・コード'' と ``半角カタカナ'' は別のものであるという
>  考え方のあることも忘れないで下さい.

これは”問題のすりかえ”かあるいは”別の問題の提起”でしょ
う！！
この議論の発端はあくまでも”半角カナ”だったはずです。

``1 byte カタカナ・コード'' と ``半角カタカナ'' は完全に
独立に議論すべきです。1 byte カタカナ・コードを半角カナ
の免罪符に使われてはたまりません。

＊僕の意見。
半角カナを使えるようにするのには手間がかかる。

純粋に技術的な困難は、問題は半角カナを伝達することではありま
せん。
たとえばニュースなら、１行、変更すればSI/SOが通るようになりま
す。問題は、less,jnews,vn,rn,,,,といった漢字をあつかうユティ
リティソフトです。たとえば、icsts1のコンソールでだけ動けばい
いのなら１日hackすれば出来る自信はあります。
汎用の半角カナ処理機能をつけるとなるとやってられません。

もうひとつの問題は、どうやって各ホストの管理者に作業してもら
うかです。結局これが一番大きい。

漢字を通すための作業なら、やってくれるでしょう。自発的にがやっ
てくれなくても、利用者からの要求で、作業するでしょう。半角カ
ナのための作業はどうでしょうか。

１バイトカナコードの問題はまた別に（必要ならば）考えましょう。
僕はそれよりは１バイトかなコードの方がデータ圧縮の手法として
魅力的に感じます。

	斉藤　明紀	齊藤＠都倉研．情報．基礎工．阪大
	saitoh@icsts1.handai.junet
	わたし、ペンを４本折りました。