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

開発中の PHP 6、UTF-16 化に失敗。開発ブランチも 5.3 系に巻き戻し 」記事へのコメント

  • by Anonymous Coward
    マニフェストどおりじゃなくていいんですか!
    • 技術的に無理だと言うなら仕方ないと思うが、スタンスが間違ってたと言う話になるなら、何でもっと早めにそれらについて討議しなかったのか?と感じる。結局無駄な時間を費やしてしまうことになる。 日頃から十分な議論を行うよう、今後に期待したい。
      親コメント
      • by firewheel (31280) on 2010年03月19日 14時35分 (#1735703)

        ソフトウエア開発は単純な組み立て作業ではなく複雑な設計作業そのものだから。
        設計作業が終わるまで見えてこない物というのはあるものです。

        って、いったい何度繰り返したらエライ人は理解してくれるようになるんだろう。

        親コメント
        • by Anonymous Coward on 2010年03月19日 15時55分 (#1735741)

          そうなんだよね。
          流れ作業にまで落ちた「製造」に該当するのはCDのプレスとかに
          なると思うんだけど、なかなか理解が得られない。

          親コメント
        • by Anonymous Coward

          あなたが技術職を引退し、あなた自身かその教え子が現場を掌握する立ち場を受け持ったときです。

      • えっと (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2010年03月19日 13時01分 (#1735653)

        基地移転問題の事ですか?

        親コメント
      • これから UCS 正規化方式に切り替えるなら、UTF-16 ではなく UTF-32 を採用したほうがマシですかね。固定長ですし。
        現状で UTF-16 を採用するメリットって何も無いような…

        親コメント
        • by Anonymous Coward on 2010年03月19日 13時16分 (#1735668)

          UTF-32でも可変長が避けて通れない(日本に限ってもIVS [nikkeibp.co.jp]とか)なんていい加減常識になったと思ってたんだけど、なんでまだこんなこと言う人がいるの?

          親コメント
          • 合成文字もありますしね。簡単な文字列処理ならともかく、エディタ等では合成された文字を1文字として認識できないとまずいですから。

            大作:「立て、ジャイアントロボ!」
            GR:「ま゛っ」 ← U+309B : 独立した濁点
            GR:「ま゙っ」 ← U+3099 : 合成用濁点

            ブラウザ次第ではありますが、上記のGRの台詞をマウスで選択したとき、上は「ま」と濁点が別々の文字、下は1つの文字として扱われているはず。

            親コメント
            • by Anonymous Coward

              Windows7RC では Firefox/Chrome とも1文字として扱われるものの、「ま ゛」のように仮名と濁点の間に大きな空間が開きますね。まだまだ不完全な感じ。一方 IE8 は隣接するものの、今度は「っ」の上にはみ出して表示されるという不具合が。また選択すると「ま」のみが反転されて、濁点は消えてなくなります。そのままメモ帳に濁点つきでコピペできるところを見ると、文字通り濁点が仮想的なマス目からはみ出て描画されているのかも。ちなみにメモ帳での表示が一番自然に見えました。

              • by Anonymous Coward

                XPでIE7だけど下のは「ま・っ」となって点になってます

            • by Anonymous Coward

              Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja; rv:1.9.3a4pre) Gecko/20100318 Minefield/3.7a4pre
              合字されました。

              Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2) Gecko/20100115 Firefox/3.6
              合字されましたが、濁点は文字の左上につきました。

              Safari 4.0.5 (6531.22.7)
              合字されませんでした。

              • by Anonymous Coward
                > Safari 4.0.5 (6531.22.7)
                > 合字されませんでした。

                うちのSafari(同じversion)ではうまくいってます。
                何が違うんだろ。
          • by Anonymous Coward on 2010年03月19日 13時50分 (#1735682)

            http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1260 [xml.gr.jp]
            >  これだけPCの容量が大きくなったのだから32bitにしてもいいじゃないか、と
            > いう意見がありますが、これは一種の錯誤です。
            続きはリンク先をどうぞ。
            最近ではスマートフォンとかiPadとかネットブックとかの、PCよりメモリ要求が厳しい端末も無視できませんからなおさらですね(主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。これは理由のないことではありません)。
            UTF-32にしても固定長で処理が済むわけでは全然なく、メリットはありません。UTF-32だろうと(サロゲートペアを無視した)UCS-2だろうとWindows←→Mac OS X間のファイル共有を実装しようとするだけで文字合成(「タ,U+3099←→ダ」とか)の考慮は必須です。
            UTF-8やUTF-16は定義域をU+10FFFFまでに制限している限り1コードポイントのサイズが4バイトを超えることはありませんから、UTF-32はメモリの無駄遣いでしかありません。ISO/IEC 10646でもUnicodeとの相互運用性向上のため、U+10FFFFを超える範囲は「永久予約」とされました。

            親コメント
            • あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。

              > 主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。
              > これは理由のないことではありません

              これはそれぞれのエンコーディングを机上に並べて評価したと言うより、
              依存先のライブラリや、プロジェクトの起点が UTF-16 だったからという理由じゃないですかね。
              IE なら Windows、WebKit なら fork 元の KHTML の親プロジェクトの KDE、
              Firefox なら Mozilla Project と。
              どれも UTF-32 が生まれる前から存在するプロジェクトなので、まぁそうなりますよね。
              というか、UCS-2 時代から存在するコードからすると UTF-8 すら新参になるため、
              その資産を生かそうとすると UTF-16 以外選択肢にならなくなってしまうと。

              そういえば、JavaScript は所々に UTF-16 前提の仕様が入ってますね。

              親コメント
              • by Anonymous Coward

                > あれ、リンク先、OS だったら wchar_t は当時でも 32bit が主流だと思うんだけどなぁ。
                でも__STDC_ISO_10646__は主流じゃなかったと思いますけど。
                まあ、
                >> 私の感想は「ああ、余裕のある組織なんだな」。お
                >> そらく余裕の無いところは意地でMacを使い続ける余裕はなく、お客さんが
                >> WindowsならWindowsにしないとやってられないのだろうな、と思いました。
                なんて書いてるような人だからWindows以外眼中に無いのは確かでしょうけど。本人は否定してますけど視点がものすごくWindowsに偏向してますから。
                > どれも UTF-32 が生まれる前から
                UCS-4は当時からあったのですからいくらなんでもその主張は無理があるでしょう。

          • いっそ全面固定長のUTF-128を…

            # zipでよく潰れそう

            親コメント
            • by Anonymous Coward

              現在Unicodeには「か」と合成済みの「が」と濁点が3種類も(合成用のU+3099、合成済みのU+309B、半角濁点)入ってますけど、これは正規化などの「問題」を引き起こすとしてむしろ非難されてますよね。ハングルも合成済みのと「合理的な」組み合わせ式のとKS X 1001互換用の3種類入ってました。
              どうして単純にビット数を増やして何でもかんでも固定長に突っ込めばすべてが解決するという単純な頭の人が後を絶たないのか本当に不思議でなりません。すごい文字コード [srad.jp]でも使っててください。

            • by Anonymous Coward

              >いっそ全面固定長のUTF-128を…
              モノクロ32x32ビットマップフォントがまんま入りますね

              #それ文字コードちゃう

            • by Anonymous Coward
              UTFv6で文字から記号から全てにコードを!
          • by Anonymous Coward
            「Unicodeコードポイント」を「固定長」で表現するという意味では正しいからでは?
          • by Anonymous Coward
            > UTF-32でも可変長が避けて通れない(日本に限ってもIVSとか)

            IVSはそれ自体で一文字だから、関係ないでしょ
        • by Anonymous Coward

          現状で UTF-16 を採用するメリットって何も無いような…

          WindowsやMac OS X(Cocoa)と互換性が高くなるというメリットがあります。

      • by Anonymous Coward
        NHK夜9時の人の口調が頭に浮かぶのはわたしだけかなあ。

人生unstable -- あるハッカー

処理中...