No. 112/622 Index Prev Next
Path: titcca!ccut!ascgw!cskvax!shige
From: shige@cskvax.csk.JUNET (Shigeki Yoshida)
Newsgroups: fj.kanji
Subject: Re: EUC &  SJIS &  JIS (Re: Hankaku KANA) (In KANJI)
Message-ID: < 473@cskvax.csk.JUNET> 
Date: 7 Jul 87 09:47:44 GMT
References: < 468@cskvax.csk.JUNET>  < 783@srava.sra.JUNET> 
Reply-To: shige@cskvax.csk.JUNET (Shigeki Yoshida)
Distribution: fj
Organization: CSK corp., Tokyo, Japan
Lines: 32
Posted: Tue Jul  7 18:47:44 1987

article < 783@srava.sra.JUNET>  で
	kameyama@srava.sra.JUNET (亀山豊久) さんが
> 日本語のソフトを作るときに, 内部コードとして long char (日本語 UNIX 諮問委員会
> で提唱した内部コードをつかうのはどうでしょうか?

  ええと、不勉強なのでlong charという内部コードは知らない
のですが、JAEで使っているwchar_t型と基本的には同じなので
しょうか。ちなみにwchar_tは、
	
	typedef unsigned short wchar_t;

で定義される16ビットの内部コードで、EUC(AT&T)コードの
漢字の1バイト目を上位8ビットに、2バイト目を下位8ビットに割当
てて、2バイトの漢字を16ビットのコード1つで表します。(CSK
の日本語UNIX[SJIS版もEUC版も]もこの方法を使っています)

> そして, 入出力のための関数で file code (euc, シフト JIS など) に変換するのです.
> (当然, かなや街字もここで吸収してしまう.)
> long char は, プログラム内部で使うコードであり, file code とは
> 無関係に使えるのではないでしょうか.

すると、内部でのコード系は1つで、ファイルとの入出力のたびにコード
変換をするという事ですよね。面白い考えだと思いますが、プログラムが
重くならないでしょうか?

  それからプログラムによっては、内部コードに変換せず、バイト列のま
まで十分なもの(やバイト列のままでないと困るもの)もあると思います。
そんな時はfile codeを意識しますので、結局OSのコードで十
分のような気がするのですが。
-- 
(株)CSK・技術開発事業本部・商品開発部・吉田茂樹
					    shige@csk.JUNET
Next
Continue < 768@shpnar.sharp.JUNET>
< 820@srava.sra.JUNET>
< 799@shpnar.sharp.JUNET>