Path: titcca!srava!nisimura
From: nisimura@srava.sra.JUNET (Tohru Nisimura [peg])
Newsgroups: fj.kanji
Subject: Re: Kanji no Escape (in kanji)
Message-ID: < 427@srava.sra.JUNET> 
Date: 2 Mar 87 07:36:35 GMT
Reply-To: nisimura@srava.sra.JUNET (Tohru Nisimura [peg])
Distribution: fj
Organization: Software Research Associates, Inc. Tokyo, Japan
Lines: 102


［遅くなりまして］

漢字コードコンベンションは小川さんの言うとおり< 376@tsuda.JUNET> 
コミュニケーションのためのコード約束で、篠田さんの言うところの
 ネットワークレイヤに関するものです。
それで各サイトの利用しているコード系への変換やアホ端末への対応は
各自それぞれデータを受け取ったものの責任でやるということで。

それから８ビットスルーが確立されているサイト間のメイル／ニュース
のやりとりについては当事者間のプライベートな諒解が交わされているなら
シフトＪＩＳで送ろうがＥＵＣで送ろうが構わない。このコンベンションは
そのような諒解に制限を加えるものでない。さらにここで「標準」ではなくて
「コンベンション」といってるのは、いま議論している漢字混じりデータに
関する約束があくまで「諒解事項」であって状況が変わればまた改変されるべき
性質のものであることを意図している。現在過渡期にあって非常に混乱している
日本語利用環境がべつななんらかの形に移行したとみなが判断したらまた議論して
変える。その意味で「標準」ではない。（「標準」という言葉になにかウラミが
あるんじゃないかとかいわれそうーだ）

コンベンションはＩＳＯ準拠でみなさんいいですね。

現在８ビットスルー体制が確立されていないので、最上位ビットを情報表現に使
う８単位符号は使えません。それで７単位符号の図形文字領域をとっかえひっかえ
使うことになります。いまはＧ０〜Ｇ３の４つのバッファうちＧ０のみを使う
ことになってます。そうするとＧ０バッファは７単位図形文字領域と同一視する
ことができて、Ｇ０指示シーケンス（ESC $ final）をもってＧ０呼び出しも兼ね
てしまう。結果として Locking Shift LS0 (= SI), LS1 (= SO), LS2, LS3 は
データストリーム中にに現われない、という仕組みになっているのですね。

そこで半角カナ問題ですが、森崎さんはこう書きました< 161@nttyrl.ntt.junet> 
> さて，上記のような誤解がおきるのは，英数字とカタカナのきりかえのときは，
> ７−ｂｉｔ系でｉｎｖｏｋｅをもちいていながら，英数字と漢字では同じ７−
> ｂｉｔ系で，ｄｅｓｉｇｎａｔｅをもちいるというようなおことやっているた
> めだとおもいます。

つまりＧ１にＪＩＳカナが指示されていると仮定してＳＯで半角カナへ切り換え、
ＳＩで元へ戻る（Ｇ０を呼び出す）というような状況のことですね。
上に述べたようにＧ０バッファのみを使う現在の諒解では、半角カナを使いたい
ならＳＯ／ＳＩは使わないでＧ０にＪＩＳカナ図形文字集合を指示するのが
（ESC $ H）正当でしょう。
しかしながら市販のコード系変換プログラムは半角カナが出てくると（たぶん）
ＳＯとやらかすでしょう。それに ESC $ H とやってちゃんとＧ０にＪＩＳカナが
指示できる端末（じゃなくて、端末エミュレータ。バカな端末エミュレータは
早く廃ててしまおう）がどれだけあるのかかなり心配です。Ｇ０バッファのみ
使うようにしているのがマズいわけなんだが、だからといって「Ｇ１は半角カ
ナだけ許す」なんてことにすると誤解と混乱の元だから、いろいろ異論も多い
でしょうが「８ビットカナコードは使わない」に換えて（８ビット系は使わない
のだから）

	＠　半角カナ図形文字集合はこれを使わない。
	
ここはスッパリとこうゆうことで。


そんで再び森崎さんの提案から。
森崎さんの提案とは、Ｇ０〜Ｇ３の４つのバッファをフルに使って７単位図形
文字領域を呼び出しシーケンス、ロッキングシフト（ＬＳ０、ＬＳ１、ＬＳ２、
ＬＳ３）でもって切り変えて使おうというものです。Ｇ０〜Ｇ３の割り当ては	

		Ｇ０		ＡＳＣＩＩあるいはＪＩＳローマン
		Ｇ１		ＪＩＳカナ
		Ｇ２		２バイト漢字図形文字（新旧どちらか）
		Ｇ３		（ＮＡＰＬＩＰＳ）

てなわけですね。Ｇ１／Ｇ２への指示を入れ替えるとこれはもうＥＵＣですな。
ＮＡＰＬＩＰＳを持ち出すなんてさすがＮＴＴ！、ゆーことが違う。
で森崎さんの意図を想像するに、ESC $ J シーケンスが多用されている現在の
状況では、たとえばふだんＧ０にＡＳＣＩＩを割り当てている人が cat かなにか
で直接にファイルを読んだとき、Ｇ０に勝手にＪＩＳローマンが残されてしまって
バックシュラッシュが円記号になったりしてじつに気分が悪い、とかいうのも
あるのかもしれません。
この提案もまた魅力的ですが、Ｇ０〜Ｇ３の割り当てをどうするかという
非常に難しい合意をする必要があって、ちょぉっと時期尚早かとも思いますが、
皆さんの議論に期待します。（ｉｎｖｏｋｅのほうがｄｅｓｉｇｎａｔｅより
処理しやすいというのは、一般的に言って正しくありません）


８０バイト問題ですが、これは技術的問題というより「more みると画面が乱れて
気分が悪い」と行ったレベルの問題で、表示したとき右端が漢字コードであると
画面がわやくちゃなるのは漢字やコード系切り換えについて何も考慮されていない
more を使うのが悪いと考えます。漢字対応でないものを利用することで生じる
不都合をコンベンションで解決しようというのははっきり間違っていると思います。

わたしは加藤さんの言う

エスケープシーケンスを含めて２５５バイト以下。
ただ，エスケープシーケンスを除いたとき，８０バイトあるい
は７５バイト程度以下にすることを奨励する。

が現実的妥当と考えます。


「いま議論しているのはプロセスコードでもなくファイルコードでもなくて、
コミュニケーションコードである」、これはいいですか？



				たくさん書いて疲れた、橘先生荒れてますねの
				にしむら＠ＳＲＡ

	美奈子はぶー子