No. 131/622 Index Prev Next
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: < 856@srava.sra.JUNET> 
Date: 6 Aug 87 10:53:04 GMT
References: < 768@shpnar.sharp.JUNET>  < 820@srava.sra.JUNET>  < 509@cskvax.csk.JUNET>  
Reply-To: kameyama@srava.UUCP (Toyohisa Kameyama)
Distribution: fj
Organization: Software Research Associates, Inc., Japan
Lines: 74

亀山です.
In article  kos@shpnar.sharp.JUNET (Toshifumi Kozuki)
write:
> どのような仕様のコード変換ライブラリや内部コードライブラリがすで
> に存在しているのか知りませんが、誰かご存じでしたらポストして欲し
> いですね。
私の知っている限りでは以下のようなものがあります.
間違っていたら follow してください.
1. 日本語 UNIX 諮問委員会
    処理コードの type
	long char (16 bit)
    ライブラリ
	ASCII のものに l をつけたもの
	    lstrlen, getlc, getls など
    
    この仕様で, NEC, 東芝 (AS-3000, 但し入出力用の関数なし) などが
    実現しています.

2. AT& T の仕様
    処理コードの type
	typedef unsigned short int wchar_t;
    ライブラリ
	ASCII のものに w をつけたもの
	    wstrlen, getwc, getws など
3. ANSI 案
    処理コードの type
	letter_t
    残念ながら詳しいことは分かりません.

4. CSK の JNIX (内部 16 形式)
    処理コードの type
	typedef unsigned short int kanzi;
	(file コードを 1 文字 16 bit にしたもの)
    ライブラリ
	ASCII のものに k をつけたもの
	    kstrlen, kgetc, kgets など

> 仕様に対して個人的意見を述べることはできると思いますが、
> 立場上、public domainのソースを作ったり出来ないのが残念です。
私も実際に何処までやれるかはわかりませんが...

In article < 509@cskvax.csk.JUNET>  shige@cskvax.csk.JUNET (Shigeki Yoshida)
write:
>   ただ、実際のプログラミングの上で、かえって面倒になるような
> 事があっては困ると思ったのです。
それは基本的に賛成です.

>  例えば、自分の使っているOSコードの日本語プログラムだけを
> 書くつもりのプログラマーにとっては、OSコードと内部コードの
> 違いは間違いの元でしかありません。
一番いいのはコードを全く意識しないですむことだと思います.
提案では安易に内部コードの統一と言ってしまいましたが,
他の方法も考えられます.
内部コードというとアルファベットの場合は ASCII と EBCDIC が代表的でしょう.
それから考えると, 文字定数, 文字列定数および ``ctype''
みたいな内部コードを意識しないですむ仕掛けが使えればいいのかも知れません.
(しかし, ``ctype'' のような関数 (文字種の判定, 変換) がどれくらいあれば
いいのだろうか?)

> > 1. ランダム・アクセスがやりにくい.
> > 2. 構造体を一括して入出力することがやりにくい.
> これも確かに問題です。read(),write()を使うような
> プログラムは一切書けなくなります。
極論を言うと, read/write を使うようなファイルはそのプログラム以外で
読める必要があるのでしょうか?
binary としてなら内部コードを直接入れるやり方もあります.
または, read/write の直前に 1 byte 文字列 (char *) に
直すという方法も考えられます.
実際に日本語を処理するときは 1 文字単位で扱ったほうがはるかに
楽だと思うのですが...
Next
Continue < 518@cskvax.csk.JUNET>
< 881@srava.sra.JUNET>