アカウント名:
パスワード:
これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、 Unicodeではこれを半角として扱わなくてはいけないことになっています。
(OS Xの文字パレットを見て…本当だ。Full-Width Formsにはローマ字と記号しか入ってない)
ncursesについてはGoogleで調べて画面表示用の関数だとしか分からなかったのですが、UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを使って表示するだけじゃ駄目ですか?
そもそも互換用に一部「全角」
libcにあったりするようで。 # ちゃんと実装されてれば、 引数としてあたえたワイド文字の tty 様表示環境で期待されるカラム数が得られる
きちんと setlocale(LC_ALL, "") するという前提ならば、 何とかなりそうな気が。
コードポイントのみならず、 ロケールの国・地域情報を加味した有意義なデータが得られそうな気がします。 # たとえば、同じキリル文字(当然同一のコードポイントね)でも、 LANG が日本語圏では2カラム、 ロシアなどでは1カラムと評価されるとかね
それよりも、もはや 構成バイト数 = 占有カラム数 は成立しないということを、 プログラマはちゃんと意識しなければならないのでは、 などと思ったり。 # もっとも、 EUC-JP の半角カナだって昔からそうだった訳ですが。
― 普段は FreeBSD 使いなので AC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
UTF-8 (スコア:1, 興味深い)
ってお願いすることはできないのでしょうか?
あんな無茶苦茶な文字コードを表に出してくるなんて
いったいどういう神経してるのかわかりません。
日本ではWin、Mac、Sunでコードに互換性がないし、
将来日本や中国が文字の定義を変更し
Re:UTF-8 (スコア:1, 参考になる)
これはUTF-8 の互換性?
UCSとかUTF-7とか諸々を unicodeで同じものだ!と勘違いして、
互換が無いとか嘆いてるって話?
> 将来日本や中国が文字の定義を変更したらどうするのかとか。
> unicodeには問題が多すぎるのはみんな知ってるはず。
そんなこと言ってる人がいるの?
将来変更したいなら、unicodeの新バージョンで対応するのでは?
協調がなければ勝手に変更できないのがunicodeであって、
変更する側も勝手に変えても幸せにはな
Re:UTF-8 (スコア:0)
ことをぜんぜん考慮してない点ですよ。例をあげると、
これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や
ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、
Unicodeではこれを半角として扱わなくてはいけないことになっています。
そうすると、例えばncursesアプリなんかは今までEUCで表示していて
上手く表示されてたプロ
Re:UTF-8 (スコア:1)
(OS Xの文字パレットを見て…本当だ。Full-Width Formsにはローマ字と記号しか入ってない)
ncursesについてはGoogleで調べて画面表示用の関数だとしか分からなかったのですが、UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを使って表示するだけじゃ駄目ですか?
そもそも互換用に一部「全角」
# For man might be free./人は自由になれるかもしれないから。
Re:UTF-8 (スコア:1, 興味深い)
> UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを
使って表示するだけじゃ駄目ですか?
そうするとncursesアプリケーションのプログラムの内部で、アジア圏と
非アジア圏でそれぞれ別な処理を行わなくてはいけないのでしょうか。
たしか以前、国際化XTermのトピックでこういった場合にどう表示を
するべきかについてkubotaさんという方がかなり悩ましげにしていた
記憶があります。そのために今のXTermではUTF-8の表示モードを
いくつか用意し、互換性のためにmediumモードという
アジア圏lo
wcwidth() なる関数が (スコア:2, 参考になる)
libcにあったりするようで。
# ちゃんと実装されてれば、 引数としてあたえたワイド文字の tty 様表示環境で期待されるカラム数が得られる
きちんと setlocale(LC_ALL, "") するという前提ならば、 何とかなりそうな気が。
コードポイントのみならず、 ロケールの国・地域情報を加味した有意義なデータが得られそうな気がします。
# たとえば、同じキリル文字(当然同一のコードポイントね)でも、 LANG が日本語圏では2カラム、 ロシアなどでは1カラムと評価されるとかね
それよりも、もはや 構成バイト数 = 占有カラム数 は成立しないということを、 プログラマはちゃんと意識しなければならないのでは、 などと思ったり。
# もっとも、 EUC-JP の半角カナだって昔からそうだった訳ですが。
― 普段は FreeBSD 使いなので AC