アカウント名:
パスワード:
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変してねってことに なると思うんだけど、Unicode だし固定だ!とかいわれる として、そのときのそれぞれの幅をどう するかって 話になるのなら、たとえば Solaris が wcwidth を 実装してるから、例えば en_US.utf-8 の時のその データをもってこれが標準だ! と、示すってのは どーでしょう。
Solaris のデータが腐ってたりして(わら
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチでは、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので、 wcwidth(3) が正しく動くことは必要なことではありますが、 だからといってロケール定義を好き勝手にしてもきちんと動くという わけではないです。 ぼくはそれでも、リモートでない場合とか、自分で分かっててやるぶんには かまわないだろうと思うのですが...
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか? いちおう、上記のぼくのパッチには、それらしきコードが書いてありますが。 XTerm + luit のアプローチだと、XTerm そのものは エンコーディング変換を一切やらない建前だし (そうすることで XTerm 本体の保守性を保つのだとか。ぼくがメンテするのではないので、 そう言われると反論しにくい)、かといって luit はロケールを使わずに ISO-2022 をそのまま解釈する構造になっていて、 やはりワイド文字とかマルチバイト文字とかとはなじみが悪いです。 というわけで、wcwidth(3) に基づいた文字幅を実現するのは このままではなかなか難しそうです。
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか?
ワイド文字のエンコーディングには××を使わなければならない,といった標準はないので (__STDC_ISO_10646__ が定義されていれば別ですが), 完全な移植性を求めるなら, 「いったん mbtowc() でマルチバイト文字に変換してから Unicode に直す」 しかありません.で,それは決して「効率よく」はない.
昔々,EUC が AT&T UNIX Pacific で規定された (厳密に言えば日本語 UNIX 諮問委員会の案を一般化しただけですが) ときには,マルチバイト文字とワイド文字との間の関係は完全に明文化されていたけれど,それは ISO/IEC 2022 の枠組みを強烈に意識していたので,その枠に収まらない Shift_JIS や Big5 での実現を排除してしまうことになり,それが標準になることもなかった.(実際 UNIX Pacific も, wchar_t を16ビットから32ビットにしたときに,ワイド文字の内部形式の互換はとらなかった.)
たとえば,HP-UX では EUC-JP も Shift_JIS も 両方サポートしていたけれど,ワイド文字の形式は UNIX Pacific 方式とは違っていて,しかも, たとえ同じ文字でも エンコーディングが違えばワイド文字の表現まで 変わってしまうのでびっくりしたことがあります. Solaris では一応 EUC-JP と Shift_JIS とでは 同じ文字のワイド文字表現は同じにしていましたが, UTF-8 になるとワイド文字が UCS-4 になってしまった ので,そういう意味での互換性はなくなりました.
ワイド文字が Unicode であることを明文化している システム (Windows NT の UCS-2 と glibc 2.2 の UCS-4) もありますし,たとえばマルチバイト文字の エンコーディングが UTF-8 の場合,wchar_t が32ビットなら,その内部表現が UCS-4 になるのが一番自然でしょうが,その想定が必ず正しいという保証はありません.たとえば,UTF-16 の範囲の文字しか使わないと思えば,上のビットが何ビットか余っていることになるので,それを別の用途に使いたいと思う人がいるかもしれません. (もっとも, Markus は wchar_t が Unicode でない実装を否定したいようですがね.)
これってDevanagariやThaiの扱いはどうなるんでしょ?
どんな仕様を提案するにしても、今日本人が欧米人に対して言うように、 後で「無知な日本人めっ」とか言われることになったら悲しいよね。
端末エミュレーターに限って言えば, 一文字が一定幅か,その整数倍の幅をもつという前提が (近似的にでも) 成り立たない文字に 適用するのはかなり困難でしょう. Devanagari や Thai がどうかは知らないので, なんとも言いかねます.
インド人やタイ人だってコンピューターを 使っているわけですから,勝手な思い込みで決めつけず,謙虚に意見を聞けばいいのです. 何にも知らないくせに, 「これなら世界中の文字に対応できる」とか, 「どうせ××文字なんて使うやつは少ないから, 後回しでいいんだ」とか, 偉そうに主張するのが一番嫌われる.
日本人なんておとなしいものですよ. なんせ,「これでは日本語が通らない」としか言わないのだから.
タイは、TIS620 というエンコーディングが使われており、結合文字が必須です。おそらくタイ人自身による実装である xiterm+thai というのが Debian では利用可能です。XTerm も UTF-8 モードではかなり前から結合文字の使用が可能です。これはタイ人じゃなくて Robert Brady さんという人の仕事です。ちなみに XTerm で全角文字が使えるようになったのも、この人のおかげです。
すみませんが、インドのことについては知りません。
「これでは日本語が通らない」としか言わないかというと、そうでもなくて、ASCII と CJK に対応したものを作って「国際化ができた」とか言うことがよくあります。
これは一本取られましたね. 「良くも悪くも,日本語のことしか考えていない」 という方が近いかな.
遠い外国の事情はわからないことが多いので, 「とりあえず日本語は通ります」といって出すのが いいのかもしれません.他の国の人が試して, 問題があれば直してくれるかもしれませんから.
それでしたら、問題があるかどうか試してほしいという意思表示が必要だと思います。「とりあえず日本語は通ります」という言い方だと、「ああ、あれは日本語専用だからわれわれには関係ない」と思ってほっとかれるおそれがあります。
ぼくは、誇大広告になるのを覚悟で、「マルチバイト文字に対応するように改良した。CJK はマルチバイトが必要だし、将来 Unicode を使いたくなったら Unicode もマルチバイトだからこのパッチが役立つ。従来の 8 ビットエンコーディングには悪影響を与えないはずだからこのパッチを採用してくれ」とかいうふうに言うことにしています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
文字の幅 (スコア:0)
ではないんですかね。従来の US-ASCII:JIS X 0208 =
1:2 が欲しいなら、そういうフォントを使えばいいの
では…
従来の文字幅が欲しいなら kterm を使えばいいわけだし、
どうでもいいじゃないですか。
Re:文字の幅 (スコア:1)
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
Re:文字の幅 (スコア:0)
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変してねってことに なると思うんだけど、Unicode だし固定だ!とかいわれる として、そのときのそれぞれの幅をどう するかって 話になるのなら、たとえば Solaris が wcwidth を 実装してるから、例えば en_US.utf-8 の時のその データをもってこれが標準だ! と、示すってのは どーでしょう。
Solaris のデータが腐ってたりして(わら
Re:文字の幅 (スコア:1)
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチでは、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので、 wcwidth(3) が正しく動くことは必要なことではありますが、 だからといってロケール定義を好き勝手にしてもきちんと動くという わけではないです。 ぼくはそれでも、リモートでない場合とか、自分で分かっててやるぶんには かまわないだろうと思うのですが...
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか? いちおう、上記のぼくのパッチには、それらしきコードが書いてありますが。 XTerm + luit のアプローチだと、XTerm そのものは エンコーディング変換を一切やらない建前だし (そうすることで XTerm 本体の保守性を保つのだとか。ぼくがメンテするのではないので、 そう言われると反論しにくい)、かといって luit はロケールを使わずに ISO-2022 をそのまま解釈する構造になっていて、 やはりワイド文字とかマルチバイト文字とかとはなじみが悪いです。 というわけで、wcwidth(3) に基づいた文字幅を実現するのは このままではなかなか難しそうです。
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Re:文字の幅 (スコア:1)
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.
Re:文字の幅 (スコア:1)
ワイド文字のエンコーディングには××を使わなければならない,といった標準はないので (__STDC_ISO_10646__ が定義されていれば別ですが), 完全な移植性を求めるなら, 「いったん mbtowc() でマルチバイト文字に変換してから Unicode に直す」 しかありません.で,それは決して「効率よく」はない.
昔々,EUC が AT&T UNIX Pacific で規定された (厳密に言えば日本語 UNIX 諮問委員会の案を一般化しただけですが) ときには,マルチバイト文字とワイド文字との間の関係は完全に明文化されていたけれど,それは ISO/IEC 2022 の枠組みを強烈に意識していたので,その枠に収まらない Shift_JIS や Big5 での実現を排除してしまうことになり,それが標準になることもなかった.(実際 UNIX Pacific も, wchar_t を16ビットから32ビットにしたときに,ワイド文字の内部形式の互換はとらなかった.)
たとえば,HP-UX では EUC-JP も Shift_JIS も 両方サポートしていたけれど,ワイド文字の形式は UNIX Pacific 方式とは違っていて,しかも, たとえ同じ文字でも エンコーディングが違えばワイド文字の表現まで 変わってしまうのでびっくりしたことがあります. Solaris では一応 EUC-JP と Shift_JIS とでは 同じ文字のワイド文字表現は同じにしていましたが, UTF-8 になるとワイド文字が UCS-4 になってしまった ので,そういう意味での互換性はなくなりました.
ワイド文字が Unicode であることを明文化している システム (Windows NT の UCS-2 と glibc 2.2 の UCS-4) もありますし,たとえばマルチバイト文字の エンコーディングが UTF-8 の場合,wchar_t が32ビットなら,その内部表現が UCS-4 になるのが一番自然でしょうが,その想定が必ず正しいという保証はありません.たとえば,UTF-16 の範囲の文字しか使わないと思えば,上のビットが何ビットか余っていることになるので,それを別の用途に使いたいと思う人がいるかもしれません. (もっとも, Markus は wchar_t が Unicode でない実装を否定したいようですがね.)
Re: 文字の幅 (スコア:0)
これってDevanagariやThaiの扱いはどうなるんでしょ?
どんな仕様を提案するにしても、今日本人が欧米人に対して言うように、 後で「無知な日本人めっ」とか言われることになったら悲しいよね。
Re: 文字の幅 (スコア:1)
端末エミュレーターに限って言えば, 一文字が一定幅か,その整数倍の幅をもつという前提が (近似的にでも) 成り立たない文字に 適用するのはかなり困難でしょう. Devanagari や Thai がどうかは知らないので, なんとも言いかねます.
インド人やタイ人だってコンピューターを 使っているわけですから,勝手な思い込みで決めつけず,謙虚に意見を聞けばいいのです. 何にも知らないくせに, 「これなら世界中の文字に対応できる」とか, 「どうせ××文字なんて使うやつは少ないから, 後回しでいいんだ」とか, 偉そうに主張するのが一番嫌われる.
日本人なんておとなしいものですよ. なんせ,「これでは日本語が通らない」としか言わないのだから.
Re: 文字の幅 (スコア:1)
タイは、TIS620 というエンコーディングが使われており、結合文字が必須です。おそらくタイ人自身による実装である xiterm+thai というのが Debian では利用可能です。XTerm も UTF-8 モードではかなり前から結合文字の使用が可能です。これはタイ人じゃなくて Robert Brady さんという人の仕事です。ちなみに XTerm で全角文字が使えるようになったのも、この人のおかげです。
すみませんが、インドのことについては知りません。
「これでは日本語が通らない」としか言わないかというと、そうでもなくて、ASCII と CJK に対応したものを作って「国際化ができた」とか言うことがよくあります。
Re: 文字の幅 (スコア:1)
これは一本取られましたね. 「良くも悪くも,日本語のことしか考えていない」 という方が近いかな.
遠い外国の事情はわからないことが多いので, 「とりあえず日本語は通ります」といって出すのが いいのかもしれません.他の国の人が試して, 問題があれば直してくれるかもしれませんから.
日本語「も」使えます (スコア:1)
それでしたら、問題があるかどうか試してほしいという意思表示が必要だと思います。「とりあえず日本語は通ります」という言い方だと、「ああ、あれは日本語専用だからわれわれには関係ない」と思ってほっとかれるおそれがあります。
ぼくは、誇大広告になるのを覚悟で、「マルチバイト文字に対応するように改良した。CJK はマルチバイトが必要だし、将来 Unicode を使いたくなったら Unicode もマルチバイトだからこのパッチが役立つ。従来の 8 ビットエンコーディングには悪影響を与えないはずだからこのパッチを採用してくれ」とかいうふうに言うことにしています。