Path: titcca!ccut!wnoc-tyo-news!scslwide!wsgw!wsserva!sakamoto
From: sakamoto@sm.sony.co.jp (Tomohiko Sakamoto)
Newsgroups: fj.kanji
Subject: Shift-JIS vs EUC (Re: Kanji code of OSF/1)
Message-ID: < 43003@wsserva.sm.sony.co.jp> 
Date: 9 Jun 90 14:56:11 GMT
References: < 2624@wm120_no0.rinfo.sumiden.co.jp>  < 15735@rena.dit.co.jp>  < WD.90Jun8014756@kurims.kurims.kyoto-u.ac.jp> 
Sender: news@sm.sony.co.jp
Distribution: fj
Lines: 115

ソニーの坂本です。

ＮＴＴの中山さんが挙げてくださった EUC と MS漢字コードの長所と短所に対し
て、京都大の鴨さんから次のような意見が出されました。

In article < WD.90Jun8014756@kurims.kurims.kyoto-u.ac.jp> ,
	wd@kurims.kyoto-u.ac.jp (Kamo Hiroyasu) says:
>    わざと、ファイルコードの話と情報交換コードの話を混同していません?
>  
>    私は、ファイルコードの話に限定すると、
>  日本語EUCと比較したMS漢字コードの欠点は、
>  
>  (1) 情報交換コードへの変換アルゴリズムが複雑。
>  
>  で、長所は特になし。両者共通の欠点として、単一言語用であって、他国語処
>  理(例えば日韓辞典を作ること)のことを考えると困る。ということがあると考
>  えています。

鴨さんは、「ファイルコードの話に限定すると、」と前置きしながら、情報交換
コードへの変換アルゴリズムなんぞを持ちだしています。議論の進め方がおかし
いですね。ファイルコードと通信コードを同時に考えていることになりますよ。

「わざと、ファイルコードの話と情報交換コードの話を混同させようとしていま
せん?」とこちらが言いたくなっちゃいます:-)

本当に、「ファイルコードの話に限定する」とすれば、
同じテキストがディスクスペースやメモリースペースをどれくらい食うかとか、
テキスト処理コマンド(ファイル名を扱うシェルなども含む)のプログラミングが
どうなるかとか、
などについて EUC と MS漢字コードを比較するべきでしょう。

鴨さんの前提ですばらしい点は、EUC を日本語 EUC に限定されたことです。

別の記事で私が言ったように、シフトJIS (MS漢字コード) は、日本語だけを
対象にデザインされたコードです。
だから、国際化コードの EUC と シフト JIS を比較しても、月とスッポンなの
は目に見えています。

日本語 EUC (ASCII、JIS 漢字、JIS 片仮名、外字) と
シフト JIS (JIS ローマ字、JIS 片仮名、JIS 漢字、外字)を
比較することに意味があるのだと思います。

0x00〜0x7f に関しては対等です。
	0x00〜0x1f の C0 制御コード、0x20 の SP、0x7f の DEL はどちらに
	もあります。0x21〜0x7e の図形文字については、ASCII と JIS ローマ
	字で、0x5c の「＼」と「¥」、0x7e の「〜」と「‾」という違いはあ
	りますが、これは端末やプリンタと言ったデバイス、あるいはフォント
	の違いということで、ここでは不問にしましょう。EUC を使っていても
	端末が PC-98 なら「¥」が出ます。

C1 制御コード:
	シフトJIS にはない。完全に負け。ただし、EUC 対応と言っておきなが
	ら、C1 をいい加減に扱っているシステムやソフトは多く存在する。

漢字:
	文字の順序は、JIS X 0208 の規格どおり保存されている。
	コード自体はどちらも２バイトである。
	コードの連続性においてシフトJIS には問題がある。
	0x817e の次が 0x8180 だとか、0x9ffc の次が 0xe040 であるとか。
	(これが、鴨さんの言っておられた情報交換コードへの変換に影響して
	 いる。)
	また、シフトJIS 漢字の第２バイト目が 0x40〜0x7e で ASCII コード
	との衝突が起こる。特殊記号を頻繁に使う C や UNIX との相性は悪い。

片仮名:
	シフトJIS は１バイト、EUC は SS2 と合わせると２バイト。
	メモリースペースの点では、EUC の負け。
	ただし、この JIS X0201 の片仮名は、X0208 の漢字符号系に含まれる
	片仮名に押されて使用頻度が減少しているから、そういう意味では、
	わざと JIS X0201 片仮名を使いにくくした EUC の怪我の功名か。
	SS2 の使い方が ISO 2022 に準拠していない点は不問とする。
	EUC そのものは通信コードではないので。

外字:
	シフトJIS は、0xf040〜0xfcfc の 2444 文字を扱うことが出来る。
	EUC は、0xa1a1〜0xfefe の 8836 文字を扱うことが出来、しかも
	国際規格に基づいた 94 x 94 文字セットを使用できる。
	ただし、これも完全にサポートしているシステムやソフトが少ない。
	あっても、入出力デバイス、フォントなどの問題が大きい。
	外字は、アプリケーションソフト自体に任されているのが現状である。

以上、ファイルコードとして見てみると、やはり、後から決まっただけあって
日本語 EUC に分があるようです。そして、国際化など今後の拡張性まで考える
と EUC に軍配が上がってしまいます。

でも、でもですよ。
EUC の現状はどうかというと、日本語 EUC ですら、まともにはサポートされて
いないわけで(C1 制御コードとか、外字)、通常の我々が扱う日本語テキストに
おいては、シフトJIS も EUC も大差無いということです。

プログラマはともかく、一般ユーザはコードのことはあまり意識していないでし
ょう。パソコンやワープロは、シフトJIS が圧倒的であって、そのユーザがフロ
ッピーや Ethernet のネットワーク経由でそのファイルを処理したいのなら、シ
ステムがシフトJIS をサポートしていることに意味があるかも知れません。
実際、MS-DOS 用のアプリケーションをワークステーションで開発しているとこ
ろもあると聞きます。
また、パソコンやワークステーションをずっと以前から使っていて、大量のシフ
ト JIS データがあったり、シフトJIS 対応のアプリケーションプログラムが
たくさんあったりして、EUC への移行が困難なところもあるでしょう。

そういう意味で、シフト JIS の存在価値はまだあると言えるのではないでしょ
うか？

「FORTRAN は、いつ滅びるか！」と言っても滅びる様子はありません。
「百年河清を俟(ま)」ってみても、
メインフレームの EBSDIC が ASCII コードになるとも思えません。

将来に目を向けながら、今も生きなければならないのです。

  ソニー(株)スーパーマイクロ事業本部ワークステーション事業部
	坂本智彦	sakamoto@sm.sony.co.jp

# 一連のポストにおいて、誤字脱字の数々、内容にそぐわない Subject: などが
# ありましたことをお詫び致します。