パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Fedora JP Projectが正式に発足」記事へのコメント

  • UTF-8 (スコア:1, 興味深い)

    by Anonymous Coward
    EUCに戻してくれ!
    ってお願いすることはできないのでしょうか?
    あんな無茶苦茶な文字コードを表に出してくるなんて
    いったいどういう神経してるのかわかりません。

    日本ではWin、Mac、Sunでコードに互換性がないし、
    将来日本や中国が文字の定義を変更し
    • Re:UTF-8 (スコア:1, 参考になる)

      by Anonymous Coward on 2004年02月10日 16時39分 (#493023)
      > 日本ではWin、Mac、Sunでコードに互換性がないし、
      これはUTF-8 の互換性?
      UCSとかUTF-7とか諸々を unicodeで同じものだ!と勘違いして、
      互換が無いとか嘆いてるって話?

      > 将来日本や中国が文字の定義を変更したらどうするのかとか。
      > unicodeには問題が多すぎるのはみんな知ってるはず。

      そんなこと言ってる人がいるの?
      将来変更したいなら、unicodeの新バージョンで対応するのでは?
      協調がなければ勝手に変更できないのがunicodeであって、
      変更する側も勝手に変えても幸せにはなりません。心配しすぎでしょ。

      そーじゃなくて、unicodeの問題は、EUC等と比較してより多くの
      リソースを消費する点と、中韓日においては似た漢字が
      同じコードとして登録されている為に、本当の書体と違う可能性が
      出てしまっているってのが一番の問題でしょ。

      それとて、文字数の少ないEUC等よりは利点があると感じる人も多いですよ。
      親コメント
      • Re:UTF-8 (スコア:2, 参考になる)

        by Anonymous Coward on 2004年02月10日 16時45分 (#493026)
        > > 日本ではWin、Mac、Sunでコードに互換性がないし、
        > これはUTF-8 の互換性?
        > UCSとかUTF-7とか諸々を unicodeで同じものだ!と勘違いして、
        > 互換が無いとか嘆いてるって話?

        変換表がそれぞれ異なっているんですよ。
        現在は、「これが正しい」って変換表がないですからねぇ。
        親コメント
        • Re:UTF-8 (スコア:2, 参考になる)

          by kyousum (11338) on 2004年02月10日 17時05分 (#493040) 日記

          日本ではWin、Mac、Sunでコードに互換性がないし、

          これはUTF-8 の互換性?
          UCSとかUTF-7とか諸々を unicodeで同じものだ!と勘違いして、
          互換が無いとか嘆いてるって話?

          変換表がそれぞれ異なっているんですよ。
          現在は、「これが正しい」って変換表がないですからねぇ。

          でも、これはユニコード同士の互換性の問題ではなくて、ユニコードとShift-JISの互換性の問題ですよね?EUC-JPに同じ問題があったとは知りませんでした。

          と、思ったらJISとユニコードの変換表の問題 [debian.or.jp]なのですね。考えてみれば当たり前か。

          私にはJISが対応すべき問題に思えるんですが、JISが作った変換表はないのでしょうか?

          --
          # For man might be free./人は自由になれるかもしれないから。
          親コメント
          • by hyoshiok (10034) on 2004年02月11日 1時14分 (#493372)
            私にはJISが対応すべき問題に思えるんですが、JISが作った変換表はないのでしょうか?
            あります。JIS X0208などを見てください。
            親コメント
            • Re:UTF-8 (スコア:2, 参考になる)

              by mkosaki (13560) on 2004年02月11日 19時22分 (#493727) ホームページ 日記
              だうと。208ではなく、JIS X 221 を見てください。

              ただし、まったく役に立ちません。
              問題点は何個かありますが、最大のものは以下の2点

              1.MSのCP932(MSのSJIS)の変換表とぜんぜん違うので
                      互換性がなく、Windowsとの相互運用性が求められる
                      場面では使い物にならない
                      (イマドキ求められへんて事はないわな)
              2.'\' が Yen Mark にマッピングされてしまうため
                      C:\Windows とか printf("\n") のような\を
                      バックスラッシュとして解釈しないと誤動作するような
                      場面ではお手上げ

              救いは「規定」ではなく「参考」なので無視してもJIS違反にはなりません。

              とゆーわけで、実装者は良識にしたがって無視します。

              #もっとも、笑っちゃうことにUnicode.orgに登録されている
              #SJIS変換表はJIS X 221 のものとは全然違ううえ、
              #やっぱりMSと互換性ないので、純朴なUnicode信者が
              #それを見て、実装した日本語用の変換表は、
              #ほぼ確実にバグってるとかいう
              #わはは・・
              #そういう訳で誰が悪いわけでもないんだけれども、
              #日本人がUnicodeを使うといっぱい苦痛を味わうような
              #文化的背景が出来上がっちゃってます。実質
              親コメント
              • by numa (4467) on 2004年02月13日 1時15分 (#494682) ホームページ 日記
                だうと。208ではなく、JIS X 221 を見てください。

                いつの話をされていますか? JIS X 0208 と Unicode (ISO/IEC 10646) との間のコード変換規則は, JIS X 0221:1995 の発行時に,その附属書で初めて定義され, その後,JIS X 0208:1997 が発行されたときに, (コード変換表という形ではないが,シンボル名の対応づけという形で) JIS X 0208 の規定に取り込まれ, JIS X 0221 の現行の版である JIS X 0221-1:2001 からは外されているはずですが.

                それから,JIS X 0221 の附属書で出たときに「参考」だったのは, 「そもそもこの種の規定は JIS X 0208 で行うべき」 という考えだったからであり, JIS X 0208:1997 では「規定」になっています. (「規定」だからといって,使われているわけでもないけど.)

                それから, Unicode.org で公開されているコード変換表は, 漢字の部分を除いて,どれも「参考」という扱いです. 特に日本語を含む EASTASIA 以下の変換表は OBSOLETE 以下の ディレクトリにあります. 参考: http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/

                親コメント
              • by Anonymous Coward
                MSとの互換性を重要視されているようですが、MSの変換表は、SJIS (CP932) の 0x5C (円記号) を Unicode の U+005C にマッピングする上、Unicode の U+005C に円記号を割り当てていますので、全然ダメです。U+005C が円記号な文字コードって、それって Unicode とは認められないと思うんだけど。

                そんなとんでもない変換表 (と Unicode モドキ文字コード) を採用しているのは、MSだけです。

              • by Anonymous Coward

                波ダッシュはチルダではない [asahi-net.or.jp]の件も忘れずに。

                「変な変換表をデファクトスタンダードにしてしまった」罪は大きいんだぞ、っと。

        • べつに・・・自分で変換ルール決めれば困ることもありません。
          UnicodeからEUC-JP、Shift_JIS、Windows-31Jへ変換するときにUnicode側で複数コードを持っている文字をまとめるという変換コードが少ない(自分で作ればある)のが問題なだけで。
          SJISやWindows-31J、EUC-JPからUnicodeに変換するときに化けるというのは、該当する位置のフォントがないのが問題という場合がほとんど。これもフォントの割当て方で解決できます。
          Unicodeの問題、というわけではないです。
          --
          okome
          親コメント
        • by Anonymous Coward
          世の中のメインが Unicode ベースに移行してしまえば、こんどは「変換表がそれぞれ異なってるんで、EUCとかSJISとかはWin、Mac、Sunで互換性がないから面倒だ」と言って毛嫌いされるようになるんでしょうね。

          正しい変換表というのを

      • by Anonymous Coward
        UTF-8というかUnicodeの一番ヤバイ点は日本語の等幅フォントの
        ことをぜんぜん考慮してない点ですよ。例をあげると、
        これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や
        ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、
        Unicodeではこれを半角として扱わなくてはいけないことになっています。
        そうすると、例えばncursesアプリなんかは今までEUCで表示していて
        上手く表示されてたプロ
        • by kyousum (11338) on 2004年02月10日 17時29分 (#493069) 日記

          これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、 Unicodeではこれを半角として扱わなくてはいけないことになっています。

          (OS Xの文字パレットを見て…本当だ。Full-Width Formsにはローマ字と記号しか入ってない)

          ncursesについてはGoogleで調べて画面表示用の関数だとしか分からなかったのですが、UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを使って表示するだけじゃ駄目ですか?

          そもそも互換用に一部「全角」文字がある以外はUnicodeには「半角」「全角」の概念は無いはずです。互換維持のために必要なら、ギリシャ・ロシア文字を「全角」で表示しようが「半角」で表示しようがUnicodeの知ったことじゃないと思うのですが。

          「全角」のロシア・ギリシャ文字と「半角」のロシア・ギリシャ文字を区別したいと言われると困りますがそもそもJISX0208でもその区別はできなかったわけですし。

          --
          # For man might be free./人は自由になれるかもしれないから。
          親コメント
          • Re:UTF-8 (スコア:1, 興味深い)

            by Anonymous Coward on 2004年02月10日 18時12分 (#493118)
            #493035です。あまり詳しくないので間違ってるかもしれませんが…
            > UTF-8を使っているときもギリシャ・ロシア文字を「全角」のフォントを
            使って表示するだけじゃ駄目ですか?
            そうするとncursesアプリケーションのプログラムの内部で、アジア圏と
            非アジア圏でそれぞれ別な処理を行わなくてはいけないのでしょうか。

            たしか以前、国際化XTermのトピックでこういった場合にどう表示を
            するべきかについてkubotaさんという方がかなり悩ましげにしていた
            記憶があります。そのために今のXTermではUTF-8の表示モードを
            いくつか用意し、互換性のためにmediumモードという
            アジア圏localeを特別視したモードが作られました。

            アジア圏の後方互換性を重視した結果、XtermのUTF-8表示モードの
            違いによって、同じUTF-8の文字列を表示した結果が異なることに
            なりました。その結果、プログラマはあるUTF-8文字を全角で表示
            するのか、半角で表示するのかを知ることはできないので、
            なんとなく泥臭い処理を行わなくてはいけなくなりました。

            アジア圏で使われるコンソールアプリケーションを作ってる人達が
            こういう状況をヒイヒイいいながら何とか自前で吸収している姿を
            想像すると、ほんとうにUTF-8化に未来なんてあるのかなって思います。
            親コメント
            • Re:UTF-8 (スコア:3, 参考になる)

              by kyousum (11338) on 2004年02月10日 19時44分 (#493167) 日記

              Unicodeは現状の各文字コードの上位互換になるように作られてますけど、「半角」のロシア文字と「全角」のロシア文字を両方マッピングした文字セットが一つもないためにこの違いがUnicode上は消えてしまったわけですな。(推測ですが。全角ロ?マ字はUnicodeにあることからすれば正しいと思います。さらに個人的には、そもそもJISはロシア文字が全角だと言っていたのかと言う疑問があります。日本のメーカーがたまたまロシア文字等を全角にしただけだったりしないでしょうか。)

              以上はUnicode派としてのなんで全角ロシア等文字がないのかの言い訳ですが、問題の解決にはつながりませんね。

              まず、Unicodeの立場としては利用者側でどんな幅で表示しようが知ったことじゃありません。でも、等角フォントを前提に複雑な表示を行うncursesアプリケーション等ではそれは困るので…

              …結局Unicodeからすれば文字コードに期待していることが多すぎると言うしかないと思います。

              付け加えればエンコーディングの問題以前に現状の日本語フォントには半角のロシア文字は含まれていないし、欧文フォントには全角のロシア文字には含まれていないと言う問題もあります。

              プログラマから、ターミナルに「こういう文字は全角で表示したい」あるいは「こういう文字は半角で表示したい」と伝えられる方法を作って、シェルが複数のフォントを組み合わせて(場合によっては半角と空白等を組み合わせて)対応するか、利用者の使用しているフォントの種類に合わせて個別アプリケーションが対応するしかないのでしょう。

              Unicodeに悩んでいる作者さんはこんなことは、こんなことは百も承知でもっと進んだところで悩んでいるのでしょうが、そう言う問題があると知ったのは大変に個人的に参考になりました。

              --
              # For man might be free./人は自由になれるかもしれないから。
              親コメント
            • by Anonymous Coward on 2004年02月10日 19時13分 (#493156)

              libcにあったりするようで。
              # ちゃんと実装されてれば、 引数としてあたえたワイド文字の tty 様表示環境で期待されるカラム数が得られる

              きちんと setlocale(LC_ALL, "") するという前提ならば、 何とかなりそうな気が。

              コードポイントのみならず、 ロケールの国・地域情報を加味した有意義なデータが得られそうな気がします。
              # たとえば、同じキリル文字(当然同一のコードポイントね)でも、 LANG が日本語圏では2カラム、 ロシアなどでは1カラムと評価されるとかね

              それよりも、もはや 構成バイト数 = 占有カラム数 は成立しないということを、 プログラマはちゃんと意識しなければならないのでは、 などと思ったり。
              # もっとも、 EUC-JP の半角カナだって昔からそうだった訳ですが。

              ― 普段は FreeBSD 使いなので AC

              親コメント
        • Re:UTF-8 (スコア:1, 参考になる)

          by Anonymous Coward on 2004年02月10日 18時48分 (#493142)
          これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、 Unicodeではこれを半角として扱わなくてはいけないことになっています。
          だうと。 UAX #11 East Asian Width [unicode.org]とかEastAsianWidth.txt [unicode.org]のU+0391~, U+0410~のプロパティを見るに、ギリシア・ロシア文字はA(East Asian Ambiguous)となっているようです。 つまり文脈依存。
          親コメント
          • by Anonymous Coward
            #493035です…
            誤った認識に基づいた発言をしてしまい、読む人に混乱を与えてしまいました。
            申し訳ありませんでした…。
            全ての私の発言に-1モデレートをお願いします。
            • by Anonymous Coward
              > 全ての私の発言に-1モデレートをお願いします。

              Anonymous Cowardの発言を全て-1にするようにという、大胆な提案でしょうか?

              # -1してもらうためにAC

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

処理中...