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

[OSASK 2912] Re: Fullset EUC

  こんばんは、川合です。


I.Tak. さんは 2002/01/11 18:15:50 の「[OSASK 2910] Re: Fullset E
UC」で書きました：

>>  まず、シングルシフトはGLにこなきゃいけないってことになっていま
>>すが、守っていないテキストもあるかもしれないから0x7fでマスクして
>>0x00とみなします。そしてbase2を加えます。
>　それは多分古い資料です。今はGLでもGRでもいいことになっています。
>日本語EUCがG2のカナを使うのに SS2+GR を使ってしまったため、そう
>変えたんだそうです。

  なるほど。

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

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

>　シングルシフト後の割り当ては、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の判断は必要
>だと思ったのです。

  いや、そこまで厳密にやることはないでしょう。常に96文字集合だと
思うことにしてください。そしてC0やC1やDELもコントロールコードで
はなくすべて表示用の文字だと思っていいです。

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

>>>	/* ↑POPが増えるからcallにしようよ */
>>  これはどういう意味なんでしょうか？
>　各ルーチンに jmp すると、ルーチンの終わりにpopが並びますよね。
>……ってpopは短いからいいのか。

  なるほど。それなら、処理が済んだらPOPの固まりのところへgotoす
るというのはどうでしょうか？

>>>/* シフトJIS変換はいじらないので省く */
>>  これをいじれば、レジスタのやり取りがスムーズになりそうですね。
>　うっ。やってねってことですか？　こうして使ってはいますが、
>シフトJISは自分で扱う気にはちょっとなりません。

  そうとう嫌っていますねえ・・・いいですよ（笑）。じゃあ、僕が直
しますから、SJISのことを気にしないでレジスタを使うようにしてくだ
さい。そのルーチンに合わせて僕がSJIS側を直します。

