[OSASK 2909] Re: Fullset EUC

[Hidemi KAWAI <kawai !Atmark! imasy.org>]

  こんにちは、川合です。


I.Tak. さんは 2002/01/10 19:55:21 の「[OSASK 2908] Re: Fullset E
UC」で書きました：

>>  また、たとえば日本語EUCのシングルシフトでG2が呼び出されたあと
>>に0x80〜0xa0など「来てはいけない」文字が来てしまったとしても、そ
>>こは何事もなかったかのようにbase2を加えるようにして欲しいんです
>　書いてて気付いたんですが、それってG2が1バイト文字の場合ですよね。

  そうです。

>マルチバイト文字の時は……？

  その時は、エラーです（＝検出しない場合は、暴走でもいいです）。

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

  SS2っていうのは・・・ええと、シングルシフトG2呼び出しですね。

  僕ならこう解釈します。

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

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

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

>　お待たせしました。疑問を残しつつ、ついにできました。
>その名も Fundamental EUC converter、基本という意味です。
>従来のもいじるついでに Easy EUC converter に改名しました。
>E-EUCの次がF-EUCでビンゴ！
>http://home1.catvmics.ne.jp/~msy/tak/garage/euc2gg.lzh

  さっそく読んでみました。いつものことですが、ソースにレスです。

>	/* ↑POPが増えるからcallにしようよ */

  これはどういう意味なんでしょうか？

>/* シフトJIS変換はいじらないので省く */

  これをいじれば、レジスタのやり取りがスムーズになりそうですね。

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

  たとえば、

>    if (al < 94) {

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

    if ((unsigned) al < 94) {

と書くのが良い記述です。

>    if(ah<=1){

  この記述も同様です。

>    ecx = cmd[28 + ecx*2];    /* base */
>    TEST(dl,[DS:ESI+4+2]);    /* opt */

  この2文は、問題ありです。というのは、DS:ESIがcmdの先頭を指して
いることを前提にしているからです。・・・これは、あまり期待できま
せん。というのは、DSは32行目で変更されうるからです（変更されない
と分かっていたら、PUSH(DS);なんてやりませんよ）。ですから、ソー
ステキストの読み込みポインタを、たとえばFS:EBXにするとか、そうい
う工夫が必要です。

>    ECX = cmd[ 8];    /* len */

  これですが、I.Tak.さんのmode0003のコードでは、srcのバイト数と
して解釈しているように見えます。僕としては、「出力する文字数」と
して解釈して欲しいんですが・・・。たとえば半角カタカナは、ソース
上では2バイトですが、1文字と数えます。全角文字1字は、OSASKにとっ
ては2文字です。・・・こうすればいいでしょう。

    EBP = EDI + ECX * 4; /* LEAでやれば1命令でできる */

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

>　データ用の対策もしてある。データの正当性をアプリでいちいち確認
>すると速度の低下を招くし，変換と同じ手間がかかってしまうからだ。

  これは、うーん、考えさせられました。

  この実装は確かに親切で賞賛に値します。

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

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

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

  もともと、ファンクション0xecは、固定的なメッセージの変換（＝つ
まり事前に内容が分かっているもの）を想定していました。もしデータ
ーなどをやり取りすることを想定していれば、不法な文字に対する応対
（たとえばどんな文字に置き換えるのかとか、もしくは読み飛ばすのか
とか、複数バイト文字の場合、2バイトをまとめて不法とするのか、1バ
イトのみ不法とするのか・・・など）を事細かに規定しなければいけな
いでしょう。それは非常に複雑になるし、それならアプリ側が自前の変
換ルーチンを持っていた方がいいと思ったので、これを想定しないこと
にしたんです（そのくせtviewc05では使っていたりするんですが・・・
笑）。

  もちろん、仕様以上に実装するのはかまいません。コードがちょっと
長くなる以上のトラブルはありませんから。

  僕自身、どうあるべきか決めかねています。I.Tak.さんの意見を聞か
せてください。


  それでは。

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