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: < 3871@ntt-twins.ntt.jp> 
Date: 8 Jun 90 10:24:58 GMT
References: < PROJ.90Jun7224744@hokkori.nff.ncl.omron.co.jp> 
Sender: futagami@ntt-twins.ntt.jp
Distribution: fj
Organization: NTT Software Laboratories, Tokyo, Japan.
Lines: 174

え〜、NTT の中山です。

前のに書いた部分もあるので、残ったところだけ…

Article < PROJ.90Jun7224744@hokkori.nff.ncl.omron.co.jp>  で、
	proj@nff.ncl.omron.co.jp (Hiroshi Kuribayashi) さん、

> In article < 3859@ntt-twins.ntt.jp>  nakayama@ntt-twins.ntt.JP (Nakayama Ryu~ji) writes:
>  
>  通りすがりの、栗林＠オムロンです。
...
>    < 内部コードは 16 ビットフルに使ったやつがいいと思う。
>  内部コードですからどうしようと勝手ですが、
>  	    0b1xxxxxxx1xxxxxxx	JIS 漢字
>  	    0b000000000xxxxxxx	JIS カタカナ
>  	    0b1xxxxxxx0xxxxxxx	外字(は本当はイヤ)
>  じゃないですか? やっぱり。

そですね。「こういうのがあったらな。」と考えていきなり書いちゃったもの
で、破綻があるに違いありません。

どうも、人の考えていることを後追いする性向がありまして。四〜五年くらい
前に「こうすりゃ漢字の扱いが楽になるのに」と考えたものがほとんど EUC 
だったりということがありました。ただし、SS2 のあとにはきちんと GR が来
ましたけどね。

>  私が思っているのは、単に、ヒストリカルな経緯だけだと思うのですが。
>  つまり、
>  もとは、ASCII だけ、それに、JISX0201 の片仮名文字集合を
>  ライトハーフに持ってきた。
>  で、JISX0208 の日本語漢字を導入しようとした時の過去との互換性を優先して、
>  また、ステートフルなエンコーディングは、使いたくなかったために、
>  C1 を使ってしまった。
>  と、いう風に考えているのですが。

それに加えてすでに 0x80 から 0x9F, 0xE0 から 0xFF が文字(グラフィック
文字)で使われていたというのも原因になったのでしょうね。もし 0x80 から 
0x9F が制御コードとして使われていたらこうはならなかっただろうに。

結局、MS-DOS の載った機械の基本的なところが悪いという結論になってしま
う。(笑) いかんな、もう少し建設的にやらないと。

>    < 長所:
>    < 	    ・もともと ISO のサブセットなので、ISO もしくはそれに準拠(やな
>    < 	      言葉! :-)したコード系との相性がいい。
>  EUC は、少なくとも、デファクトスタンダードですし、(まあ、これは、主観の
>  問題かも知れませんが)、ISO2022 にも一応準拠していると思います。
>  一応と、言ったのは、コードセット2 で、SS2 を、GL ではなく、GR に
>  invoke している点です。

これはほんとまぬけですね。しっかり規格に書いてあるのに。

>  つまり、日本語などの複数文字(複数文字だけじゃないですが)を扱う場合
>  UN*X コマンド などの、アメリカ製のアプリケーションの改造が少なくて済む。
>  でしょう。

こんなので妥協したのがそもそもの間違いということでしょうか。

>    < 短所:
>    < 	    ・文字が全く定義されていないバイトの組合せが多い。(これ欠点か
>    < 	      な? 冗長度が高いともいえますね。)
>  定義されていないバイトの組合せ、てありますか?
>  なくて、困っているんですが。
>  0x8xxx, 0x9xxx ですか?
>  0x80 - 0x9f は、C1 だから、こんな使いかたしちゃ駄目でしょう。
>  0xa100 - 0xa1a0 ですか?
>  これも使えないですよね。

以前、EUC のファイルを変換する時に、1 バイト目が 0xA1 - 0xFE で、2 バ
イト目が0x21 - 0x7E だったらどうするんだろう? と不思議に思ったので、こ
れを文字が未定義と表現してしまったのです。

なるほど、未定義ではなく、いけないとするわけですね。

