メール送信以外で文字化けなどの現象を報告するスレ

この問題は相当困難かと思いまして、時間をかけながらじっくりやって行こうと思います。成果が上がり次第報告します。
MODxのサイトをEUCで作成し、のちにデーターベース、MODｘともにUTFに切り替えるなんて芸当はできるのでしょうか？

http://memo.xight.org/2007-02-14-1
http://hain.jp/index.php/tech-j/2007/02/13/%EF%BC%B0%EF%BC%A8%EF%BC%B0%E3%81%AE%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91
上記サイトはかなり驚がくでした。
ちょっとエンコードの問題は手に負えないなぁ

ん～、原因がわかりませんが、多分MySQL周りとPHPの設定じゃないかと・・・。
ちなみに、Land.toではEUC-JPで３つサイトぐらい作ったことがあります。
今動いているのは、http://feeds.oh.land.to/ ですが・・MySQLが4.0台なのがEUC-JPの理由だったりします。

EUC-JPからUTF-8へは、EUC-JPのMySQLのデータをエクスポートしてSQL文を修正するのと文字コードをUTF-8に直してインポートし直せばいけます。
エクスポートでEUC-JPで文字化けするようだと駄目かも・・。

ちなみに、フロント側（ユーザ側）から表示させるとドキュメントの文字化けはないんでしょうか？

Quote from: SSMx at Apr 28, 2008, 06:21 AM

この問題は相当困難かと思いまして、時間をかけながらじっくりやって行こうと思います。成果が上がり次第報告します。
http://memo.xight.org/2007-02-14-1
http://hain.jp/index.php/tech-j/2007/02/13/%EF%BC%B0%EF%BC%A8%EF%BC%B0%E3%81%AE%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91

こんにちは。私も上記サイトを読み、一から勉強したいと思います。。
情報どうもありがとうございます。

詳しいことは、私にはわかりませんが、

1.私の環境の問題だ、と考えるより、MODｘ側のロジックの問題と捉えることができます。

これはあり得ると思います。

MEGUさん
お写真変えられたのですね。ちょっと前の猫のイメージとのギャップでびっくりです(笑)
男性かと思ってました、失敬（だって野郎ばっかりの世界かと Cry）

はい。たぶん、セミナーや、OSCでお会いした方以外には、男性と思われてるなと思ってました。
それでも良かったのですが、海外で、投稿したとき、レスがつきやすいようにと思って（？爆）
写真を変えてみたのです。

Zero師匠、ＭＥＧＵさんありがとうございます。

ドキュメントに関しては、マネージャー側通りにユーザーも見えます。
なんか、ブログの方にも書きましたが、完全に文字情報を失っているみたいですね。
php.iniのutfやらeucをいじっても変わる気がしない...先回あげたリンクからも直接的な問題じゃないような...まだわかんないですけど。

