Path: titcca!nttlab!nttyrl!morisaki
From: morisaki@nttyrl.ntt.jp (Masato Morisaki)
Newsgroups: fj.kanji
Subject: Re: Shift-JIS vs EUC (Re: Kanji code of OSF/1)
Message-ID: < 15041@nttyrl.ntt.jp> 
Date: 11 Jun 90 11:03:42 GMT
References: < 11769@socslgw.csl.sony.co.jp> 
Distribution: fj
Organization: Advanced Information Systems lab., NTT, Yokosuka, Japan
Lines: 46

In article < 11769@socslgw.csl.sony.co.jp> ,
	kono@csl.sony.co.jp (Shinji Kono) says:
>  Unix上のテキストファイルは grep, sed, awk, less を前提としたファイルで
>  あって単なる情報交換のためにあるのではないでしょう。つまり、nlをデリミ
>  タとした行単位の可変長レコードの逐次ファイルです。

ここにひっかかる、森崎です。UNIX の基本的な magic number のない
ファイルは、stream type つまり file system が意識する
デルミタがない（ここが重要。でも、抹消論 :-)）というのが
特徴じゃないのですか？
nl をデルミタとしているのは、行という概念が必要なアプリケーション間の
了解事項でしょう。もっとも　nl をデルミタとしているアプリケーションが
ほどんどのため、可変長レコードの逐次ファイルという解釈もできるわけですが。

>  従って、行単位内部で
	>  statefull, 行単位の外でstatelessであるのが望ましいでしょ?

いいえ、端末じゃあるまいし、ファイルを行という単位で考える
メリットがどこにあります？
送りたい／交換したい情報の単位で、stateless であればいいのであって、
相手が端末であれば行でしょうけど、ファイルの場合は全体でしょう。
わざわざ　>  でかかれているようにする必要性は？

>  また、いくら
>  grepが頑張っても同じ文字列を表現するのに複数の形があったらしょせんだめ
>  だとおもいますね。

そうですか？　効率がわるい、プログラムが大変だいうだけではないのですか？

と書きましたが、河野さんのいわんとする点もわからないではないですよ。
私のいいたいのは１点。ファイル（とくにテキストファイルのなか）のコードに
関しては、「類似のエンコーディングがはびこるのは、ユーザにとって不幸ですな」
ということです。たとえば、ソニーさんの NEWS で作成された Shift-JIS ファ
イルを、これはどんなエンコーディングでかかれたファイルか hex dump を
とって調べるという、馬鹿なことはやりたくないのでね。
机のまえに Sun があって、となりに uVAX があってさらに NEWS があってという
ような状況下でカセットが山積みされていた場合どうします？

これ、XX 用、YY 用 .. という区別が必要はわけでしょう。
ベンダーさんはいいですよ。自社のマシンだけつかっておればいいわけですからね。
また、その方が上司から覚えがいいわけですし。（皮肉かな？）

>  Shinji Kono 
>  河野真治 Sony Computer Science Laboratory, Inc.: kono@csl.sony.co.jp

森崎