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

[OSASK 2916] Re: Fullset EUC



Hidemi KAWAI さん、こんにちは。I.Tak. です。

Fri, 11 Jan 2002 13:26:45 -0000 の
[OSASK 2912] Re: Fullset EUC
に返信です。

>  はい、0x8e 0x8eはありうるでしょう。その場合後ろの0x8eは0x7fで
>マスクされて0x0eになって、それでbase2を加える、ということでよい
>かと。シングルシフトを2度並べる意味は特にないわけですし。

 ということは、SS2やSS3の後のバイトも常に&=0x7fしていいんですね!
ああ助かった(^o^

>  そして0x8e 0x20なんていうコードがspaceのために使われるというこ
>とは僕には信じられないので、0x8eに続く0x20はG0のコードではなく、
>G2のコードです。

 ええと、定義では、シフトされるのは図形文字(グリフ)領域だけの
はずです。でも確かに、存在は信じられませんね。

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

>>>>/* シフトJIS変換はいじらないので省く */
>>>  これをいじれば、レジスタのやり取りがスムーズになりそうですね。
>> うっ。やってねってことですか? こうして使ってはいますが、
>>シフトJISは自分で扱う気にはちょっとなりません。
>  そうとう嫌っていますねえ・・・いいですよ(笑)。じゃあ、僕が直
>しますから、SJISのことを気にしないでレジスタを使うようにしてくだ
>さい。そのルーチンに合わせて僕がSJIS側を直します。

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

>  僕は1バイト文字だから半角で書いているというわけではありません
>。たとえば、こういうエンコード方法(仮にEUC-川合と呼ぶことにする
>)があったとしましょう。
>  G0 : JISの0x2421〜0x247e(全角ひらがな)
>  G1 : JISの1面全体
>  G2 : ASCII
>  G3 : 半角カタカナ

 うー、一つ目のJISはエンコードで、二つ目のJISは文字集合だ……

>  こういうコードは今のE-EUCやF-EUCルーチンでは扱えませんが(E-EU
>CやF-EUCでは、1バイト文字は半角、2バイト文字は全角と決め付けてい
>るため)、まあ本来のEUCのルールには反していないでしょう。

 使えない、それはそうですが。使いたくなったら、第二段階を縮小し、
追加する第三段階で x とか x x+1 とか x x+1 x+2 とかいうコードを出力
させれば達成できます。
オプションが増えますが、可能性として。

>  I.Tak.さんは全角/半角を「表示上の問題」と言われていますが、僕
>にとっては非常に本質的な違いです。OSASKの簡易文字表示ルーチンで
>は、半角以外の文字を理解しません。必ず固定ピッチで、半角1文字は
>厳密に4バイトです。OSASKのルーチンは、どんな全角文字列であろうと
>それは2倍の文字数の半角文字列を表示したつもりでいます。

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

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

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

>  そしてファンクション0xecはこの簡易文字表示ルーチンのためのコン
>バーターなのです。汎用的なデコーダーではありません。

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

>  僕はOSASKの表示的な文字数とエンコードした時のバイト数が同じで
>あるべきだとは思っていません。I.Tak.さんはシフトJISのことがあっ
>たせいで、僕を誤解しているのではないでしょうか?・・・シフトJIS
>やE-EUCではたまたまそうであったというだけです。そしてその場合に

 シフトJISというより、ぐいぐいコードのせいでした。あれが文字コード
と呼ばれていたから……

>  もし将来、2倍全角や1.5倍全角文字というものが出てきたら、それは
>OSASKの簡易表示ルーチンにおいては、半角4文字や半角3文字として表
>現され、それは4文字、3文字と数えるでしょう。しかしそれらの文字が
>元の文字列の中で何バイトにエンコードされているかはどうでもいいこ
>とです。

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

>  I.Tak.さんにとって、0x2422という文字は、サイズの無いただの「あ
>」なんでしょう。しかし僕にとっては、0x2422という文字は「(全角の)
>あ」なんです。世間が0x2422を全角で表示するべきものだと期待してい
>るので。

 そうです。「情報交換用符号」「文字を表す」と考え、大きさや幅の
情報を持っているとは考えません(それはワープロや組版システムの
仕事です)。そして、この蓋茨窓のエディタを見ても
    『JIS X 0208を』全角で表示するという暗黙の了解がある。
と見ています。

 まあ、ぐいぐいコードは文字コードではないと分かった以上、もう
気にしないと思います。


>  なお94x94の文字集合で、2バイト目を0x7fでマスクしたあと0x21〜0x
>7eに納まっていることをチェックしていませんが、0x21の方はチェック
>して欲しいです。0xa1 0x00とかが来るとbaseよりも前になってしまう
>ことがありえて、これは場合によっては落ちてしまいます。0x7fが来て
>しまうかもしれないのはかまいません。94x94の後ろに全角1文字くらい
>の余裕はありますから。

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

------------------------------------------------------------
I.Tak. <msy !Atmark! catvmics.ne.jp>
http://home1.catvmics.ne.jp/~msy/takhome.htm