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: < 3859@ntt-twins.ntt.jp> 
Date: 6 Jun 90 08:46:59 GMT
References: < 2624@wm120_no0.rinfo.sumiden.co.jp>  < 15735@rena.dit.co.jp> 
	< 42981@wsserva.sm.sony.co.jp> 
Sender: nakayama@ntt-twins.ntt.jp
Distribution: fj
Organization: NTT Software Laboratories, Tokyo, Japan.
Lines: 156

え〜、NTT ソフト研の中山といいます。

もしかすると間抜けなフォローかもしれませんが…

Article < 42981@wsserva.sm.sony.co.jp>  で、
	      sakamoto@sm.sony.co.jp (坂本智彦) さん、

> In article < 2624@wm120_no0.rinfo.sumiden.co.jp> 
>  	   inoue@rinfo.sumiden.co.jp ( Hiroyuki Inoue ) writes:
>  > 
>  > ＯＳＦが開発中のUNIXカーネル OSF/1 の国際化の文字コードとして Shift-JIS
>  >  が採用されるということを聞いたのですが、どうなんでしょうか？
>  
> In article < 15735@rena.dit.co.jp> ,
>  	   void@dit.co.jp (Youichi Kusakabe) says:
>  >      げげっ、もしそれがほんとなら、とんでもない。
>  >      実際のところどうなんでしょう。
>  >      私も知りたい。
>  
>  シフトJIS も EUC も対等にサポートできるように努力しているソニーの
>  坂本です。
>  枕詞が長かったようですが、ここでの発言はあくまでも私個人の意見です。
...
>  自分の気にくわないことに対して、「とんでもない」とか「邪悪だ」とか、すぐ
>  に言い出す人がいますが、もう少し理性的な意見を伺いたいもんです。

私も MS 漢字コードは好きではないのですが(シフト JIS と呼ぶことすら好き
ではない)、出来るだけ理性的にやりたいと思います。

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

内部コードは 16 ビットフルに使ったやつがいいと思う。
	0b000000000xxxxxxx	ASCII/JIS ローマ字
	0b0xxxxxxx1xxxxxxx	JIS 漢字
	0b100000000xxxxxxx	JIS カタカナ
	0b1xxxxxxx1xxxxxxx	外字(は本当はイヤ)
てな感じのやつ。

>  ところで、くさかべさん。
>  シフトJIS の長所と欠点を出来るだけたくさん挙げてみてください。

私でも答えていいのかな？

長所:
	・(現状では)文字の幅とコードの長さが一致している
	・コード空間(勝手に作った言葉です)の利用効率がいい
	・designate/invoke がいらない。(これは多分必要に迫られて作られ
	  た MS 漢字コードの特徴だと思います。例えばこれ以前は、各社の
	  コード呼び出しのシーケンスが違っていたのでこうせざるをえなかっ
	  たのだと私は思います。本来、メーカが JIS をわかるくらいの能
	  力があればこんなことは起きなかったんだよね。)

短所:
	・小さくまとまりすぎている。拡張性に欠けるということ。JIS
	  X0208-1988(あってたかな?)を採用しなくてはならなくなった時、
	  どうするんでしょう?
	・C1 制御コードが使用できない。C0 と入れ換えるか、ESC Fe を使
	  うことになる。どちらにしろコード系の欠陥を ISO に助けてもらっ
	  ていることになる。
	・(上のことも含まれるのですが)およそ世の中に流布している文字コー
	  ドの体系との整合が非常にとりにくい。

長所と短所は表裏一体ですね。長所を裏返すか、時代が変われば短所になって
しまうような感じです。EUC もそうかな?

>  それから、もし EUC がいいと思うなら、
>  EUC の長所と欠点を出来るだけたくさん挙げてみてください。

長所:
	・もともと ISO のサブセットなので、ISO もしくはそれに準拠(やな
	  言葉! :-)したコード系との相性がいい。
	・G0 〜 G3 をきちんと扱える(designate/invoke、アナウンサの省略
	  など)ならば、この枠組を拡張することは容易である。