>>  それと、if文で不等号を使う場合は、できるだけ(signed), (unsigne
>>d)を指定してあげてください。ASKAが混乱します。
>　えっ、長いからいやなんですけど(^_^;;　マクロか……

  長いから嫌？それはそれでごもっともなご意見です。・・・それなら
、94を(unsigned)な定数であると明記すればいいでしょう。C言語のル
ールでは、末尾にUをつければいいことになっています。つまり、

    if (al < 94U) {

にすればいいわけです。・・・が、多分今のバージョンのASKAはこれを
解釈できないでしょう。いいです、I.Tak.さんは正式ASKAの文法で書い
てください。僕が組み込む時に直します（笑）。

>ところで、キャストは94に付けてもいいんですか？
>#define above >(unsigned) とか書きたいので。

  キャストは94につけてもいいです。

  このマクロを使うと、

    if (al above 94) {

ってなるんですか？・・・うーん、これは僕が嫌だなあ（笑）。せめて、

#define is_above >(unsigned)

にしませんか？（笑）。3文字ほど長くなりますが。

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

  ん？それは誤解です。僕はエンコード方式は気にしていません。

  もし2000JISを94x94x94でエンコード（最初の文字は面を表す。0x21
が1面、0x22が2面）した場合、それでも漢字は半角2個で表示させます
。

  僕は1バイト文字だから半角で書いているというわけではありません
。たとえば、こういうエンコード方法（仮にEUC-川合と呼ぶことにする
）があったとしましょう。

  G0 : JISの0x2421〜0x247e(全角ひらがな)
  G1 : JISの1面全体
  G2 : ASCII
  G3 : 半角カタカナ

  このエンコード方式のいいところは、普通の日本語の文章のある程度
の割合を占める全角ひらがなが1バイトで書けるということです（この
用途に限れば、シフトJISより優れています）。その代わりプログラム
ソースなど、ASCIIキャラクターがメインの文章ではバイト数がかさみ
ますが。

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

  そしてこのEUC-川合で

    0x22 0x24 0x26 0x28 0x2a

という5バイトの文字列があった場合、これは「あいうえお」という5文
字ですが、これは僕の数え方で「10文字」です。

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

  そしてファンクション0xecはこの簡易文字表示ルーチンのためのコン
バーターなのです。汎用的なデコーダーではありません。
  
  僕はOSASKの表示的な文字数とエンコードした時のバイト数が同じで
あるべきだとは思っていません。I.Tak.さんはシフトJISのことがあっ
たせいで、僕を誤解しているのではないでしょうか？・・・シフトJIS
やE-EUCではたまたまそうであったというだけです。そしてその場合に
限って僕が楽をしてルーチンを書いたというだけです（楽をしたとい
うほどの差があるわけではないと思いますが）。

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

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

  そしてこれが、

    0xa4 0xa2 (日本語EUC)
    0x82 0xa0 (シフトJIS)
    0x21 0x24 0x22 (94x94x94)
    0x22      (EUC-川合)

のどれでエンコードされていようとも、意味するところは同じで、どれ
も2文字なのです。一番最後の例はF-EUCではサポートしていませんが。

（不正データ対策）
>>  しかしAPI仕様としてはこの実装をあてにしてもよいとは言えないで
>>しょう。そうなると、利用者は利用をためらいます。結局使われないか
>>もしれません（この話は、Easy EUCの川合仕様の部分も同じです）。
>　それは、tviewc05のソースをちらっと見て、「面倒くさそうだから
>データ丸投げに耐える変換をさせよう」と思ったからです。

  そう、その意図は気がついていました。そしてその意図を達成すると
いう観点では、あのコードは実に良くできています。賞賛に値します。

>>  Easy EUCの川合仕様は、これに伴うコードの増加がほとんどないので
>>（94との比較もなくしてしまうべきでしょう。それでも0x80〜0xa0は使
>>えますし・・・0xffだけなら使えなくてもいいです）。
>　あれっ、0xffは要らないんですか。この間（OSASK 2870）と違います。
>ここが94/96文字集合で違うのでかなり悩んだんですよ。

  すみません、確かに入れてほしいと書きました。

  しかし、それは処理が増えない範囲での話です。つまり、処理をけち
って達成できるなら達成したいが、コードが増えるなら、うーん、どう
しようかなあとためらうわけです。今でも入れてもいいような気もする
んですが、もしかしたら誰も一度も使わないかもしれない気もしていて
、それが実に悩ましいのです・・・。

  僕の優柔不断のせいで、I.Tak.さんまで悩ませてしまってすみません
。

[OSASK 2870]より
>  まあでもこんな細かい仕様を設定しなくても、この手のテキストはア
>プリが自分で変換するってことにしてもいいような気もしますね。マイ
>ナーなものは自分でやれと（そんなに大変じゃないんだし）。・・・と
>いうことで、上記仕様のうち面倒なものは実装しないでいいです。

  この「上記仕様のうち面倒なものは実装しないでいい」という記述で
、今回の0xffのようなものは入れなくていいですよって言ったつもりに
なっていました。誤解されるようなことを書いてしまってすみません。

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

  なるほど！・・・つまりエラーコードは返しても、それはWarningな
んですね。処理はとりあえず続行できる、と。・・・これは名案です。
そんなエラーコード、考えたこともありませんでした。

  うん、じゃあ、これで行きましょう。そうすれば、tviewc05では丸な
げができます。不正文字処理を厳密にやりたい人は、アプリ側でコンバ
ートしなさい、ということで。

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

>>  もともと、ファンクション0xecは、固定的なメッセージの変換（＝つ
>>まり事前に内容が分かっているもの）を想定していました。もしデータ
>　OSASKエディタができて、ぐいぐいコードを直接書けるようになったら
>お蔵入りのファンクションになりそうな。(^_^

  それはそうかもしれませんが、でもあのコードは長いです。10文字書
けば40バイトですからねえ・・・。いくらtek0があるとは言っても、余
計な冗長さがはじめから少ない方が圧縮利率も良くなるでしょうから、
使われ続けるかもしれません。・・・まあ、tek0よりももっとかしこい
エンコード方法が見付かれば、ファンクション0xecは確かに誰も使わな
くなるかもしれませんが。

  でも、データーの変換にも対応するということなら、ぐいぐい01仕様
になっても生き残れそうです。まあ、生き残らせることがそんなに重要
というわけではないんですが（笑）。・・・この世にEUC文字コードの
テキストファイルがある限り。

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

  この「不正なデータに正しい変換結果はありません」という言葉は、
気に入りました。かっこいいです。

  そしてもちろん、「未定義である以上勝手に処置してよい」という意
見にも賛成です。


  それでは。

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