Path: titcca!ccut!wnoc-tyo-news!astemgw!choshi!frf!proj
From: proj@nff.ncl.omron.co.jp (Hiroshi Kuribayashi)
Newsgroups: fj.kanji
Subject: Re: Kanji code of OSF/1
Message-ID: < PROJ.90Jun7224744@hokkori.nff.ncl.omron.co.jp> 
Date: 7 Jun 90 13:47:44 GMT
Sender: news@frf.omron.co.jp
Distribution: fj
Organization: OMRON Corp., Kyoto, Japan
Lines: 210

In article < 3859@ntt-twins.ntt.jp>  nakayama@ntt-twins.ntt.JP (Nakayama Ryu~ji) writes:

通りすがりの、栗林＠オムロンです。

    で、
   < 		  sakamoto@sm.sony.co.jp (坂本智彦) さん、
   < 
   < > シフトJIS も EUC も対等にサポートできるように努力しているソニーの
   < > 坂本です。
ソニーさんも、そういう努力をされてたんですか、
それは、知らなかった。:-) それとも、ソニーさんじゃなくて、
ソニーの坂本さんが、そういう努力をされてるんですね。なっとく-:)

   < 内部コードは 16 ビットフルに使ったやつがいいと思う。
内部コードですからどうしようと勝手ですが、
   < 	    0b0xxxxxxx1xxxxxxx	JIS 漢字
   < 	    0b100000000xxxxxxx	JIS カタカナ
   < 	    0b1xxxxxxx1xxxxxxx	外字(は本当はイヤ)

   	    0b1xxxxxxx1xxxxxxx	JIS 漢字
   	    0b000000000xxxxxxx	JIS カタカナ
   	    0b1xxxxxxx0xxxxxxx	外字(は本当はイヤ)
じゃないですか? やっぱり。

   < > シフトJIS の長所と欠点を出来るだけたくさん挙げてみてください。
   < 長所:
   < 	    ・(現状では)文字の幅とコードの長さが一致している
(現状では)と、ことわってあるので、わかってるとは、思いますが、
「文字の幅」と、「コードの長さ」とは、全く違うもので、
それが、「一致している」とか、してないとか、という話しは、おかしいと
思います。

   < 	    ・designate/invoke がいらない。(これは多分必要に迫られて作られ
   < 	      た MS 漢字コードの特徴だと思います。例えばこれ以前は、各社の
   < 	      コード呼び出しのシーケンスが違っていたのでこうせざるをえなかっ
   < 	      たのだと私は思います。本来、メーカが JIS をわかるくらいの能
JIS ではなくて、ISO2022 ですね。
   < 	      力があればこんなことは起きなかったんだよね。)
というよりも、
私が思っているのは、単に、ヒストリカルな経緯だけだと思うのですが。
つまり、
もとは、ASCII だけ、それに、JISX0201 の片仮名文字集合を
ライトハーフに持ってきた。
で、JISX0208 の日本語漢字を導入しようとした時の過去との互換性を優先して、
また、ステートフルなエンコーディングは、使いたくなかったために、
C1 を使ってしまった。
と、いう風に考えているのですが。

   < 短所:
   < 	    ・小さくまとまりすぎている。拡張性に欠けるということ。JIS
   < 	      X0208-1988(あってたかな?)を採用しなくてはならなくなった時、
   < 	      どうするんでしょう?
   < 	    ・C1 制御コードが使用できない。C0 と入れ換えるか、ESC Fe を使
   < 	      うことになる。どちらにしろコード系の欠陥を ISO に助けてもらっ
   < 	      ていることになる。
   < 	    ・(上のことも含まれるのですが)およそ世の中に流布している文字コー
   < 	      ドの体系との整合が非常にとりにくい。
というよりも、エンコーディングの国際規格(ISO2022)に準拠していない
点が最大の問題だと思います。
それに、一か国語しか表せない点も問題です。これは、EUC も同じですが、
80年代はこれでも良かったけど、90年代は駄目でしょう。
(英語と、日本語のバイリンガルだ、なんていわないで下さい、
 英語というよりも、ASCII コードも日本語の一部だと思っています)

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

   < > それから、もし EUC がいいと思うなら、
   < > EUC の長所と欠点を出来るだけたくさん挙げてみてください。
   < 
   < 長所:
   < 	    ・もともと ISO のサブセットなので、ISO もしくはそれに準拠(やな
   < 	      言葉! :-)したコード系との相性がいい。
