Path: titcca!nttlab!creamy!etlcom!ulisvax!saka
From: saka@ulisvax.ulis.JUNET (Tetsuo Sakaguchi)
Newsgroups: fj.kanji
Subject: Re: JIS78/83 and Shift-JIS
Message-ID: < 2031@ulisvax.ulis.JUNET> 
Date: 6 May 89 02:11:40 GMT
References: < 608@crimson.kek.junet>  < 3217@sami.cs.titech.JUNET>  < 2028@ulisvax.ulis.JUNET>  < 3308@icsts1.osaka-u.junet> 
Reply-To: saka@ulis.JUNET (Tetsuo Sakaguchi)
Distribution: fj
Organization: Univ. of Lib. &  Info. Sci., Tsukuba, Japan
Lines: 50

どうも、阪口＠図情大です。

In article < 3308@icsts1.osaka-u.junet>  saitoh@icsts1.osaka-u.junet (SAITOH Akinori) writes:
> これは端末の問題であってＥＵＣの問題ではないと思います。

確かに端末の問題であるというのが正しいかも知れません。
でも、実際に端末に正しく表示されるような実現法が取られていなければ、
いくらＥＵＣがそれ自身きちんとしていると言っても、実際には
統一されていないのと同じことになってしまうのではないでしょうか？
（例えば、「ＭＳ漢字コードも JIS78 で統一しているんだけど各パソコンが
ちゃんと表示しないだけなんだ。」と言われて納得できるでしょうか？）

正確に端末側の責任になるのは以下のような場合だと思います。

(1) EUC 対応と言っているのに JIS78 のフォントで表示する。
	(EUC が JIS83 に基づいている場合。）
(2) ESC-$-@ を受け取っても JIS83 として表示する。
(3) ESC-$-B を受け取っても JIS78 として表示する。

> 古い規格に基づいた製品が新しい規格をうまく扱えないのは当たり前です。

問題は JIS78 が単純に「古い」規格と言い切れないところにもあります。
あれは国際規格上は２種類の文字セットとして登録してあるはずです。
だから JIS なんかでは文字セットの呼び出しとして、ESC-$-@ と ESC-$-B の
二つあるでしょう？

> JIS83 が JIS78 の スーパーセットになっていないのがそもそもの
> 不幸の始まりだとは思いますが、あくまでも責任はEUC-> JIS83 の変

同感です。本当なら JIS83 の時点で JIS78 の修正じゃなくて
全く別の文字セットにすべきだったのではないかと思います。
（つまり JIS78 (@) のセットにない文字から JIS83 (B) を構成する。）

> 換アルゴリズムとJIS78フォントを持って”EUC対応”と称する端末
> にあって、規格を満たさない端末に対応していない EUC コードにあ
> るのではないと思います。

これは全くそのとおりでしょう。つまり「ＥＵＣ対応」と言っている
物がちゃんとやっていないために、ＥＵＣに濡れ衣がかかってしまう
ということになると思います。

結局は実現する側の意識の低さも問題なんでしょう。
（でも、ISO の委員会なんかでは JIS78 と JIS83 ってどんな風に
見られているのでしょうね？）

--
阪口哲男＠図書館情報大学（大学院研究科修士課程２年）
E-mail address: saka@ulis.junet (JUNET)
                PEC00237        (NIFTY-Serve)
                74420,237       (CompuServe)