On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • はじめまして。

    0.9.6.2系で「サイトのインポート」を行うと、日本語が文字化け(クエスチョンマーク"?"になる)してしまいます。
    SVNから最新版(リビジョン4159)を持ってきて試したのですが、同様の結果でした。

    0.9.6.1では正常にインポート可能でしたので0.9.6.2系の問題と思うのですが、同様の現象が発生している方はいらっしゃいますか?

    なお、テスト環境は、php5.2.5, MySQL4.1.20max, apache2.2.6 です。
    • インポート機能って全然使ったこと無かったんですが、初めて使ってみました。

      Yahoo!のTOPページのソース(文字コードはUTF-8)をローカルに保存して、
      これをMODxの「assets/import」にアップロードして、
      管理画面からインポートしてみました。

      そしたら普通にインポートできましたよ~
      管理画面上もFrontendからも文字化けは有りません。

      もともとアップロードしたHTMLファイルの文字コードとかがまずかったとか?
      • tkfmさん、ご確認ありがとうございます。文字化けしませんかー。

        HTMLファイルは処理時間を計測したかったので、自分でビルドしたphpマニュアル(UTF-8)を使用しました(7500ページほど)。
        改めてyahooのトップページを保存して試したのですが、同じく文字化けします。0.9.6.1p2だと大丈夫。

        テスト環境はVMwareにて構築してあり、0.9.6.1p2をインストールした仮想マシンをコピッてMODxだけリビジョン4159にインストールしなおしてます。なので両者の環境は同じです。なぜでしょうね?

        ちなみに文字の化け方は、4106で対応されたようなパターン(Webブラウザでマルチバイト文字をISO-8859-1で開いたときのようなやつ)でなく、日本語がすべてクエスチョンマークになるというものです。ちょうど、オラクルでNLS_LANGを設定し忘れた時のような感じです。

        今回初めてMODxの仕事を受けるので、どのバージョンを使うか検証しているところで、この文字化けに会ってしまいました。tkfmさんは、どのリビジョンを使用されてますか?
        • Quote from: hisawo at Sep 26, 2008, 05:08 AM

          今回初めてMODxの仕事を受けるので、どのバージョンを使うか検証しているところで、この文字化けに会ってしまいました。tkfmさんは、どのリビジョンを使用されてますか?
          私が確認したのはSVN版のrev.4158です。
          私はプロのシステム屋さんじゃないので安定性とかは度外視してまして、
          常に最新の情報だけ追っかけてるような状況です...

          インポートは「manager/actions/import_site.static.php」がやっていると思うんですが、
          このファイルはrev.2588以来変更されていないんですよね。
          しかもDBとのやりとりはmysql_query()関数で直接やってるみたいですし。
          ですので、0.9.6.2のバグの影響はないと思ってますが...?

          soushiさんのこの記事のようなことをしないといけないのかなぁ~?
          プログラミングは全然分からない人なんで、このあたりはプロの方からコメント頂きたいです~ tongue
          • tkfmさん、たびたびありがとうございます。
            なるほど、インポート機能は0.9.6.2のバグとは関係なさそうですね。それに使われているリビジョンはほぼ同じなので、インフラ系が原因っぽいですね。

            そしてご紹介いただいた記事、とても参考になります。確かに、ターミナルから mysql コマンドで接続するとき、"SET CHARACTER SET utf8;" しておかないと、日本語がクエスチョンマークになります。

            また、私のテスト環境は MySQL4.1なんですが、4系はUTF-8の扱いが不安なので5系にした方がいいんじゃない?と同僚にアドバイスされました。

            というわけで、改めて環境から作り直して調べてみます。進展がありましたら、ここで報告させていただきますね。
            • 確か以前どこかで議論があった記憶があるのですが思い出せない... :’(

              管理画面内蔵のファイルマネージャなんですが、
              UTF-8でエンコードされた日本語を含むファイルを見たりすると文字化けしませんか?

              manager/actions/files.dynamic.php の 573行目に以下のコードがあるんですが、
              この関数で文字コードを指定していないのが原因のような気がします。
              <?php echo htmlentities($buffer)?>


              以下のように変更すると上手く行くようですが、これだけで良いんでしょうか?
              <?php echo htmlentities($buffer,ENT_COMPAT,$modx_charset)?>
              • Dittoの日本語(マルチバイト文字)文字化け対応について、
                まともにDittoを改造するとなるとどうなるか?
                「substr」を「mb_substr」に変える等の程度で対応させることが可能なのか?
                ちょうど、RSS出力を使う機会があったので、その部分で試してみました。
                (MODx0.9.6.1p2で試していますが、現時点では0.9.6.2も同様のはずです)

                ちなみに、PHxを使うのではなく、Dittoのデフォルト動作の改造ですので、
                こちらの「DittoでRSSが上手く吐き出せない」
                http://modxcms.com/forums/index.php/topic,20855.0.html
                での対策とは、ちょっと違うアプローチになっているかと思います。

                今回、改造の対象としたのは、上記の記事でも指摘されていますが、
                DittoのRSS出力では、要約(introtext)が入力されていないドキュメントでは、
                内容(content)が[+summary+]として「description」タグに使われます。
                その際、デフォルトでは半角300文字(=300バイト)でカットされますが、
                日本語等のマルチバイト文字に対応していないため、
                300バイト目が日本語等のマルチバイト文字だった場合
                1文字の途中でぶちきってしまうので、ありえない文字コードになってしまいます。
                たいていのRSSリーダーでは、文末がちょっと文字化けする程度で大きな問題にはならないでしょうが、
                IE7では、これがエラーになって使えなくなってしまいます。
                (ちなみに、パラメータにより、300文字の制限は変えられます)

                これに該当する箇所は、
                assets/snippets/ditto/extenders/summary.extender.inc.php
                の213行目~225行目の「truncate::textTrunc」メソッドです。
                	function textTrunc($string, $limit, $break=". ") {
                	// Original PHP code from The Art of Web: www.the-art-of-web.com
                
                	    // return with no change if string is shorter than $limit
                	    if(strlen($string) <= $limit) return $string;
                
                	    $string = substr($string, 0, $limit);
                	    if(false !== ($breakpoint = strrpos($string, $break))) {
                	      $string = substr($string, 0, $breakpoint+1);
                	    }
                
                	    return $string;
                	}
                

                日本語等のマルチバイト文字(ここではUTF-8)に対応させるには、以下のような改造になるかと思います。
                213行目)「$break=". "」を「$break="。"」に変更。(*1)
                215行目)「mb_internal_encoding("UTF-8");」を追加。(*2)
                217行目)「strlen」を「mb_strwidth」に変更。
                219行目)「substr」を「mb_strimwidth」に変更。
                220行目)「strrpos」を「mb_strrpos」に変更。
                221行目)「substr」を「mb_substr」に変更。

                こうみてくると、
                単純に「substr」を「mb_substr」に変えるだけでは、
                必ずしも動かない
                可能性があることがわかります。
                さらに、この上位にあたる「truncate::html_substr」にも手を加えてみましたが、
                200行目のカウントアップの処理[$c++;」は、
                「$c+=mb_strwidth($current_char);」のように置き換えないと、
                正しく文字の幅がカウントされないなど、
                文字列関数だけに着目してもダメだということがあります。

                ちなみに、必ずしも「全角=2バイト」ではありませんので、
                表示上の文字数の計算と、文字中の文字の位置の計算は別になり、
                「mb_strlen」と「mb_strwidth」、「mb_substr」と「mb_strimwidth」等を使い分けることが必要になります。

                ★「mbstring拡張モジュール」を前提にしているので、
                 この改造を行なってしまうと、当然ながら、
                 このモジュールが有効になっていない環境では動かなくなります。
                 (欧米のサーバ等では使えないんだろうなぁ…)

                (*1) この変更は、今回の目的とは直接関係ないですが、
                  元が最後のピリオドで止めるという処理だったので、これを句点に変更しました。
                (*2) 「mb_internal_encoding("UTF-8");」は、
                  本来から言うと、下記の言語ファイルに入れたほうが良いかもしれません。
                  assets/snippets/ditto/lang/japanese-utf8.inc.php

                前述の箇所の改造後のソースは以下になります。
                	function textTrunc($string, $limit, $break="。") {
                	// Original PHP code from The Art of Web: www.the-art-of-web.com
                	    mb_internal_encoding("UTF-8");
                	    // return with no change if string is shorter than $limit
                	    if(mb_strwidth($string) <= $limit) return $string;
                
                	    $string = mb_strimwidth($string, 0, $limit);
                	    if(false !== ($breakpoint = mb_strrpos($string, $break))) {
                	      $string = mb_substr($string, 0, $breakpoint+1);
                	    }
                
                	    return $string;
                	}
                
                  ★日本公式フォーラム2009年9月1日本格始動!★
                  http://modxcms-jp.com/bb/

                  ▼ウェブ屋のCMS→modxヒキダス流(備忘録)
                  http://d.hatena.ne.jp/hikidas_ikeda/
                  ▼制作済みHTMLページをmodxで更新するデモ
                  http://www.hikidas.com/hikidas/modx_document/modx_demo_osc2009kansai.php