EUC は、少なくとも、デファクトスタンダードですし、(まあ、これは、主観の
問題かも知れませんが)、ISO2022 にも一応準拠していると思います。
一応と、言ったのは、コードセット2 で、SS2 を、GL ではなく、GR に
invoke している点です。
At& T UP の話しでは、日本規格協会に問い合わせたところ、GR invoke でも、
かまわないと言われたそうです。
もしそれが、事実なら、ISO2022準拠 というよりも、JISX0202準拠ですが、
どうせなら、JIS ではなく、ISO に問い合わせて欲しかった。
   < 	    ・G0 〜 G3 をきちんと扱える(designate/invoke、アナウンサの省略
   < 	      など)ならば、この枠組を拡張することは容易である。
ISO2022 で、初期状態を決めて、designate のみで、invoke を省略したのが、
「いわゆるJISコード」(何と呼べばいいのでしょう?)で、
初期状態を決めて、designate を省略し、invoke だけが、EUC と理解していますが。

長所は、やはり扱い安さでしょう。情報処理 Vol.27 No.12 pp.1399-
にも書いていますが、バイト単位で、アクセスした時に、
ASCII 文字との、区別が簡単と言う点です。
つまり、日本語などの複数文字(複数文字だけじゃないですが)を扱う場合
UN*X コマンド などの、アメリカ製のアプリケーションの改造が少なくて済む。
でしょう。

   < 短所:
   < 	    ・GL, GR に収まらない文字種を扱うと、(今の JLE だと JIS カタカ
   < 	      ナですか)とたんにコードを表すバイトの数が増える。
   < 	    ・文字が全く定義されていないバイトの組合せが多い。(これ欠点か
   < 	      な? 冗長度が高いともいえますね。)
定義されていないバイトの組合せ、てありますか?
なくて、困っているんですが。
0x8xxx, 0x9xxx ですか?
0x80 - 0x9f は、C1 だから、こんな使いかたしちゃ駄目でしょう。
0xa100 - 0xa1a0 ですか?
これも使えないですよね。

短所と言えば、一か国語しか表せない点でしょう。(latin/1は、別として)
そういや、X Consortium の meeting で、ベル研の人に、
EUC は、80年代のエンコーディングスキームとしては、良かったけど、
90年代のエンコーディングスキームとしては、もう駄目だ、
といったら、いやな顔をされたなあ。

   < ところで、EUC(Extended Unix Code(だっけ?))という呼び方もあまり気分のい
   < いものではありませんね。UNIX に依存しているみたいで。何かいい呼び方は
   < ないものかな? UJIS ってのはどういう由来があるんでしょう?
これは、AT& T UNIX パシフィック社が、依頼して、
「日本語UNIX*システム諮問委員会」なるものを
			*UNIX is registed trade make of AT& T
作って、U*IX を日本語化する場合に、持つべき機能を定義した中で、
文字集合と、文字コードの定義があって、
(多分その中で、読んでたと思うのですが、)
UN*X JIS, Upper JIS, うそ JIS, などと読んでたらしいです。
(又聞きなので、さだかではない)
でそれを、そのまんま、持ってきたのが、あの悪名高き、
SIGM* で、それを拡張したのが、EUC です。
    ^ 検閲 :-)

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

   < 私は、(3)はあまり認めたくありませんね。外字の扱いは“情報交換用”のコー
   < ドとも合わせて、なかなか難しい問題が含まれているような気がします。これ
外字の話しは、今日はやめよう。
   < から先のことを考えると、G3 集合には JIS X0208-1988 が(あれば)入ってい
   < て欲しいんだけど。
これなんですか? いわゆる、JIS第3集合ですか?
これも困り物です。漢字はいいんだけど、
ウムラウトとかが、入っているでしょう。
JIS X0208-1983 もそうだけど、ISO8859/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 じゃないですか。
   < 		    終端文字 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 は、フォントがないのでやってませんが、
キーボードの問題ではなくて、変換入力の問題でしょう。
Wnn を拡張して、中国語とか、Latin/1 とか入力できるようにしたんですが、
早く配りたいんだけど、フォントの問題(著作権)が、まだ解決してないので、
配れないんです。
近い将来、きっと配れると思います。:-)

話しは、変わりますが、ISO10646 が、問題だと思います。
まえに、和田さん@東大 計数工学科)が、post されていましたが、
	Subject: Re: alphebet numeric and symbol cahr.
	Date: 26 May 90 08:06:19 GMT

>  同じ文字が2箇所以上にあるのはのぞましくありません........
>  そこでISO4873では,....

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

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

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


もう一つ気に入らないのは、APL programing language ようの script が、
あって、ここにも、数字とアルファベットが入っていることです。