Path: titcca!ccut!kyu-cs!ccku-gw!kudpc!kuis!kurims!wd
From: wd@kurims.kyoto-u.ac.jp (Kamo Hiroyasu)
Newsgroups: fj.kanji
Subject: Re: Kanji code of OSF/1
Message-ID: < WD.90Jun8014756@kurims.kurims.kyoto-u.ac.jp> 
Date: 7 Jun 90 16:47:56 GMT
References: < 2624@wm120_no0.rinfo.sumiden.co.jp>  < 15735@rena.dit.co.jp> 
	< 42981@wsserva.sm.sony.co.jp>  < 3859@ntt-twins.ntt.jp> 
Sender: bnews@kurims.kurims.kyoto-u.ac.jp (News Administrator)
Distribution: fj
Organization: Research Institute for Mathematical Sciences, Kyoto, Japan.
Lines: 121
In-reply-to: nakayama@ntt-twins.ntt.JP's message of 6 Jun 90 08:46:59 GMT


  鴨ともうします。

In article < 3859@ntt-twins.ntt.jp>  nakayama@ntt-twins.ntt.JP (Nakayama Ryu~ji) writes:
 >Article < 42981@wsserva.sm.sony.co.jp>  で、
 > 		sakamoto@sm.sony.co.jp (坂本智彦) さん、
 > 
 > >  自分の気にくわないことに対して、「とんでもない」とか「邪悪だ」とか、すぐ
 > >  に言い出す人がいますが、もう少し理性的な意見を伺いたいもんです。
 > 
 > 私も MS 漢字コードは好きではないのですが(シフト JIS と呼ぶことすら好き
 > ではない)、出来るだけ理性的にやりたいと思います。

  「もう少し理性的な意見を伺いたいもんです」というのは、デマゴーグが他
人に意見を罵倒する時によく使う言葉だから、安易に言って欲しくないんです
けどね。だいたい、根拠を示さずに他人の意見が理性的でないと断定するなん
て議論のマナー以前の問題ですよ。まあ、坂本さんも筆がすべっただけでしょ
うから無視してあげましょう。

 > 情報交換用コードは必ず designate/invoke がいると思っているので(だから、
 > 普通の文章でたとえ始めにアルファベットが来ても、始めには ESC ( B とか
 > が来るべきだと思ってます)、今の議論はファイルコードのことだと思って話
 > をします。

  私も、ファイルコードのことだという前提で話をします。
 > >  ところで、くさかべさん。
 > >  シフトJIS の長所と欠点を出来るだけたくさん挙げてみてください。
 > 
 > 私でも答えていいのかな？
 > 
 > 長所:
 > 	  ・(現状では)文字の幅とコードの長さが一致している

  コラム数を計算するかわりにバイト数を数えることで代用できるという意味
ですか?  それは話が逆ではないでしょうか?  多くのアプリケーションが安易
にバイト数を数えることで代用しているため、使用できる端末やプリンタが制
限されているという現状になっているということでは?  だから、これは文字
コード系の長所とか短所とかとは違うと思いますが。

 > 	  ・コード空間(勝手に作った言葉です)の利用効率がいい

  ごめんなさい、意味がわかりません。空きコードが少ないという意味ですか?
それって長所でしょうか?

 > 	  ・designate/invoke がいらない。(これは多分必要に迫られて作られ
 > 	    た MS 漢字コードの特徴だと思います。例えばこれ以前は、各社の
 > 	    コード呼び出しのシーケンスが違っていたのでこうせざるをえなかっ
 > 	    たのだと私は思います。本来、メーカが JIS をわかるくらいの能
 > 	    力があればこんなことは起きなかったんだよね。)

  日本語EUCもそうだと思いますけど。

 > 短所:
 > 	  ・小さくまとまりすぎている。拡張性に欠けるということ。JIS
 > 	    X0208-1988(あってたかな?)を採用しなくてはならなくなった時、
 > 	    どうするんでしょう?

  そうですね。でも、拡張する方法はあるでしょう。

 > 	  ・C1 制御コードが使用できない。C0 と入れ換えるか、ESC Fe を使
 > 	    うことになる。どちらにしろコード系の欠陥を ISO に助けてもらっ
 > 	    ていることになる。

  これは重要なことだと私も思います。

 > 	  ・(上のことも含まれるのですが)およそ世の中に流布している文字コー
 > 	    ドの体系との整合が非常にとりにくい。

  ファイルコードとしてだけ考えるなら、世の中で使われている情報交換コー
ドとの変換が容易であるかどうかだけかんがえれば、いいはずですよね。つま
り、これは、「変換アルゴリズムが複雑である」ということですよね。

 > 長所と短所は表裏一体ですね。長所を裏返すか、時代が変われば短所になって
 > しまうような感じです。EUC もそうかな?
 > 
 > >  それから、もし EUC がいいと思うなら、
 > >  EUC の長所と欠点を出来るだけたくさん挙げてみてください。
 > 
 > 長所:
 > 	  ・もともと ISO のサブセットなので、ISO もしくはそれに準拠(やな
 > 	    言葉! :-)したコード系との相性がいい。
 > 	  ・G0 〜 G3 をきちんと扱える(designate/invoke、アナウンサの省略
 > 	    など)ならば、この枠組を拡張することは容易である。
 > 
 > 短所:
 > 	  ・GL, GR に収まらない文字種を扱うと、(今の JLE だと JIS カタカ
 > 	    ナですか)とたんにコードを表すバイトの数が増える。
 > 	  ・文字が全く定義されていないバイトの組合せが多い。(これ欠点か
 > 	    な? 冗長度が高いともいえますね。)
 > 
 > あまりでないなあ。当たり前すぎて長所になってないところもあるのかもしれ
 > ない。

  わざと、ファイルコードの話と情報交換コードの話を混同していません?

  私は、ファイルコードの話に限定すると、
日本語EUCと比較したMS漢字コードの欠点は、

(1) 情報交換コードへの変換アルゴリズムが複雑。

で、長所は特になし。両者共通の欠点として、単一言語用であって、他国語処
理(例えば日韓辞典を作ること)のことを考えると困る。ということがあると考
えています。

  ところで、数カ月前、fj.lang.mod2で日本語処理について議論した時に書い
たことですが、テキスト処理を考える時に、「活字文化における文字の概念を
コンピュータ上に射影したもの」と「文字をコンピュータ上で表現したもの」
をきちんと区別して考えないと、本当はいけないんですよ。ところが、これま
ではコンピュータの世界が貧しかったため、仕方なく両者を混同して処理が行
なわれていたんです。私たちは、そういった貧しい過去をひきずっているんで
すよ。
  でも、このままでは貧しいままですから、ここらへんで何とかしないといけ
ないんですけどね。
  ここらへんをきちんと考えて文字コード体系を再設計する研究とかは、どな
たか、やっていらっしゃらないのでしょうか。TRON文字コードなんかはそれを
目指していたのかもしれないけど、残念ながら論外の駄作でしたね。(こう書
くとTRON派が「もっと理性的に云々」といってくるかもしれないので、念のた
め宣言しておきます。私は理性的に検討した結果TRON文字コードは論外の駄作
であるとの結論に達したのです。これについて議論する用意はあります。)

					鴨 浩靖@数理解析研究所.京都大学