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 諮問委員会
> で提唱した内部コードをつかうのはどうでしょうか?

  ええと、不勉強なのでｌｏｎｇ　ｃｈａｒという内部コードは知らない
のですが、ＪＡＥで使っているｗｃｈａｒ＿ｔ型と基本的には同じなので
しょうか。ちなみにｗｃｈａｒ＿ｔは、
	
	typedef unsigned short wchar_t;

で定義される１６ビットの内部コードで、ＥＵＣ（ＡＴ＆Ｔ）コードの
漢字の１バイト目を上位８ビットに、２バイト目を下位８ビットに割当
てて、２バイトの漢字を１６ビットのコード１つで表します。（ＣＳＫ
の日本語ＵＮＩＸ［ＳＪＩＳ版もＥＵＣ版も］もこの方法を使っています）

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

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

  それからプログラムによっては、内部コードに変換せず、バイト列のま
まで十分なもの（やバイト列のままでないと困るもの）もあると思います。
そんな時はｆｉｌｅ　ｃｏｄｅを意識しますので、結局ＯＳのコードで十
分のような気がするのですが。
-- 
（株）ＣＳＫ・技術開発事業本部・商品開発部・吉田茂樹
					    shige@csk.JUNET