こんばんは、川合です。
I.Tak. さんは 2002/10/28 12:14:56 の「[OSASK 5232] Re: 文字のエ
ンコード」で書きました：
>> UTF-8 ： 128 + 2048 + 65536 = 67712
>> （とりあえずややこしいサロゲートを使わないと仮定）
>
> UTF-8の2バイト、3バイトコードというのは0x0080以降と0x0800以降に
>なっているらしいので、UTF-8でも文字数は65536までですよ。
なんと！・・・それはまあ計算がやりやすそうだけど、なおさらエン
コード可能な文字コードが減るなあ。
> UTF-8のエンコードが良いのは分かりましたけど、UnicodeはCJKを統合
>しているのでちょっとまずいことになります。中国語と日本語を混ぜると
>日本語を簡体字で書くか中国語を日本漢字で書かないといけません。
>本当に国際化しているか微妙で、私は地域化ではないかと思っています
>(したがってUnicodeは好きになれない)。文字集合の話ですが(^^;;
この問題は僕も知っています。そう、僕も同じ理由でUnicodeは嫌い
です。っていうか超漢字の10万文字を収めうるような文字コードでない
と、超漢字を超えられる可能性はなくなるので、その点からも文字コー
ドとしてのUnicodeは嫌いです。僕が好きなのは、UTF-8のエンコードの
ポリシーだけです。まあ、SKEの方がもっと好きですが（笑）。
> 気の早い話ですが、実際にSKEを使うとなると文字集合をどうするかが
>問題になりますね。
そうです。SKEはただの汎用エンコードアルゴリズムなので、実際の
文字コードについてはなにも決めていません。このままでは使えません
。どうしましょうねえ。僕としては、あまり良い案を持っていません。
先日、ちょっとだけ考えた案としては、OSASKのフォントコードをそ
のまま使ってしまえ、というのがありました。ただ、ご存知のとおり、
OSASKのコードでは全角文字が右半分と左半分に分かれています。そう
すると全角文字1文字は8バイトにもなるでしょう。これはなかなかに悲
惨です。サイズについてはtek0があるから心配しなくていいとはいって
も、うーんとうなりたくなります。でもこれはOSASKフォントコードに
おける単純32bitとくらべると、別に増えも減りもしていないともいえ
ます。
これを克服するには、文字コードとしては左側のコードのみを利用し
、表示用文字列(単純32bit)に展開するときは左側が検出された時点で
右側のコードも出力するという方法が考えられますが、なんか単純じゃ
ない気がするんですよね・・・（どのコードが全角か半角なのかを判定
しなきゃいけませんし）。左右のコードが別々に存在するというのは情
けないかもしれませんが、結果的に文字を全角として表示するという観
点では単純明快です。
とにかく僕は決め手になるような案を持っていません。だからこの件
については何も提案できません。とりあえず今はエンコード方式だけで
す。
>> gccの移植に当たっては、SKEに特化して移植するつもりはありません
>> が、SKEでもすんなり通るようにしたいです。シフトJISには配慮しない
>
> 普通EUCを飛ばす処理を書けばUTF-8もSKEも難なく飛ばせるから大丈夫
>でしょうね。iso-2022のエスケープを考えると(コンパウンドテキストとか)
>途端に面倒になると思います。
> 元のままでもSKEは通るはずですし、もしかしたらそっとしておいたほう
>がいいんじゃないかと(^^;
なるほど。それはなおさら好都合です。というか、この話題はgccの
移植改造に際して、シフトJISをフォローするようなコードは一切入れ
ないという宣言みたいなものです。シフトJISをフォローしたい人は、
僕の方針にかまうことなく、独自に独立してやってもらうことにします
。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/