短所:
	・GL, GR に収まらない文字種を扱うと、(今の JLE だと JIS カタカ
	  ナですか)とたんにコードを表すバイトの数が増える。
	・文字が全く定義されていないバイトの組合せが多い。(これ欠点か
	  な? 冗長度が高いともいえますね。)

あまりでないなあ。当たり前すぎて長所になってないところもあるのかもしれ
ない。

ところで、EUC(Extended Unix Code(だっけ?))という呼び方もあまり気分のい
いものではありませんね。UNIX に依存しているみたいで。何かいい呼び方は
ないものかな? UJIS ってのはどういう由来があるんでしょう?

>  また、くさかべさんは EUC をどんなものだと考えていますか？
>  
>  	   (1) 0x00〜0x7f が ASCII、0xa1a1〜0xfefe が漢字。
>  	   (2) (1) に SS2 0xa1〜0xdf の片仮名を追加したもの。
>  	   (3) (2) に SS3 0xa1a1〜0xfefe の外字を追加したもの。
>  	   (4) 0x00〜0x7f が ASCII、でコードセット０〜３は、それぞれに
>  		   ０〜４バイトの文字セットをアサインできるもの。

私は、(3)はあまり認めたくありませんね。外字の扱いは“情報交換用”のコー
ドとも合わせて、なかなか難しい問題が含まれているような気がします。これ
から先のことを考えると、G3 集合には JIS X0208-1988 が(あれば)入ってい
て欲しいんだけど。

	   (4') ISO 2022 の機能(designate/invoke)が使用でき、
		図形文字セットとして、1 〜 3(4?) バイトの文字セットが
		設定できる。
		詳しくいうと、ESC 2/4 F, ESC 2/4 2/9-F F, ESC 2/8-F F,
		SI, SO, LS0-3, LS1-3R, SS2, SS3 がきちんと動作すること。
		終端文字 F はさすがに全部というわけにはいかないだろう
		から、ASCII, JIS ローマ字, JIS カタカナ, JIS 漢字 '78,
		JIS 漢字 '83 というところでしょうか。終端文字でいうと、
		B, J, I と @, B が利用可能。

が一番嬉しいですね。G0 → GL に JIS ローマ字が欲しい人もいるかもしれな
いし（笑）。

>  これらを実現するのはどれくらい難しいと思いますか？

私はターミナルなどには(4')を実現して欲しいと思います。確かに、数種類の
文字を 4 つの文字セットバッファ(しかも 1 バイトにも多バイトにも使える)
に取り出してきて、さらに GL, GR の二つの現用コード表に持ってくるという
のは大変そうですが、各部の可搬性が相当高いので、考えているほど難しくな
いのではないでしょうか。

実用にするためにはさらに初期アナウンサの登録などが必要になるかと思いま
すが(これをしないとコードを出しても何も画面にでないかもしれない)、これ
は簡単でしょう。

また、これを完全に実現しておけば、図形文字セットとその図形文字を 
designate する終端文字さえ追加すれば全世界の大部分で使えるようになるの
です。このことを考えると決して高い投資ではないと思いますけど。まあ、実
際にはキーボードの問題とかが残っていますが。

>  別に、くさかべさんだけに訊いているつもりはありません。
>  皆さんの意見をお聞かせください。

なんか未熟な意見ですけど、現在使われているものをサポートする必要がある
のはわかります。しかし、それに欠陥があったり、拡張が出来ない状態になっ
ている場合にそれが“主”になってしまってはいけないのではないかと私は思
うのですが。

−−−−−

ところで、今突然思ったのですが、なぜ JIS カタカナは濁点・半濁点付の文
字をコードの中に入れなかったのでしょうねえ。6, 7 列が山ほど空いていた
のに。

片仮名文字セット・平仮名文字セット・漢字文字セットとわけて、コードと表
現の大きさは関係ないんだよということを徹底していれば、もうちょっと意識
が高まったかもしれないと思うのですが。面倒だけど。

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