>    < > また、くさかべさんは EUC をどんなものだと考えていますか？
>    < > 	   (2) (1) に SS2 0xa1〜0xdf の片仮名を追加したもの。
>    < > 	   (3) (2) に SS3 0xa1a1〜0xfefe の外字を追加したもの。
>  私は、(2) も嫌いです。どうして、0xa1〜0xdf の片仮名が、
>  今時必要なんでしょう。
>  過去との互換性であれば、JISX0208 の片仮名にコード変換すればしまいだと
>  思うんだけど。同じ、片仮名を表すのに、どうして2つのコードがあるんでしょう。
>  nemacs で読めないし、:-(
>  使わなければいいんでしょうが、あると使ってしまう人もいるんだ。

もしかすると ASCII / JIS ローマ字すらいらないかもしれない。同じアルファ
ベットを表すのに、漢字の方を使っちゃいけないってのはないよね。:-)

>    < から先のことを考えると、G3 集合には JIS X0208-1988 が(あれば)入ってい
>    < て欲しいんだけど。
>  これなんですか? いわゆる、JIS第3集合ですか?
>  これも困り物です。漢字はいいんだけど、
>  ウムラウトとかが、入っているでしょう。

う〜ん、そうなんですか。私は話に JIS 第 3 水準だと聞くだけで、どんなも
のかを実際にしらないんです。憶測だけでものを話してしまって申し訳ないん
ですけど。

>  JIS X0208-1983 もそうだけど、ISO8859/1 とどう使い分けるんですか?

すみません、不勉強でこの ISO 8859/1 というのは始めて聞くものなのですが。
こういう情報はどこから仕入れてくるものなのでしょう?

>    < 	       (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 がきちんと動作すること。
>  EUC は、designate 無しでしょう。
>  これって、ISO2022 じゃないですか。

そうです。利用に先だって、必要な designate すなわち、ESC ( B ESC $ ) B
LS0 LS1R を行なっておけば、まさに EUC の端末として使えるわけでしょう。

逆に、(いわゆる)JIS の端末として使うのなら、ESC ( B SI とやればそこで
すぐに JIS の端末になりませんか?

このアナウンスシーケンスの省略を端末が機能として持っていればセットアッ
プによっていかようにも端末が使い分けられます。

やりすぎですかね。

>    < 		    終端文字 F はさすがに全部というわけにはいかないだろう
>    < 		    から、ASCII, JIS ローマ字, JIS カタカナ, JIS 漢字 '78,
>    < 		    JIS 漢字 '83 というところでしょうか。終端文字でいうと、
>    < 		    B, J, I と @, B が利用可能。
>  私は、ESC 2/4 A, ESC 2/4 C, ESC 2/13 A もほしい。

すみません、この最後のは中国語ですか?

>    < また、これを完全に実現しておけば、図形文字セットとその図形文字を 
>    < designate する終端文字さえ追加すれば全世界の大部分で使えるようになるの
>    < です。このことを考えると決して高い投資ではないと思いますけど。まあ、実
>    < 際にはキーボードの問題とかが残っていますが。
>  これに近いことは、もう実現してますよ。
>  さすがに、ESC 2/4 C は、フォントがないのでやってませんが、
>  キーボードの問題ではなくて、変換入力の問題でしょう。

そうなのですか、やはり出来るところではすでにやってるんですね。

未来は明るいかもしれない。

>  話しは、変わりますが、ISO10646 が、問題だと思います。
...
>  ISO10646 には、JISX0208 の4区、5区、16区-94区までが、入ってるだけです。
>  記号は、バラバラに、一部が入っていますが、ないものもパラパラ、
>  アルファベット、などは、latin script を使えと言うことになっています。

先取権ってところでしょうか。あとから来たコードは重複部分は使わないよう
にってことかな。

>  で、JISx0208 からのコード変換をどうするか、
> と言うか、ISO2022  ISO10646のコード変換は、
>  テーブルを引くしかなく、ちょっと大変。ない記号をどうしよう?
>  と、思っている今日この頃です。

そうですね。1, 2 区でない記号って結構ありますからねえ。

反対方向で変換不能ってのは確かありませんよね。

>  まあ、この際過去との互換性を捨てちゃって、
>  JISX201 の片仮名みたいに、後で困らないように、
>  と言うのも一つですが、、、、
>  皆さんは、どうお考えですか?

どっちかっていうと全部含んだ複数バイト文字セットを使って、それしか使わ
ないっていう方がいいかもしれない。

やっぱり書き足りないような気がする。

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