Path: titcca!srava!kameyama
From: kameyama@srava.sra.JUNET (Toyohisa Kameyama)
Newsgroups: fj.kanji
Subject: Re: long char (Re: EUC &  SJIS &  JIS) (In KANJI)
Message-ID: < 820@srava.sra.JUNET> 
Date: 20 Jul 87 10:04:00 GMT
References: < 468@cskvax.csk.JUNET>  < 783@srava.sra.JUNET>  < 473@cskvax.csk.JUNET>  < 768@shpnar.sharp.JUNET> 
Distribution: fj
Organization: Software Research Associates, Inc., Japan
Lines: 81



亀山です. 返事が遅くなってしまってすみません.

この提案の意図は,
1. 日本語を取り扱うプログラムの作成を楽にする.
2. 異なる file code でも同一のプログラムが走るようにする.
の, 2 点にあります.

In article < 473@cskvax.csk.JUNET> , shige@cskvax.csk.JUNET (Shigeki Yoshida)
write:
>    ええと、不勉強なのでｌｏｎｇ　ｃｈａｒという内部コードは知らない
>  のですが、ＪＡＥで使っているｗｃｈａｒ＿ｔ型と基本的には同じなので
>  しょうか。ちなみにｗｃｈａｒ＿ｔは、
>  	
>  	typedef unsigned short wchar_t;
>  
>  で定義される１６ビットの内部コードで、ＥＵＣ（ＡＴ＆Ｔ）コードの
>  漢字の１バイト目を上位８ビットに、２バイト目を下位８ビットに割当
>  てて、２バイトの漢字を１６ビットのコード１つで表します。
同じです. そのコードを 日本語 UNIX 諮問委員会では long char と呼んでいました.
そして, l は 1 と区別しにくいと言う事情で wchar_t になったと思います.
(しかし, long int のほうが余程紛らわしいはずだと思いますが...)

>  > 入出力のための関数で file code (euc, シフト JIS など) に変換するのです.
>  > (当然, かなや街字もここで吸収してしまう.)
>  > long char は, プログラム内部で使うコードであり, file code とは
>  > 無関係に使えるのではないでしょうか.
>  
>  すると、内部でのコード系は１つで、ファイルとの入出力のたびにコード
>  変換をするという事ですよね。面白い考えだと思いますが、プログラムが
>  重くならないでしょうか？
>  
当然, それだけのオーバーヘッドはかかります.
どれぐらい重くなるかはどれぐらい入出力を行なうかによって違うとおもいますが
測定していないので不明です.

CSK のように 内部コードとして file code を使う方法もありますが,
文字定数および文字列定数が使用できるのなら, それでもよいかもしれません.
ただ, ASCII での is* や to* などにあたるものがたくさん必要になると
思いますが...

>    それからプログラムによっては、内部コードに変換せず、バイト列のま
>  まで十分なもの（やバイト列のままでないと困るもの）もあると思います。
十分なものはまだわかりますが, 困るものというのは, たとえば,
どのようなものでしょうか?

>  そんな時はｆｉｌｅ　ｃｏｄｅを意識しますので、結局ＯＳのコードで十
>  分のような気がするのですが。
そのようなプログラムは従来どうり書けばよいと思います.

In article  kos@shpnar.sharp.JUNET (Toshifumi Kozuki)
writes:
>  内部コードを使うとソースレベルでの互換性ができますが、必要に応じ
>  てコード変換をしなくてはいけない。即ち、プログラマはデータがファ
>  イルコード（unsinged char *)なのか内部コード(unsinged short *)で
>  あるかを意識しておかなくてはいけない。lintで間違いは発見できると
>  思いますがいちいちコード変換をすることは面倒ですね。
それは, 確かにいえますね.
すべて内部コードだけで済めば良いのですがそういかないことも多いし...

この方法には, その他にもいろいろな欠陥が考えられます.
たとえば,

1. ランダム・アクセスがやりにくい.
2. 構造体を一括して入出力することがやりにくい.

などです.
このため, 利用可能な範囲は限定されると思います.

>  ところで、コード変換ライブラリや内部コードライブラリの仕様は統一
>  されているのでしょうか？もし、ＪＡＥの場合、シグマの場合、その他
>  ＳＨＩＦＴＪＩＳ採用の○×の場合と異なっているなら、内部コードを
>  使ってもライブラリの違いによって悩まなくてはいけない。
そのためにも, public domain でソースを流すことが望ましいと
思っているのですが, その前にどの仕様をとるかを決定する必要が
ありそうですね.