アカウント名:
パスワード:
非ヨーロッパ言語系の人々から見ればかなり独善的なことをばしばし言う人ですが、なぜか、けっこう大きな発言力を持っているみたいです。
が、BiDi に関しての、実装は、BiDi に関するターミナルの動作をきちっと定義してからにしろ [xfree86.org]という意見は、まともな意見に思えます。mlterm [sourceforge.net] は「便利だったらいいや」というノリなので FriBidi を使った BiDi サポートを実装しましたが、BiDi に関しては
ユーザインターフェース的には、文字単位の処理になっていることが必要です。というのは、Shift_JIS や EUC-JP では全角文字についてもバイト数とカラム数が一致していたので、Backspace キーを 2 回押すことでなんとかごまかしが効きましたが、UTF-8 ではそれは
まあ、ふつうは ASCII + JIS X 0208 しか使わないということで。
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね? もちろん、JIS X 0201 カナや JIS X 0212 補助漢字は 2 / 3 バイトと数える人が殆どでしょうし、実際そのように考えた方が便利だからこそ eucJP が使われるわけですが。
ところで
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケ ンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね?
その通りかもしれませんが、いまは、Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、それが正しく実現できさえすれば、どちらの考えに立っても構いません。
ところで、こういう用途って UTF-8 (というよりも ISO-10646 そのもの) はあんまり向いてないんじゃないですかね?下手にきちんと扱い得る潜在能力があるだけに、却って泥沼化しそうな気がするんですけど。
なにが「下手」なのか、「泥沼化」とは具体的にどういうことかが分からないのですが、EUC-JP や Shift_JIS においては偶然バイト数とカラム数が (JIS X 0208 について) 一致するという幸運に恵まれてきたわけですが、そういう幸運に頼ることのできない言語があり (タイ語など; 0 カラムの文字がありますが、それらを 0 バイトにすることはできません)、どうせ「きちんと扱」う必要が出てきます。
全角文字をどうするか、BiDiをどうするか、とかいってなかなかモデルが決まらな いことがまさに「泥沼化」なのでは。
なるほど。そうですね。
が、これは Unicode のせいではありません。現実に使われている文字が (全角はさておき) BiDi であったり結合文字であったりするので、 Unicode を使おうと、ISO-2022 や TRON コードなど別の文字コードを使おうと、 文字コードの側でそれをなかったことにすることはできません。
まあ、全部いっぺんにつめこむ「だけ」なら、できると思います。 問題は、各々の言語圏で従来まで使われてきた慣例どうしの擦り合わせでしょう。 誰がどこまで妥協すべきか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
BiDi (スコア:5, 参考になる)
非ヨーロッパ言語系の人々から見ればかなり独善的なことをばしばし言う人ですが、なぜか、けっこう大きな発言力を持っているみたいです。
が、BiDi に関しての、実装は、BiDi に関するターミナルの動作をきちっと定義してからにしろ [xfree86.org]という意見は、まともな意見に思えます。mlterm [sourceforge.net] は「便利だったらいいや」というノリなので FriBidi を使った BiDi サポートを実装しましたが、BiDi に関しては
Re:BiDi (スコア:1)
全角文字は 1文字で 2セル分なので、バックスペースで
1文字消した後 1セルしかカーソルが戻らないと半文字のところで
カーソルが止まってしまい、動作がおかしくなるという話です。
エディタ等のプログラマにしか関係ない話と言えばそれまでですが...
Re:BiDi (スコア:3, 興味深い)
ユーザインターフェース的には、文字単位の処理になっていることが必要です。というのは、Shift_JIS や EUC-JP では全角文字についてもバイト数とカラム数が一致していたので、Backspace キーを 2 回押すことでなんとかごまかしが効きましたが、UTF-8 ではそれは
Re:BiDi (スコア:1)
> EUC-JP では全角文字についてもバイト数とカラム数が一致していた
あの忌まわしき(いわゆる)半角カナは2バイトですよん。
#SS2 + JIS 0201 右半面(MSB on)とでも言うか。
Re:BiDi (スコア:1)
まあ、ふつうは ASCII + JIS X 0208 しか使わないということで。
Re:BiDi (スコア:1)
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね? もちろん、JIS X 0201 カナや JIS X 0212 補助漢字は 2 / 3 バイトと数える人が殆どでしょうし、実際そのように考えた方が便利だからこそ eucJP が使われるわけですが。
ところで
Re:BiDi (スコア:1)
その通りかもしれませんが、いまは、Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、それが正しく実現できさえすれば、どちらの考えに立っても構いません。
なにが「下手」なのか、「泥沼化」とは具体的にどういうことかが分からないのですが、EUC-JP や Shift_JIS においては偶然バイト数とカラム数が (JIS X 0208 について) 一致するという幸運に恵まれてきたわけですが、そういう幸運に頼ることのできない言語があり (タイ語など; 0 カラムの文字がありますが、それらを 0 バイトにすることはできません)、どうせ「きちんと扱」う必要が出てきます。
Re:BiDi (スコア:0)
>Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、
UIに関しては「1文字削除」で問題ないでしょう。
現在の2バイトの日本語文字も、ちゃんと対応してない環境では2回BackSpaceを押さないといけないことがありますが、
そのような動作を本来望んでいるユーザーはいないでしょう。
まして「UTF-8でもBackSpaceは1バイト削除」なんて考えられません。
ただ、「Unicodeの1文字」が「当該スクリプトの削除単位として望ましい1文字」であるかどうかは別ですが。
ともかく、単純なバイト数より上のレイヤ
Re:BiDi (スコア:2, 興味深い)
なるほど。そうですね。
が、これは Unicode のせいではありません。現実に使われている文字が (全角はさておき) BiDi であったり結合文字であったりするので、 Unicode を使おうと、ISO-2022 や TRON コードなど別の文字コードを使おうと、 文字コードの側でそれをなかったことにすることはできません。
まあ、全部いっぺんにつめこむ「だけ」なら、できると思います。 問題は、各々の言語圏で従来まで使われてきた慣例どうしの擦り合わせでしょう。 誰がどこまで妥協すべきか。