Path: titcca!nttlab!ntt-twins!nakayama
From: nakayama@ntt-twins.ntt.JP (Nakayama Ryu~ji)
Newsgroups: fj.kanji
Subject: Re: Kanji code of OSF/1
Message-ID: < 3870@ntt-twins.ntt.jp> 
Date: 8 Jun 90 09:19:11 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> 
	< WD.90Jun8014756@kurims.kurims.kyoto-u.ac.jp> 
Sender: nakayama@ntt-twins.ntt.jp
Distribution: fj
Organization: NTT Software Laboratories, Tokyo, Japan.
Lines: 124

あいやー、やっぱりしろうとの浅知恵でフォローするとボロが出ますね。

え〜、NTT の中山です。

Article < WD.90Jun8014756@kurims.kurims.kyoto-u.ac.jp>  で、
	wd@kurims.kyoto-u.ac.jp (鴨 浩靖) さん、

>    鴨ともうします。
...
>    私も、ファイルコードのことだという前提で話をします。
...
>   > >  シフトJIS の長所と欠点を出来るだけたくさん挙げてみてください。
...
>   > 長所:
>   > 	  ・(現状では)文字の幅とコードの長さが一致している
>  
>    コラム数を計算するかわりにバイト数を数えることで代用できるという意味
>  ですか?  それは話が逆ではないでしょうか?  多くのアプリケーションが安易
>  にバイト数を数えることで代用しているため、使用できる端末やプリンタが制
>  限されているという現状になっているということでは?  だから、これは文字
>  コード系の長所とか短所とかとは違うと思いますが。

はい、全くその通りです。じつは、欠点ばかりが思いついて、長所が思いつか
なかったので、短所を裏返して長所にしてしまった感があります。

つまり、今はこれで代用できてるからいいけど、将来(すでに?)文字の幅なん
てのがプロポーショナルになった時この長所は全く役に立たないよという感じ
の意味で入れちゃいました。誤解を招くような表現ですみません。

>   > 	  ・コード空間(勝手に作った言葉です)の利用効率がいい
>  
>    ごめんなさい、意味がわかりません。空きコードが少ないという意味ですか?
>  それって長所でしょうか?

はい、これもそのつもりです。良くあんな狭いところに詰め込んだというのが
正直な感想だったので。しかし、そのせいで最上位ビットが落ちた時、EUC な
らすぐ修復出来ますけど、MS 漢字コードだと非常に難しいというのがありま
すね。こう見ると立派に短所です(笑)。時々これで悩まされてます。

>   > 	  ・designate/invoke がいらない。(これは多分必要に迫られて作られ
>  
>    日本語EUCもそうだと思いますけど。

これは完全に勘違いでした。SS2, SS3 を invoke の一種だととらえてしまっ
たので。

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

う〜む、なんだか屋上屋を重ねてヌエのようになりそうな…

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

以前制御コードを使わなくてはならなくなった時、CSI (9/11) を山ほど使っ
てしっかり漢字と衝突したことがあります。

あとで苦労したのなんのって。

>   > 長所と短所は表裏一体ですね。長所を裏返すか、時代が変われば短所になって
>   > しまうような感じです。EUC もそうかな?
>   > 
>   > >  それから、もし EUC がいいと思うなら、
>   > >  EUC の長所と欠点を出来るだけたくさん挙げてみてください。
...
>   > あまりでないなあ。当たり前すぎて長所になってないところもあるのかもしれ
>   > ない。
>  
>    わざと、ファイルコードの話と情報交換コードの話を混同していません?

書いてる時には気がつきませんでしたが、大当たりですね。そう、言いたいこ
とは、ファイル / 内部コードが ISO 2022 を基礎においていればすっきりし
ているということだけなんですね。

一番言いたかったのは、C1 領域を文字のために使わないで欲しかったという
ことだけだったんです。

たくさん書こうとして失敗してしまった。

>    私は、ファイルコードの話に限定すると、
>  日本語EUCと比較したMS漢字コードの欠点は、
>  
>  (1) 情報交換コードへの変換アルゴリズムが複雑。
>  
>  で、長所は特になし。両者共通の欠点として、単一言語用であって、他国語処
>  理(例えば日韓辞典を作ること)のことを考えると困る。ということがあると考
>  えています。

結局、狭いところにステートレスで収めようとすること自体がそもそも一国だ
けのことしか考えていないのでしょう。今までの ISO 登録文字セットにして
も結局一国使用のためのものなわけですから。

全世界のことを考えるとどれだけ大きくなることやら。

>    でも、このままでは貧しいままですから、ここらへんで何とかしないといけ
>  ないんですけどね。

一から考え直さないと、あとで苦労してしまいますよねえ。X0208 も五年毎の
改定のたびに歪んでいくような気がするし。

>    ここらへんをきちんと考えて文字コード体系を再設計する研究とかは、どな
>  たか、やっていらっしゃらないのでしょうか。TRON文字コードなんかはそれを

結局、流行らない研究なのでしょうか? まだまだ日本はせせこましいのかもし
れない。○年以内に成果を出さないといけないとか。

まだ何か書き足りないような気がしますが、どうも頭の中にあることを全部外
に出せなくて困っているんです。コードを書いて表現した方がわかってもらえ
そうだ(笑)。

では。また厳しくお教え願います。

--
　／＼／＼　　　　　　お金で買えないものがここにある…
／　　＼　＼　日本電信電話株式会社　ソフトウェア研究所　中山隆二
＼　←／　／
　＼／＼／　　　　　　　　　　　　nakayama@ntt-twins.ntt.jp