Path: titcca!ccut!kyu-cs!ccku-gw!kudpc!kuis!kurims!wd
From: wd@kurims.kyoto-u.ac.jp (Kamo Hiroyasu)
Newsgroups: fj.kanji,fj.comp.text
Subject: character code for text processing (Re: Shift-JIS vs EUC)
Message-ID: < WD.90Jun12151553@kurims.kurims.kyoto-u.ac.jp> 
Date: 12 Jun 90 06:15:53 GMT
References: < PROJ.90Jun11212750@hokkori.nff.ncl.omron.co.jp> 
Sender: bnews@kurims.kurims.kyoto-u.ac.jp (News Administrator)
Distribution: fj
Organization: Research Institute for Mathematical Sciences, Kyoto, Japan.
Lines: 40
Xref: titcca fj.kanji:723 fj.comp.text:204
In-reply-to: proj@nff.ncl.omron.co.jp's message of 11 Jun 90 12:27:50 GMT


  鴨ともうします。

In article < PROJ.90Jun11212750@hokkori.nff.ncl.omron.co.jp>  proj@nff.ncl.omron.co.jp (Hiroshi Kuribayashi) writes:
 >In article < 43006@wsserva.sm.sony.co.jp>  sakamoto@sm.sony.co.jp (Tomohiko Sakamoto) writes:
 > 
 >    > > >  私は、個人的には、ファイルコード、ネットワークコードとしては、ISO2022,
 >    > > >  処理コードとしては、ISO10646 だと思っています。
 >    > > 
 >    > > 栗林さんのこの発言は EUC を否定しているともとれますよ。
 > 
 > 今までは、EUC で良かったけど、これからは、EUC じゃだめだよと、
 > いっているのです。
 > だって、EUC だと、1か国語しか表せないんですもの、

  ファイルフォーマットは、そのファイルを使うアプリケーションが勝手に決
めればよい。ただし、似た目的で使うアプリケーションに共通ファイルフォー
マットがあると便利。で、文字コードというのは、テキスト処理用の共通ファ
イルフォーマットの構成要素である。これはいいですか?
  そう考えると、栗林さんの意見に納得できます。
  昔は貧しかったので、テキスト処理はプログラムと英文だけを対象にしてい
ればよかった。だから、ASCIIだけで十分だった。でも、いつまでも貧しいま
までいてはいけない。少なくとも、複数の言語が混在した文章が処理できる程
度のことは必要だ。となると、EUCでも不十分なのは当然ですよね。
  ではどうしようかということを考えます。複数の言語が混在した文章のため
の共通ファイルフォーマットおよびそのための文字コードは、現在、世の中に
存在していません。(TRON文字コードがある? あれは論外。)そうすると、一番
良いのは、自分でいいのを設計して使うこと(できれば、それを世間に広める
活動もしてもらうとうれしい。)ですが、それはたいへんです。だから、それ
ができない人は、ISO2022を流用するのがよいでしょう。

 > # といいながら、nemacs は、EUC モードで使っています。
 > # 今までは、これ(EUC)で、良かったんです。
 > # 私は、今のことをいってるんでは、なくて、明日からのコードは、どうするべきか
 > # を、みんなでそろそろ考えてもいいころだといいたいのです。

# そうですよ。今きちんと研究しておかないと、10年後は悲惨なことになって
# いますよ。(ならばおまえやれといわれるとつらい。)

					鴨 浩靖@数理解析研究所.京都大学