We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33014 ☆ A M B ☆
    • 1,231 Posts
    Quote from: tkfm at Nov 11, 2008, 01:35 AM

    ほぼ100%がmodxのエンコーディングと同じエンコーディングが必要です。UTF-8で運用していて、EUCなファイルを書き出したいというケースはまずありません。
    今回は、そういう前提でいいような気がします。MODxをutf-8で運用してるなら、テキストファイルもutf-8という前提で。
    そこは最低限対応するとして、ファイルマネージャとして機能を充実させるには、他にもいろいろ観点があると思いますし。
      • 33014 ☆ A M B ☆
      • 1,231 Posts
      http://modxcms.com/forums/index.php/topic,29201.msg184339.html#msg184339
      Quote from: yama at Nov 05, 2008, 10:17 PM

      mysql_query関数の一部を$modx->db->queryに置き換えました。
      話が前後しますが、こちらの件。
      厳密には、
      $name = mysql_escape_string(trim($_POST['name']));
      $description = mysql_escape_string($_POST['description']);

      このへんもDBAPIに置き換えるのがスマートなのかなと思ったりしてます。
      できれば全部一括で置き換えるつもりでDBAPIのほうを綿密にメンテすべきではと思っていて、
      そういう意味で今回は必要最低限に対応することにしたわけですが。
      実際に一括で置き換えると画面遷移などで不具合が発生します。
        • 26012
        • 324 Posts
        みなさんこんにちは、sama55と申します。

        1週間ぐらい前から0963-RC2をインストールして評価的に使ってます。
        文字化けではありませんが、ある現象を確認しましたので報告させていただきます。

        1.現象
         0963-RC2でphiEditedonのカレンダーボタンが動かない。

        2.再現手順
         ・0963-RC2にphiEditedonプラグインをセットアップ
         ・テンプレート変数(pe_editedon & pe_update)を使う任意のドキュメントを編集
         ・pe_Editedonのカレンダーボタンをクリック >> 無反応

        3.直接原因
         編集画面のpe_editedonのinputタグおよびスクリプトを調べたところ、アンダースコア("_")がURLエンコーディングされていることに気がつきました。
         HTML上では、"tvpe_editedon"といったシンボルが"tvpe%5Feditedon"に置き換えられています。
         同一のサーバで0962版+phiEditedonも使わせて頂いている関係で、違いに気がついた次第です。

        4.回避方法(暫定?)
         ・テンプレート変数の名称を変更(pe_Editedon >> peEditedon, pe_update >> peUpdate) ※アンダースコアを除去
         ・プラグイン(phiEditedon)設定のUpdate TV nameとEditedon TV nameの名称を上記と同様に変更

        5.その他
         同じ環境で0962で動いていたものが0963-RC2で動かなくなったことから、コアソース(OnBeforeDocFormSave?)の仕様変更ないしはバグではないかと考えてます。
         他の日本語リソースなどにも同じ影響が及んでいるとまずいと思いましたのでコメントさせて頂きました。

        既出の問題であったりスレ違いの場合は、お手数ですが削除や移動をお願いします。
        今後ともよろしくお願いします。
          • 33014 ☆ A M B ☆
          • 1,231 Posts
          ありがとうございます。これも報告しておいたほうがよさそうですね。
            • 33014 ☆ A M B ☆
            • 1,231 Posts
            相談です。

            ようやく文字化け対応のパッチを上げたところなんですが、
            http://svn.modxcms.com/jira/browse/MODX-489
            ディスカッションを求められているようです。正直、それが難しいので自らパッチを作って提供したのですが、
            やっぱり具体的に説明が必要な様子。

            DBAPIのコードを追ってみるとSET NAMES関係の対策が盛り込まれているようなので、差し替えてみれば
            うまくいくのではと思いました。該当のファンクション自体は短いコードで、互換性を考慮して差し替えて
            使うのがむしろ推奨されているように感じたから、というのもあります。ただし僕自身はSET NAMESや
            SET CHARACTER SETといった処理の実態がどういうものか正直よく分かってませんし、そもそも
            MySQL関係の関数はよく理解できてないので、論理的に説明するのは日本語でも難しいです。
            (なので、開発チーム側でdiffなどをとって差分を見るなどして、論理的に検証していただけることを期待してました)

            実際のところ、このパッチを適用しないと国内のいくつかのレンサバでは文字化けが発生するのではと思います。
            それはレンサバ側の設定がイレギュラーだからなんですが、サーバ側のイレギュラーをMODx側で巻き取って
            対応することは可能なようです。今回のパッチは、そのような想定です。ですが、これで動くだろうというのは
            根拠が薄く、乱暴かもしれません。プログラミングに慣れた人のご意見をお聞きしたいです。

            せっかくパッチを作ったところですが、実際のところこのあたり、論理的にはどう対処するのが理想でしょうか。

              • 36592
              • 970 Posts
              MODX-489 のJason氏のコメントを読む限り、mysql_query()関数のままにしておいても「SET NAMES」「SET CHARACTER SET」の設定に基づいて適切に設定がされるから、DBAPIに置き換えても何の意味も無いのではないか? と言っているようですね。

              これって本当なんでしょうか?

              私の認識では、単純に「MODX-185で修正された部分だけでは不足している」という認識です。私もプログラマーではないので技術的なことは良く分かりませんが… あまり難しい技術的な議論にするより、単に修正箇所が不足していると主張した方が分かってもらえるかも? って思うんですが。

              追記:(2008/11/13 12:46)
              短い文章ですが、ポイントだけコメント入れておきました。
                • 33014 ☆ A M B ☆
                • 1,231 Posts
                あ、そうなんですか。Jasonの言ってる内容をよく理解できてなかったみたいです。
                rc2で化けなくなった箇所についてコードを追ったところ、DBAPIに差し替えてありました。
                なので、DBAPIに置き換えたから化けなくなったのだなと、その時は解釈しました。

                でもJasonの考えだと、そこは別の理由でDBAPIに置き換えているということみたいですね。

                とりあえず、どこで文字化けが発生するかを挙げたうえで「まだ対応が必要」と伝えるのがいいかな?
                (ドキュメント編集画面以外のほとんどの箇所で化けますが)

                追記
                コメントありがとうございました。問題個所は、パッチとして上げたファイルのファイル名を見ればJasonなら分かるかなと。
                  • 33488
                  • 429 Posts
                  Quote from: tkfm at Nov 12, 2008, 09:35 PM

                  MODX-489 のJason氏のコメントを読む限り、mysql_query()関数のままにしておいても「SET NAMES」「SET CHARACTER SET」の設定に基づいて適切に設定がされるから、DBAPIに置き換えても何の意味も無いのではないか? と言っているようですね。

                  これって本当なんでしょうか?
                  mysqlを接続後(DB APIでもmysql_connectでも)に、SET NAMESかSET CHARCTER SETを行っているのであれば、以降のMySQLへのアクセスは、直接MySQL関数(mysql_query)でもDB API使っても同じコネクト先に対してなので、結果は同じ=変えても変わらないってことなんじゃないですかね
                    • 27690
                    • 98 Posts
                    にっくです。結構修正点、バグらしき点、上がってますね。

                    とりあえず、現状JIRAに挙げたほうがよいのは

                    ・ファイルマネージャーの修正(我々の提案がベターだと考える、ファイルの文字コード検出自体は難しいが、いずれにせよ管理画面と同じ文字コードでないと文字化けは理論上発生するので、2バイト圏を考慮すると我々の提案がもっとも適切であると考えるのでどうか対応してほしい)

                    ・カレンダーボタンが動かない
                    http://modxcms.com/forums/index.php/topic,29201.msg185203.html#msg185203

                    ・サイトキャッシュが壊れる
                    http://modxcms.com/forums/index.php/topic,30442.msg184931.html#msg184931

                    あたりですかね・・・。

                    上記3件、土曜日の朝までに英訳してアップしますー。
                      • 36592
                      • 970 Posts
                      Quote from: ZeRo at Nov 13, 2008, 12:00 AM

                      mysqlを接続後(DB APIでもmysql_connectでも)に、SET NAMESかSET CHARCTER SETを行っているのであれば、以降のMySQLへのアクセスは、直接MySQL関数(mysql_query)でもDB API使っても同じコネクト先に対してなので、結果は同じ=変えても変わらないってことなんじゃないですかね
                      なるほど、そうなんですか~ 勉強になります。

                      確かに manager/processors/login.processor.php で mysql_connect()した後 SET NAMES/SET CHARACTER SET してますね(20行目~25行目)。このファイルはおそらく管理画面にログインする時必ず実行されるので、以降の管理画面での操作に伴うDBとのやり取りでは、ちゃんと SET NAMES/SET CHARACTER SET が適用されているってことになるわけですね。

                      何かのきっかけでこれがリセット(あるいは変更)されてしまうことってあるんでしょうか?

                      よくよくDBAPIを見てみましたが、SET NAMES/SET CHARACTER SET の関係でDBAPIの修正された点は connect() 関数だけですね。query() 関数は全然変更されていません。だとすると、mysql_query() を $modx->db>query() に置き換えても SET NAMES/SET CHARACTER SET が再実行されてないってことですか? そうだとすれば、何で置き換えると文字化けしなくなるのか理由が付かないですね… undecided