ZeRo師匠にお伺いしたいのが、すぐに必要になるわけではないですが、SQL文の修正とは何のことでしょうか？
結構大事で、EUCでサイトを構築していくにも、いずれUTFに変更できなければEUCで作っていくには怖い...
EUCでつくれば、システム問題の解決が速そうで、本題(サイト構築)に注力できる。しかし、将来UTFに移行できるか超不安です。
UTFでつくれば将来性があるけど、システムの問題に引っ掛かり本題にいつまでも着手できない... :’( :’( :’(

1.私の環境の問題だ、と考えるより、MODｘ側のロジックの問題と捉えることができます。

まぁいずれにしてもこれは現行、大きな支障がなかったとしても、ここだけ(ドキュメント部)共通化されてないのは問題ですよね


MEGUさん、写真いいですよ！ 親近感が湧きます（前の猫もかなりインパクトありましたが）
ZeRoさんは以前、Blogで親身に教えて頂きましてもともと親近感があります(笑)

MODｘのロジック問題の件ですが、もし仮にそうだとした場合にはその部分はかなり基本的な部分だと思うので、すでに同じような問題が起こっていてよいはずかと思います。
なので、まずは環境の問題と捉えて切り分けをしてみるのがよいかと思います。
管理画面では、前回書いたような気がするんですが、mysqlへの接続がmanager/index.phpで行われてアクションごとにそれぞれの処理ファイルを呼び出します。
なので、MySQLへのアクセスはそれぞれアクションごとにテーブルや与える値も違うわけですが、共通の方法でMySQLへはアクセスしています。
まあ、その与える値の加工がおかしければそれがロジックの問題っていうことにはなるんですが・・・、ということで
ちょっとテクニカルにはなりますが、こういうときの原始的な方法でまずはどこでおかしいかを探ってみましょう。

システム設定においては、manager/processors/save_settings.processor.phpでMySQLに設定情報を保存しています。
35行目付近のmysql_queryがその部分なんですが、その前の行にecho "SQL=".$sql; と埋め込んでMySQLに保存する予定のSQL文を表示させてみてください。
ついでに、その行にvar_dump($_POST); も加えれば、入力した文字がvar_dumpで、それを元に作ったSQLがSQL=の後に表示されるはずです。
ここで、var_dumpとSQLが文字化けせずに表示されれば、MySQLの問題であり、この時点で文字化けしているのであればphpの設定の問題かと思われます。
同様にドキュメントの保存は、同じディレクトリのsave_content.processor.phpです。
ドキュメントの場合は、新規・修正・削除のアクションがあるので長いんですが、最終的にはinsertかupdateのSQL文を吐き出します。
今回は修正の箇所だけでとりあえずチェックしてみてください。　440行目のmysql_queryの直前にシステム設定と同じような感じでデータのチェックをしてみてください。

ここで、ドキュメントとシステム設定に違いがあればより詳細の情報を取得して原因を突き止める必要があります。
同じ日本語文字列でどちらの値にも使うとよいかと思います。（同じ文字なのに、どこかで違いが出る）
var_dumpではOKで、sqlではNGだった場合はそのSQLを生成する過程でNGにさせている部分があることになります。
そういう場合は、適当にソースをみてもらってSQL生成に使っている変数なんかをechoかvar_dumpで出力させてみて、範囲を狭めていくとどこら辺が怪しいか見当が付くかと思います。
PHPの設定だった場合には、はじめから化けてそうな気がします。
変な文字に変換されるという今回の事象だと、やっぱMySQLのクライアントの文字コードとDBまたはテーブルの文字コードの違いじゃないかなと思うわけですが、そうであるかどうかを探るには上記のような切り分けが必要です。

ということで、まずはSQL文自体が問題なのか、それともMySQLに日本語入れたのに取り出すと化けるのか（MySQLの保存の問題か）を切り分けましょう。

－－－－－－－－－－－－－－－－－
SQLの修正についてですが、phpMyadminでエキスポートした際にはSQL文に文字コードが記載されている場合があります。（CREATE文に対して）
バージョンによりますが、MySQL4.1系を使っているなら多分文字コードついた形で吐き出されると思います。
euc-jpだった場合には、この文字コードにujis（だと思う）が入っているので、これをutf8_generic_ciとかにします。
それとファイルの保存時に文字コードをUTF-8にすることで、一応utf8版のSQLになります。

mysql側の対処は、SQL文を上記のように直して新しいDBはちゃんとUTF-8の設定にすればいけるはずです。
同一マシン上で、同じDBを入れ替えるっていう手はエクスポート後削除してDB作り直してインポートってことになるので、かなり慎重にやらないといけません。
できれば、別の環境へ移行の方が最悪新しい方がミスってもまたeuc-jp環境から引っ張ってこれるのでよいのですが・・・。



ということで、頑張ってください。

はじめましてー。

僕のサイトは以前EUC-JPで動作しているところをサーバを移す際、UTF-8に切り替えてます
移設の際は文字化けしまくったり苦戦した記憶があるのですが、とりあえず移行はできます。

参考までに当時の覚書です。
http://ayd.jp/p_blog/archive-200702/article-1171908362.html

あと文字化けの件です。
DB内でも文字化けしているとありますが、ここでは「??」という感じで文字化けされてるのでしょうか?
それとも意味不明な文字になっているのでしょうか…。
(流し読みしたのでもうどこかで書いてたらすいません)

ZeRo師匠、ありがとうございます。かなり、神の領域かと...
ちょっとがんばりますので、１～２日ください。
SQLは分かりやすかったです。(前半も理屈的には分かりました、少しは )
環境の移行は、最悪DBをもう一つ準備して、構築後、/manager/includes/config.inc.php をいじって切り替えるとか。(出来そうですよね？)

soushiさん
このページ見に来たことがあります!!
参考にさせて頂きます。文字化けは完全な？？？？です。(本来は半角です)
文字化けなんだけど、文字情報を失ってるみたいです。

遅くなりました。save_settings.processor.phpの35行目　save_content.processor.phpの440行目に

をいれました。ちょっとvar_dump($_POST);
どこでこの結果が表示されるのかさえなぞだったのですが(笑)、デフォルトのサイト名に”テスト”という日本語を追加して保存したところ

["site_name"]=> string(21) "My MODx Siteテスト"
(’site_name’, ’My MODx Siteテスト’),

と表示されました。

この結果が、save_settings.processor.phpによるものなのかsave_content.processor.phpによるものなのかは分かりかねます
ただ、どこみても　"SQL="　が表示されていないところをみると、ZeRoさんの思惑通りの結果が出力されているか謎です。　echo が入っておらず。

リソース/ユーザ関係は、何も表示されませんでした。
つまりはsave_settings.processor.phpやsave_content.processor.phpのロジックは使用していないってことですね。

ドキュメントの保存は

["pagetitle"]=> string(33) "MODx CMS Install Successテスト"
pagetitle=’MODx CMS Install Successテスト’

が表示されました。

これ以後は、完全にMySQLに渡しているとしたら、MODxの問題じゃないですよねぇ。

phpの設定です
mbstring.detect_order SJIS,EUC-JP,JIS,UTF-8,ASCII
mbstring.encoding_translation Off
mbstring.func_overload 0
mbstring.http_input pass
mbstring.http_output pass
mbstring.internal_encoding UTF-8
mbstring.language Japanese

すこし、不可解なことが。
やはり、MySQL側のMODx用のDB、及び各フィールドは正しく文字コードが設定されています(utf8_general_ci)

気になるところ１　MySQLのサーバ変数と設定値
character set client utf8
(グローバル値) latin1
character set connection utf8
(グローバル値) latin1
character set database latin1
character set results utf8
(グローバル値) latin1
collation connection utf8_unicode_ci
(グローバル値) latin1_swedish_ci

http://anigon.net/frei/archives/2007/01/post_422.php
を見ると、改めてconfig.inc.php が気になりました。
とりあえず、utf8を消してディフォルトに戻すと
リソース関係は一切表示されない(空っぽ)。保存してもMODx上[結果はありません]と表示される。
しかし、MySQLを覗くと保存されています。

サイト名や、ユーザー名の文字化けはMODｘ上では正しく表示されるようになりました。
しかし、MySQLを覗くと、リソースを含め全て文字化けしています。

ちなみに、フィールドをEUC(ujis_japanese_ci)に変えて書き込んでみましたが、書き込まれたデータは文字化け、MODxの症状は変わらずです。

ただ、分かったのはconfig.inc.phpをutf8に戻したとたん
1.リソース系がMySQLからMODxへ表示されるようになった。
2.書き込まれる文字情報が壊れるようになった。ã?†ã？？ã？？ とかじゃなく ？？？？に統一される

参考にして頂けたらと思います。

申し訳ありませんが、明日は一日ではらってレスがかけません :’(

Quote from: SSMx at May 02, 2008, 03:34 AM

ただ、どこみても　"SQL="　が表示されていないところをみると、ZeRoさんの思惑通りの結果が出力されているか謎です。

ですよ～