[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 2885] Re: Fullset EUC

  こんばんは、川合です。


I.Tak. さんは 2002/01/05 19:27:29 の「[OSASK 2883] Re: Fullset E
UC」で書きました：

>　GL,GRともに1バイト文字という設定ならわかりますが、GLは１バイトでは
>なくマルチバイトなんですよね？　どういう環境を想定するのでしょうか？

  あれ？それをいうならGRじゃないの？？？・・・僕の認識とはGL, GR
の関係が入れ替わって記述されているようだったので、以後すべて入れ
替えて読みました。

>グラフィックキャラクタがマトモに出てくるのは８ビットマシンだけで、
>シフトJISの時代には0x00-0x1f,0x7f,0x80,0xfd-0xffを除いて廃れてしまっ
>たのではありませんか？
>（そもそもEUCでこれを変換するというのがナゾですが）

  うーん、どうなんでしょう。僕は16bit機以降にもグラフィックキャ
ラクターがあるのではないかと思っています。各メーカーがフォントRO
Mの部分に空きパターンを作っておいたとは思えません。・・・そして
そういうキャラクターがあれば使いたくなるのは人情なので、そういう
テキストが存在していたのではないかと思うのです。

  ちなみに全角文字が全く出てこないと分かっているなら、そういうキ
ャラクターセットを使えばいいだけなので、ご指摘の通りEUCルーチン
を呼ぶまでもないでしょう。

>　しかしシフトJISでも部分的には生き残っているわけで、シンプルEUCの
>特権機能としてなら、別に難しくはないとも思います。
>「GLでないなら、GRもC0もC1もみーんなまとめて１バイトコードだ♪」
>という手抜きによって実現可能です。これならシングルシフト後の扱いに
>悩む事はありません。

  おっしゃる通りです。そうですね、これこそSimple-EUCの隠し仕様と
いうことにします。

>>  また、たとえば日本語EUCのシングルシフトでG2が呼び出されたあと
>>に0x80〜0xa0など「来てはいけない」文字が来てしまったとしても、そ
>>こは何事もなかったかのようにbase2を加えるようにして欲しいんです
>　うーむ、やはり何を想定するのかナゾナゾです。シングルシフトを使っ
>て500文字まで使えるようにする１バイト文字環境というのは聞いたこと
>がありません。base0の代わりにbase2を加えるとはそういうことですよね。

  僕も聞いた事はないですが、ありえないとはいえないでしょうし、チ
ェックをサボるだけでいいので（笑）、悪くない案だと思っています。

>　で、結局「文字集合大きさビット」はどこへ行っちゃったんでしょうか？
>完全に忘れられているようなので、optの上位に適当に振ってみますと、
>
>     96^nビット : ^nビット    : 下位１６ビット
>00000   0  1  0 : 01 00 01 00 : 00000000 : 00000011
>rrrrr  G3 G2 G1   G3 G2 G1 G0
>
>私の考えではこんな感じになります。この場合、各文字集合の大きさは
>    G0:94^1  G1:94^2  G2:96^1  G3:94^2
>という指示になります（G2はいわゆるLatin-1かな？）。

  僕の考えでは、^nビットの部分が1バイト指定だと94と96を区別する
必要なく128文字集合なので、問題になりそうなのは96x96だけです（96
x96x96はさすがにないと思います）。そうなると、リザーブしておいた
指定11を割り振ってもいいのではないかと思います。そうすれば上記8b
itはリザーブのまま残せます。

  しかしそうではなくて94文字集合系か96文字集合系なのかを別のbit
に割り当てた方がAPIルーチンを書きやすいということでしたら、ご提
案の通り分けてもいいです。

  僕は文字集合のことを忘れていたのではなくて、

    1バイト ... 128文字集合  （G1の場合シングルシフトの分がある
                               ので126文字集合ですが）
    2バイト ... 94x94文字集合
    3バイト ... 94x94x94文字集合

と勝手に決め付けていただけです。

  それと、チェックはできるだけサボってください。まともにチェック
してありえない組み合わせを検出したとしても、そこから先どうするこ
ともできません。アプリ高速の宿命です。むしろエラーを検出するのが
速度の低下を招いてばかばかしいので、チェックしないでください。

  もしそのせいで例外が発生したとしても悪いのは不適切な引数でAPI
を呼び出したアプリの方です。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/