Path: titcca!ccut!wnoc-tyo-news!astemgw!choshi!frf!proj
From: proj@nff.ncl.omron.co.jp (Hiroshi Kuribayashi)
Newsgroups: fj.kanji
Subject: Re: Shift-JIS vs EUC
Message-ID: < PROJ.90Jun11213819@hokkori.nff.ncl.omron.co.jp> 
Date: 11 Jun 90 12:38:19 GMT
Sender: news@frf.omron.co.jp
Distribution: fj
Organization: OMRON Corp., Kyoto, Japan
Lines: 39

In article < 11769@socslgw.csl.sony.co.jp>  kono@csl.sony.co.jp (Shinji Kono) writes:

   > > UnixだったらEUCと思いつつShift-JISを使っている河野です。

   >>In article < 15029@nttyrl.ntt.jp>   , morisaki@nttyrl.ntt.jp (Masato Morisaki)writes 
   > > >  ファイルというのは、本来情報交換のためにあるのではないですか？
   > > >  grep, sed, awk などのアプリケーションの処理のしやすさを先に考えるべきでなく、
   > > >  ファイルの本来の目的からファイルコードというを考えるべきでしょう。
   > > 
   > > Unix上のテキストファイルは grep, sed, awk, less を前提としたファイルで
   > > あって単なる情報交換のためにあるのではないでしょう。つまり、nlをデリミ
   > > タとした行単位の可変長レコードの逐次ファイルです。従って、行単位内部で
   > > statefull, 行単位の外でstatelessであるのが望ましいでしょ? また、いくら
   > > grepが頑張っても同じ文字列を表現するのに複数の形があったらしょせんだめ
   > > だとおもいますね。というわけで坂本さんの方に賛成。これは、Unixのファイ
   > > ルの暗黙の仮定でしょうね。テキストファイルにmagicがついてないのはおか
   > > しいけど。

えぇ〜。grep, sed, awk, less は、ファイルコードで、
ええっと、これは2バイトだから〜、なんてやっているんですか?
# といいながら、LUNA も実は似たりよったりのような気もして恐い。
でも、これは間違いですよ。ファイルのエンコーディングと、
内部処理とは、独立だと思っている私です。

   > > ただし、NFSとかcut and pasteが入ってくるなら、その転送の過程ではISO
   > > 2022がいいと思います。

NFS サーバにコード変換を入れるって話しもいいですね。
でも、これは冗談じゃなくてやってますよ。
IBM ホストのEBSDIC とLUNA のEUC 間で、もっともやってるのは、
IBM 側ですけどね。(多分)