We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36592
    • 970 Posts
    Quote from: yama at Nov 04, 2008, 08:46 AM

    「MODx設定」はactions/mutate_settings.dynamic.php が制御しているようなのでこのファイルを観察中です。
    MODx設定は、DBからの設定されたデータの読み出しを「manager/actions/mutate_settings.dynamic.php」が行っていて、DBへの保存は「manager/processors/save_settings.processor.php」が行っているようですね。

    どちらのファイルもDBとのデータのやり取りは「mysql_query()」関数を直接使っていて、先の SET NAMES/SET CHARACTER SET の設定を使えるようにした変更が利いていない(MODxのDB-APIを利用していない)状態のようです。

    MySQLは門外漢なので良く分かりませんが、「SET NAMES/SET CHARACTER SET」に関する変更と同様にMySQLのクエリーを飛ばす前に適切に「SET NAMES/SET CHARACTER SET」を1行挿入してあげれば直るのかも?
      • 33014 ☆ A M B ☆
      • 1,231 Posts
      save_settings.processor.phpですか。このファイルは70行足らずのようなので、なんとか
      試行錯誤できそうな感じです。見てみると、たしかにmysql_xxxxx関数を使ってますね。
      0963になってDB-API利用への書き換えがどんどん進んでる印象を受けましたが、このファイルは
      まだ手つかずなのかな?ちょっと調べてみます。
        • 36592
        • 970 Posts
        Quote from: yama at Nov 04, 2008, 07:23 PM

        DB-API利用への書き換えがどんどん進んでる印象を受けましたが…
        いやいや、むしろDB-API利用の方が少ない印象があります。

        試しに、manager以下のディレクトリで「mysql_query」をgrepしてみて下さい。
        ものすごくたくさん出てきますよ~

        コアに限らずSnippet等のサードパーティ部品でも、「mysql_query」を直接使ってるものは多いです。
        日本語が扱われる場合は、これら全部に適切に「SET NAMES/SET CHARACTER SET」しないとダメなんじゃないでしょうか?
          • 33014 ☆ A M B ☆
          • 1,231 Posts
          Quote from: tkfm at Nov 04, 2008, 09:18 PM

          いやいや、むしろDB-API利用の方が少ない印象があります。

          試しに、manager以下のディレクトリで「mysql_query」をgrepしてみて下さい。
          ものすごくたくさん出てきますよ~
          調べてみました。ほんとだ、たくさんありますね。0962の時と比べると何十ヶ所か置き換えが
          進んでるみたいですが、まだ数百ヶ所あるみたい。
          とりあえずDBAPI差し替えで試してみます。
            • 33014 ☆ A M B ☆
            • 1,231 Posts
            さっそくですが報告です。DBAPI差し替えで文字化け解決しました。
            (set namesを個別に仕込むよりはスマートな解決方法かな?)

            あとでjiraにパッチを上げますので、その時に詳細を報告します。

              • 33014 ☆ A M B ☆
              • 1,231 Posts
              対象ファイルが思ったよりも多かったので、先にこちらで公開して感想を求めます。
              mysql_query関数の一部を$modx->db->queryに置き換えました。
              これらをrc2に上書きして、スニペットやプラグインの「説明」やコード本体に
              日本語を記述して化けないかどうか、どなたか確認をお願いできますでしょうか。
              カテゴリー名の日本語も確認をお願いします。

              http://modxcms.com/forums/index.php/topic,20957.msg178473.html#msg178473
              あと、こちらの問題も未解決ですね。
                • 36592
                • 970 Posts
                yamaさん、ご苦労さまです~

                Quote from: yama at Nov 05, 2008, 10:17 PM

                これらをrc2に上書きして、スニペットやプラグインの「説明」やコード本体に
                日本語を記述して化けないかどうか、どなたか確認をお願いできますでしょうか。
                カテゴリー名の日本語も確認をお願いします。
                基本的に、MySQLサーバ/データベース/テーブルと全ての設定をUTF-8で揃えちゃってるんで、
                逆に今文字化けを起こせる環境がありません~ tongue


                http://modxcms.com/forums/index.php/topic,20957.msg178473.html#msg178473
                あと、こちらの問題も未解決ですね。
                そっちは、Jason氏から「その変更じゃMODxで使ってるエンコードと同じエンコードのファイルしか読み書きできないだろ」と指摘を受けています。いや、そのとおりなんですけどね... 現実問題として、例えばUTF-8で運用しているMODxの管理画面から、EUCやShiftJISのファイルを読み書きすることは無いんですが、完全な対策かと言われればそうではないですし。

                リストボックスとかで文字エンコード方式を選んで各ファイルを開くようなインターフェースにするのが一番なんでしょうけど、どうすればできるのかは私にはわかりません。ファイルを読み込んだときに自動で文字エンコード方式を推定するなんてことは、そんな簡単なことではないんでしょうかね~?
                  • 33014 ☆ A M B ☆
                  • 1,231 Posts
                  どうもです。文字化け問題もなくちゃんと運用できてる状態ででも見ていただけると助かります。
                  というのは、最初は全てDBAPIに置き換えてみたのですが、それだと画面遷移で問題がある
                  ケースが出てきたので、結局ひとつずつ検証しながら書き換えたので。文字化け対応自体は
                  たぶんこれで問題ないと思うので、保存ボタンをクリックした後の画面遷移が確認できれば
                  さらに安心かなと思います。

                  そもそも、チカッパのMySQL5の設定自体がイレギュラーなんだと思います。MySQL5の扱いに
                  慣れてないレンサバ業者が今は多いと思うので、今後しばらくこういうことが他のレンサバでも
                  起きるのかもしれません。

                  jiraの件ですが、結局のところファイルマネージャの日本語読み書きをするには、今の時点で何か
                  対応しないと、ここをハックしないとちゃんと使えないのは確かなことですよね。だったら現実的な
                  解決として、jiraに上げた$modx_charsetで合わせる方法で今回は対応して、他のエンコードの
                  ファイルも扱いたいという人だけ、必要に応じてハックさせればいいんじゃないかと思います。
                  実際のところ、そういう人のほうが少数派でしょうし。
                  でも今は、そのハックの仕方自体をこれから考えるという段階ですしね。

                  今は「同じエンコードのファイルの読み書きしかできない」ということにしておいて、次のバージョンアップで
                  「異なるエンコードのファイルをシームレスに扱えるようになったよ!」ということにできればいいのではと。
                  そうすれば今困ってる人も含めて、みんな喜ぶ。

                  エンコードの自動推定はある程度は可能ですが、完全には無理ですね。必要に応じてリストボックスから
                  選択し直すことができる作りになるのではと思います。UIから作らないといけないから、このへんちゃんと
                  考えるならずっと先の話になるでしょうね。
                    • 36592
                    • 970 Posts
                    Quote from: yama at Nov 06, 2008, 04:07 AM

                    どうもです。文字化け問題もなくちゃんと運用できてる状態ででも見ていただけると助かります。
                    やってみました。
                    関係有りそうなアクションは一通り試したつもりですが、特に文字化けはありませんでした。
                    DBの中も一通り覗いてみましたが、正常な日本語で表示されています。


                    そもそも、チカッパのMySQL5の設定自体がイレギュラーなんだと思います。MySQL5の扱いに
                    慣れてないレンサバ業者が今は多いと思うので、今後しばらくこういうことが他のレンサバでも
                    起きるのかもしれません。
                    そうですね~ 特にMySQLサーバ自体のcollation(MySQL自体の設定ファイル(my.cnfでしたっけ?)に記述しなければならない設定)がデフォルトのままだとlatin1_swedish_ciだったりするんで、そこはユーザーからは触れなかったりしますもんね。ユーザーが声を上げて指摘するしかないですね~ まぁ、MySQLのバージョン自体が未だに4.0系だったりするところも多いですから...


                    今は「同じエンコードのファイルの読み書きしかできない」ということにしておいて、次のバージョンアップで
                    「異なるエンコードのファイルをシームレスに扱えるようになったよ!」ということにできればいいのではと。
                    そうすれば今困ってる人も含めて、みんな喜ぶ。
                    私もそう思います。けど、26文字のアルファベットで事足りる世界の方々にそれがご理解頂けるのかな~?
                      • 33488
                      • 429 Posts
                      アップロードの日本語名対応ですけど、そういえば古いバージョンでやった記憶が・・。
                      ま、やり方はテンポラリから移動する際のファイル名を文字コード合わせこんだだけですが・・。
                      けど、OSの文字コードとMODxの文字コードがあってないと、えらい目(削除できないOS上変なファイル名なったり)あうので微妙な気が・・。
                      最終的には、日本語だったら英字に直しちゃうようなパッチを充てちゃいました。