Path: titcca!ccut!creamy!nttlab!nttyrl!morisaki
From: morisaki@nttyrl.ntt.jp (Masato Morisaki)
Newsgroups: fj.kanji
Subject: Re: RE:Shift-JIS vs EUC (Re: Kanji code of OSF/1)
Message-ID: < 15029@nttyrl.ntt.jp> 
Date: 11 Jun 90 02:18:36 GMT
References: < 43006@wsserva.sm.sony.co.jp> 
Distribution: fj
Organization: Advanced Information Systems lab., NTT, Yokosuka, Japan
Lines: 49

In article < 43006@wsserva.sm.sony.co.jp> ,
	sakamoto@sm.sony.co.jp (Tomohiko Sakamoto) says:
>  ファイルコードが ISO 2022 というのは、ダメです。
>  ISO 2022 というのは、定義が大きすぎて、同じ文字列を表現するのに複数の形
>  が存在しえます。
>  だから、EUC のように ISO 2022 のサブセットで、しかも、文字列を一意に決定
>  できるコーディング方式がファイルコードに適しています。
>  ISO 2022 は、あくまでも情報交換用コードです。システム間のシリアルなデー
>  タ転送には向いていても、grep、sed、awk などで、行、あるいはフィールドを
>  切ったり貼ったりする UNIX には不適応です。

ファイルというのは、本来情報交換のためにあるのではないですか？
grep, sed, awk などのアプリケーションの処理のしやすさを先に考えるべきでなく、
ファイルの本来の目的からファイルコードというを考えるべきでしょう。
逆に grep, sed, awk などが工夫をすればいい。これを効率的に作るあるいは
ベンダーが用意するのが筋道じゃないですか？このいいアルゴリズムを考えた
ところの製品が優秀なわけでしょう。

この観点からみると、ファイルコードは ISO 2022 で統一すべきです。
それも、ISO 2022 は state full ですから、厳密にファイルの先頭に
すべてのアンサー等をした記述にすべきでしょう。
逆に、EUC など、すべて暗黙の了解が仮定になっているわけですから、
この仮定をだれが守るか、どう省略するかでいつももめているわけです。

問題は ISAM 等での、fix structure をもったファイルでの扱いですね。
だいたいが filed length などというもので、入れるスロットが制約を
うけるわけでここには、state less のがほしい。このときこそ、アプリ
ケーションのファイル設計者が、徹底してあるコンベンションを定めて
しまえばいい。sift-JIS でも UJIS でも、EUC でもいいわけです。
ようは、この種の structured ファイルを扱うのは、同じ体系の
アプリケーションですから、このコンベンションを守りさえすればいい。

いま、私のように、マルチベンダー環境（ＮＴＴがＵＮＩＸを特定の
メーカのマシンだけで統一することは社会的にゆるされますか？）で
仕事をせざる環境での最大の問題は、単純なテキストファイルでも
暗黙の了解を仮定して複数の encoding を相手にせざるを得ないという
ことです。暗黙の了解はすべてのマシン、アプリケーションで一致し、
それが守られないと意味をなさないのです。暗黙の了解が複数存在する
なら、それはないに等しいことでしょう。
とくに、これが、X の ICCCM のように、リアルタイムで情報交換する
場合ででもですよ。（だれだ、ICCCM、 XLFD のように不完全な定義状況
下での投票の時、JIS 関係で 8bit 目の議論で両方を投票したのは！
ベンダーのエゴですな。。）

坂本さんは、情報交換という範囲をどの程度までととらえています？
わたしは、ファイル（データセット）、通信系の範囲でことなるマシンとの
interconnection がある場合すべてを、その範囲であると考えていますが。

森崎＠ＮＴＴ