[OSASK 2910] Re: Fullset EUC

["I.Tak." <msy !Atmark! catvmics.ne.jp>]

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

Fri, 11 Jan 2002 00:56:46 -0000 の
[OSASK 2909] Re: Fullset EUC
に返信です。

>>　そしてG2が1バイト文字のときさらに SS2 0x80 みたいなコードが来たら
>>どうしたらいいんでしょう？　ここの 0x80 はGRなんでしょうか？使用
>>禁止領域なんでしょうか？　こういうことを企むときに、94 or 96 が
>>分からないと困ります。SS後のGRはGLに移さないといけないのです。

　ぐお、間違えました。0x80ではなく、0xa0です。

>  まず、シングルシフトはGLにこなきゃいけないってことになっていま
>すが、守っていないテキストもあるかもしれないから0x7fでマスクして
>0x00とみなします。そしてbase2を加えます。

　それは多分古い資料です。今はGLでもGRでもいいことになっています。
日本語EUCがG2のカナを使うのに SS2+GR を使ってしまったため、そう
変えたんだそうです。

>  もちろん、ここはSS2を無視してGRとみなすべきだという主張がある
>かもしれませんが、僕はそれを支持しません。もしそういう意図でテキ
>ストが書かれているのだとしたらそもそもSS2を挿入する意味がありま
>せん。無視されるためにSS2を入れたのだとしたら、このテキストを生
>成したエンコーダーはかなり変です。僕はそう思うからこそ、0x7fでマ
>スクするわけです。

　シングルシフトを使うと、0x8eと0x8fのグラフィックキャラが使えなく
なります。そこで、0x8e 0x8e として、0x8eのグラフィックキャラを出そう
とすることも（川合秀実仕様では）ありえると思いました。なにしろ、C0と
C1はシフトされません……いや、未定義か禁止でしょうが。

>  僕の方針は以上のとおりなのですが、94/96の区別が必要だというI.T
>ak.さんの主張が実はよく分かりません。仮に、94だとしたらどういう
>処理になるんですか？そして96だとしたらどういう処理になるんですか
>？どこが違うんですか？・・・この場合、どちらにしても0x80は範囲外
>のように思うのですが・・・。

　シングルシフト後の割り当ては、94文字集合ではこうなります。
    0x00-0x1f:C0
    0x20     :space
    0x21-0x7e:GL(=GR)
    0x7f     :DEL
    0x80-0x9f:C1
    0xa0     :invalid
    0xa1-0xfe:GR(=GL)
    0xff     :invalid
これに対して、96文字集合では invalid の二バイトはGR(=GL)に吸収され
て無くなります（0x80はよくやってしまう勘違いですm(_ _)m）。それで、
invalidをグラフィックキャラとして扱いたい場合、94/96の判断は必要
だと思ったのです。

>>	/* ↑POPが増えるからcallにしようよ */
>  これはどういう意味なんでしょうか？

　各ルーチンに jmp すると、ルーチンの終わりにpopが並びますよね。
……ってpopは短いからいいのか。

>>/* シフトJIS変換はいじらないので省く */
>  これをいじれば、レジスタのやり取りがスムーズになりそうですね。

　うっ。やってねってことですか？　こうして使ってはいますが、
シフトJISは自分で扱う気にはちょっとなりません。

>  それと、if文で不等号を使う場合は、できるだけ(signed), (unsigne
>d)を指定してあげてください。ASKAが混乱します。

　えっ、長いからいやなんですけど(^_^;;　マクロか……

>>    if (al < 94) {
>という文は、alがunsignedで、94がsignedな定数ですから、ASKAはどう
>したものかと悩みます（これはASKAが好きな方に勝手に決めていいこと
>になっています）。こういう時は、

　ええっ、あぁ、32ビットレジスタとの兼ね合いでしょうか。＞実装
ところで、キャストは94に付けてもいいんですか？
#define above >(unsigned) とか書きたいので。

>として、EBPとEDIを比較しながらループを続けるわけです。・・・この
>こだわりは、バイト数よりも文字数の方が「より本質的である」と僕が
>信じているからです。内容が同じなら文字数はエンコード方式によらず
>不変ですが、バイト数はエンコード方式によって変わります。コンバー
>ターとしてはソースのバイト数を指定するよりも、コンバート前後で不
>変な量を指定する方が仕様として美しいと思ったわけです。

　本質的文字数と言うなら、半角と全角は表示上の問題であって、文字
としては同じです。１バイト文字を必ず半角で表示するという慣例は
けっこうですが、せめてオプションにしてください。まさか、94^3文字を
1.5倍角で表示するつもりですか？（まだ無いけど）

「そうです」と言われると怖いなあ……

（不正データ対策）
>  しかしAPI仕様としてはこの実装をあてにしてもよいとは言えないで
>しょう。そうなると、利用者は利用をためらいます。結局使われないか
>もしれません（この話は、Easy EUCの川合仕様の部分も同じです）。

　それは、tviewc05のソースをちらっと見て、「面倒くさそうだから
データ丸投げに耐える変換をさせよう」と思ったからです。

>  Easy EUCの川合仕様は、これに伴うコードの増加がほとんどないので
>（94との比較もなくしてしまうべきでしょう。それでも0x80〜0xa0は使
>えますし・・・0xffだけなら使えなくてもいいです）。

　あれっ、0xffは要らないんですか。この間（OSASK 2870）と違います。
ここが94/96文字集合で違うのでかなり悩んだんですよ。

>  それとも不用意なデーターが来た場合でも落ちないというのを仕様に
>しますか？これを仕様にするとなると、アプリ安全では不法なコードを
>検出してはいけないということになります（＝エラーにできない）。

　とりあえず変換するが結果は保証できないのでエラーを返す、という
のでいいと思います。

>  もともと、ファンクション0xecは、固定的なメッセージの変換（＝つ
>まり事前に内容が分かっているもの）を想定していました。もしデータ

　OSASKエディタができて、ぐいぐいコードを直接書けるようになったら
お蔵入りのファンクションになりそうな。(^_^

>ーなどをやり取りすることを想定していれば、不法な文字に対する応対
>イトのみ不法とするのか・・・など）を事細かに規定しなければいけな
>いでしょう。それは非常に複雑になるし、それならアプリ側が自前の変
>換ルーチンを持っていた方がいいと思ったので、これを想定しないこと
>にしたんです（そのくせtviewc05では使っていたりするんですが・・・
>笑）。

　上にも書いたように、未定義である以上勝手に処置してよいと思います
（ASKAと同じです）。不正なデータに正しい変換結果はありません。

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