アカウント名:
パスワード:
これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、 Unicodeではこれを半角として扱わなくてはいけないことになっています。
(OS Xの文字パレットを見て…本当だ。Full-Width Formsにはローマ字と記号しか入ってない)
ncursesについてはGoogleで調べて画面表示用の関数だとしか分からなかったのですが、UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを使って表示するだけじゃ駄目ですか?
そもそも互換用に一部「全角」
Unicodeは現状の各文字コードの上位互換になるように作られてますけど、「半角」のロシア文字と「全角」のロシア文字を両方マッピングした文字セットが一つもないためにこの違いがUnicode上は消えてしまったわけですな。(推測ですが。全角ロ?マ字はUnicodeにあることからすれば正しいと思います。さらに個人的には、そもそもJISはロシア文字が全角だと言っていたのかと言う疑問があります。日本のメーカーがたまたまロシア文字等を全角にしただけだったりしないでしょうか。)
以上はUnicode派としてのなんで全角ロシア等文字がないのかの言い訳ですが、問題の解決にはつながりませんね。
まず、Unicodeの立場としては利用者側でどんな幅で表示しようが知ったことじゃありません。でも、等角フォントを前提に複雑な表示を行うncursesアプリケーション等ではそれは困るので…
…結局Unicodeからすれば文字コードに期待していることが多すぎると言うしかないと思います。
付け加えればエンコーディングの問題以前に現状の日本語フォントには半角のロシア文字は含まれていないし、欧文フォントには全角のロシア文字には含まれていないと言う問題もあります。
プログラマから、ターミナルに「こういう文字は全角で表示したい」あるいは「こういう文字は半角で表示したい」と伝えられる方法を作って、シェルが複数のフォントを組み合わせて(場合によっては半角と空白等を組み合わせて)対応するか、利用者の使用しているフォントの種類に合わせて個別アプリケーションが対応するしかないのでしょう。
Unicodeに悩んでいる作者さんはこんなことは、こんなことは百も承知でもっと進んだところで悩んでいるのでしょうが、そう言う問題があると知ったのは大変に個人的に参考になりました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
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
Re:UTF-8 (スコア:3, 参考になる)
Unicodeは現状の各文字コードの上位互換になるように作られてますけど、「半角」のロシア文字と「全角」のロシア文字を両方マッピングした文字セットが一つもないためにこの違いがUnicode上は消えてしまったわけですな。(推測ですが。全角ロ?マ字はUnicodeにあることからすれば正しいと思います。さらに個人的には、そもそもJISはロシア文字が全角だと言っていたのかと言う疑問があります。日本のメーカーがたまたまロシア文字等を全角にしただけだったりしないでしょうか。)
以上はUnicode派としてのなんで全角ロシア等文字がないのかの言い訳ですが、問題の解決にはつながりませんね。
まず、Unicodeの立場としては利用者側でどんな幅で表示しようが知ったことじゃありません。でも、等角フォントを前提に複雑な表示を行うncursesアプリケーション等ではそれは困るので…
…結局Unicodeからすれば文字コードに期待していることが多すぎると言うしかないと思います。
付け加えればエンコーディングの問題以前に現状の日本語フォントには半角のロシア文字は含まれていないし、欧文フォントには全角のロシア文字には含まれていないと言う問題もあります。
プログラマから、ターミナルに「こういう文字は全角で表示したい」あるいは「こういう文字は半角で表示したい」と伝えられる方法を作って、シェルが複数のフォントを組み合わせて(場合によっては半角と空白等を組み合わせて)対応するか、利用者の使用しているフォントの種類に合わせて個別アプリケーションが対応するしかないのでしょう。
Unicodeに悩んでいる作者さんはこんなことは、こんなことは百も承知でもっと進んだところで悩んでいるのでしょうが、そう言う問題があると知ったのは大変に個人的に参考になりました。
# For man might be free./人は自由になれるかもしれないから。