アカウント名:
パスワード:
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変して
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチ [debian.or.jp]では、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので
あと、この 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 でない実装を否定したいようですがね.)
より多くのコメントがこの議論にあるかもしれませんが、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 を改変して
Re:文字の幅 (スコア:1)
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチ [debian.or.jp]では、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので
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 でない実装を否定したいようですがね.)