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

[OSASK 2918] Re: Fullset EUC

  こんにちは、川合です。


I.Tak. さんは 2002/01/12 00:46:54 の「[OSASK 2916] Re: Fullset E
UC」で書きました：

>　それから、GLに94^n集合を呼び出したとき、0x20 0x7f といったコード
>は C0 GL のどちらにも属しません（当然、G0,G1,G2,G3のどれにも入り
>ません。GRでも同じです。GLがASCII以外の文字集合でもスペースを使う
>ためでしょう……ASCII文字集合にスペースは含みません）。

  はい、厳密にはそうであることを僕も知っています。

  そういうややこしいことを引き受けたくなかったので、GLは1バイト
文字に限定したかったのです。そしてスペースはGL側のを使ってほし
いと思っています（GR側のものを使うことも許されていますが、そう
いうエンコードがなされたテキストは存在しない思っています・・・
というか、存在してほしくない、という願望です・・・笑）。

>　だって、シフトJISって美しくないから……（←パイププログラムを
>MS-DOS用に作ってもEUC専用にするやつ）
>　でも光成さんのウェブページのアルゴリズムも試したいのでやっぱり
>いじります（はっきりせえ）。

  そういうことなら、お願いします。

>>  G0 : JISの0x2421〜0x247e(全角ひらがな)
>>  G1 : JISの1面全体
>>  G2 : ASCII
>>  G3 : 半角カタカナ
>　うー、一つ目のJISはエンコードで、二つ目のJISは文字集合だ……

  いや一つ目も文字集合だという事もできます。たとえば、JISの0x242
1〜0x247eと合同な文字集合を僕が定義して、KAW-X-001とかにして登録
すればいいわけですから（笑）。多分受け入れられないでしょうけど。

>>  こういうコードは今のE-EUCやF-EUCルーチンでは扱えませんが（E-EU
>>CやF-EUCでは、1バイト文字は半角、2バイト文字は全角と決め付けてい
>>るため）、まあ本来のEUCのルールには反していないでしょう。
>　使えない、それはそうですが。使いたくなったら、第二段階を縮小し、
>追加する第三段階で x とか x x+1 とか x x+1 x+2 とかいうコードを出力
>させれば達成できます。
>オプションが増えますが、可能性として。

  いや、今のところ使いたいとは思っていません。これは話のたとえで
出しただけなので、こんな存在しないエンコード方式のために、F-EUC
を改造するには及びません。

  本当に短いバイト数で文字を表したいのなら、こういうエンコード方
式に悩む前にtek0などを導入した方がずっと効果的です。

>　それが変に思えるのです。だって「図形文字の左半分」と「図形文字の
>右半分」を表すコードを定義するんですよ？

  そのとおり、変です。・・・変なだけではなく、無駄でもあります。

  僕はこのコードに対応したテキストエディターが出てこないだろうと
思っているのですが、それは全角1文字につき、8バイトも食うからです
。こんなのでテキストファイルを作ったら、ディスクがもったいないで
すよ。それゆえ、これはAPIのやり取りだけに限定された文字コードで
（まあ一種のエンコードといってもいいですが）、基本的にそれ以上の
範囲に拡大応用させる気はありません。

>　ぐいぐいコードで「文字」を書くなら、一文字につき一ダブルワードで
>用が済むはずです。だって、全角文字を表示するために x x+1 というコード
>を使うんですから。x だけで「文字」の識別ができるはずです。

  そのとおりです。異議はありません。

  ただスクロールなどの際に、全角文字の右半分だけとか、左半分だけ
を表示したい時がありまして、これはこれで単純かつ便利な仕様なので
す。それだけです。

>　私がずっと「ぐいぐいコード」と呼び「ぐいぐい文字コード」と呼ば
>ないのは、この表示に直結した冗長性が「文字」コードにふさわしくない
>と思えるからです。もちろん表示用としては問題無いのですが……

  ようするに、I.Tak.さんはぐいぐいの文字コードを、世間で言われて
いるような汎用的な文字コードとして僕が提唱していると思っておられ
たわけですね。それは確かにナンセンスです。僕がI.Tak.さんの立場だ
ったら、僕もI.Tak.さんと同様に異議を唱えたでしょう。

  ということで、汎用的な文字コードではありません。ただのフォント
番号みたいなものです。

>　なるほど、表示ルーチン用ですか。TRONがどうとか出てくるから、
>Unicodeみたいな「文字コード」を定義しているのかとドキドキしてい
>ました(^_^　そう割り切ってあるのなら安心です。

  そう、TRON文字コードがどうのこうのというのは、「これらも表示が
可能になるように、フォントコード空間を割り振る」ということです。

>　そうすると、ぐいぐい00コードはワープロ的ですね。表示に直結する
>以上あたりまえですが。

  ワープロ的な文字コードが「大きさや幅の情報を持っている」という
意味での指摘なら、そう、それは全くのそのとおりです。

>　E-EUCですね。二バイト目は変換結果に大した影響を与えないので、
>ケチっていました(^^;
>　「けっこう簡単に丸められる」ということはF-EUCで分かると思ったので。

  ・・・あ、本当ですね。

  これですが、ちょっと考えてもっと簡単そうな方法を見付けました。
ちなみに、2バイト目限定ですが。

  「0x7fでマスクしてから、0x21を引く」代わりに、「0x21を引いてか
ら0x7fでマスクする」というものです。

  こうすれば、前に戻ってしまう心配はありません。後ろに34文字の保
証が必要ですが、これは満たされます。94x94の後ろに全角80文字くら
いの存在を仮定してかまいません。

  これで、CMP, SBB, ANDの3つを省略できます。


  それでは。

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