Path: titcca!ccut!wnoc-tyo-news!scslwide!wsgw!wsserva!sakamoto
From: sakamoto@sm.sony.co.jp (Tomohiko Sakamoto)
Newsgroups: fj.kanji
Subject: Re: Kanji code of OSF/1
Message-ID: < 42998@wsserva.sm.sony.co.jp> 
Date: 9 Jun 90 06:47:22 GMT
References: < PROJ.90Jun7224744@hokkori.nff.ncl.omron.co.jp>  < 3871@ntt-twins.ntt.jp> 
Sender: news@sm.sony.co.jp
Distribution: fj
Lines: 65

オムロンの栗林さん:
> >  EUC は、少なくとも、デファクトスタンダードですし、(まあ、これは、主観の
> >  問題かも知れませんが)、ISO2022 にも一応準拠していると思います。
> >  一応と、言ったのは、コードセット2 で、SS2 を、GL ではなく、GR に
> >  invoke している点です。

In article < 3871@ntt-twins.ntt.jp> ,
	nakayama@ntt-twins.ntt.JP (Nakayama Ryu~ji) says:
>  これはほんとまぬけですね。しっかり規格に書いてあるのに。
 
ソニーの坂本です。
中山さんは、EUC のことをまぬけだと言っておられるのでしょうか。
私は、すべてのロッキングシフトおよびシングルシフトを用意しなかった
ISO 2022 のほうがまぬけだと思っています。

	LS0	00/15	(７ビット環境での SI, 0x0f)
	LS1	00/14	(７ビット環境での SO, 0x0e)
	LS2	ESC 06/14
	LS3	ESC 06/15
	LS0R	なし
	LS1R	ESC 07/14
	LS2R	ESC 07/13
	LS3R	ESC 07/12
	SS0	なし
	SS1	なし
	SS2	08/14	(EUC の 0x8e)
	SS3	08/15	(EUC の 0x8f)
	SS0R	なし
	SS1R	なし
	SS2R	なし
	SS3R	なし

歴史的理由で G0 を８ビットコードの右側に invoke できないのは、まあいいと
して、SS1、SS1R、SS2R、SS3R がないのは、規格の一貫性を損なっていると思い
ます。SS2R、SS3R があれば、ISO 2022 完全準拠の EUC が出来たのに。

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

妥協しなかったら、シフトJIS 以上に扱いにくいコードになっていたでしょう。

例えば、EUC のコードセット２の SS2 0xa2 が SS2 0x22 となるわけで、このコ
ードは ASCII の「" 」とぶつかってしまいます。他の文字も同様で、すべての
ASCII と衝突することになります。
つまり、シフトJIS は、0x40、0x5b〜0x60、0x7b〜0x7e が、特に 0x5c の「\」
が UNIX &  C と相性の悪い要因になっているのに、それに輪を掛けて混乱を招く
コードになってしまいます。
本来なら、処理コードを使わなくても済んだアプリケーションも大改造が必要と
なってしまうことが予想されます。

EUC は、あくまでも UNIX 用のコードなのす。

そして、シフト JIS コード は、MS漢字コードと呼ばれるように、Microsoft 社
が、自社の BASIC、FORTRAN、そして MS-DOS に用いる「日本語コード」として
デザインされたものだということです。

だから、EUC とシフト JIS を同じ土俵で戦わせることはどだい無理な話なのか
も知れません。