Path: titcca!srava!kameyama
From: kameyama@srava.sra.JUNET (Toyohisa Kameyama)
Newsgroups: fj.kanji
Subject: Re: EUC &  SJIS &  JIS (Re: Hankaku KANA) (In KANJI)
Message-ID: < 783@srava.sra.JUNET> 
Date: 6 Jul 87 10:29:36 GMT
References: < 229@kaba.JUNET>  < 1450@nttspl.ntt.JUNET>  < 702@shpnar.sharp.JUNET>  < 468@cskvax.csk.JUNET> 
Distribution: fj
Organization: Software Research Associates, Inc., Japan
Lines: 40

In article < 468@cskvax.csk.JUNET> , shige@cskvax.csk.JUNET (Shigeki Yoshida) writes:
> > article < 702@shpnar.sharp.JUNET>  で
>  >  kos@shpnar.sharp.JUNET (神月（こうづき）利文）さんが
>  >  ところで、これからのソフトは『ＪＩＳ、シフトＪＩＳ、ＵＪＩＳなど
>  >  複数のコード体系を扱えることが必修だ！』なんて言われるのかなぁ。
>  
>  ユーザーから見た分には、そのユーザーの使っているＯＳ（日本語
>  ＵＮＩＸ，ΣＯＳ，ｅｔｃ）のコードさえ使えれば十分だと思います。
>  他のコードのデーターはフィルターさえあれば使えるんですから。
>  
>  開発者としては、制限付きではありますが、ＥＵＣとＳＪＩＳの両
>  バージョンを作るのはそれほど難しくはないはずです。（特にＳＪＩＳ
>  の経験がある人なら、ＥＵＣはかなり簡単だと言えると思います）
>  そして、今後の日本語ＯＳの普及を考えると、ＥＵＣとＳＪＩＳバー
>  ジョンだけで十分のような気もします。

日本語のソフトを作るときに, 内部コードとして long char (日本語 UNIX 諮問委員会
で提唱した内部コードをつかうのはどうでしょうか?
そして, 入出力のための関数で file code (euc, シフト JIS など) に変換するのです.
(当然, かなや街字もここで吸収してしまう.)

long char は, プログラム内部で使うコードであり, file code とは
無関係に使えるのではないでしょうか.

入出力の関数だけは file code 毎に作る必要がありますが,
文字列処理用の関数などは共通に使えます.
他の file code の入出力関数があれば filter も簡単に作れます.
当然のことながら, 作成されたプログラムも (入出力のための関数をさしかえるだけで)
ソース・レベルでの互換性もでてきます.
プログラマが (複数の) file code を意識する必要もなくなります.
文字の種類によって長さが異なることもないので,
プログラムがかなりすっきりかけると思います.

JUNET の皆様に提案ですが, long char library を public domain で作りませんか?
私が大学院の時に作った EUC 版 (そのときに必要だったもののみ 10 個程度)
を公開してもかまいませんが...