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

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SSMx]

とりあえず、応急処置がおわりましたが手こずりました。
まず、結論からですが、MODx上でUTF8で正常に動くようになる。
MySQL上での文字化けは解決せず。
問題が不可解(サーバー上の要因が大きいため）で、次期サーバーのバージョンアップで解決すると見込んで今回の暫定対処は終了。

対処内容
DBを latian1_swedish_ci で作成
/manager/includes/config.inc.phpの
$database_connection_charset = 'utf8';
↓　utf8を記述しない
$database_connection_charset = '';

解決策を見いだせず、だめもとでやった対処です。
OSCのDBがすべてlatian1になっていたことをヒントに、DBを latian1 で作成しなおす。
以前、config.inc.phpの utf8 を書き込むと文字化け●▼■から????に変わってしまったので、defoultに変える。
（たぶんDB標準のlatianに適した書き込み方になったんじゃないかな？）

ま～とりあえず、MODxのバックアップ機能自体は文字化け起こさないから、新しく環境をかえるときも何も問題ないだろうと思ってます。
そう信じてます。　ってか、あまり考えたくないですね。

みなみなさま、かなりのお時間を投入していただきありがとうございました。
また、大した実績が出せなくてすみませんでした。orz

[soushi]

もう解決されてるかもしれませんが…

僕も最近文字化けを経験しました。
SSMxさんとはちょっと現象は違うしMODxのバージョンも違うのですが、参考になれば幸いです。

http://ayd.jp/p_blog/archive-200806/article-1213119654.html

こちらの文字化けの場合、SET NAMESを書く位置が結構重要だったようです。
正直、原因は良くわかってないです 

[SSMx]

soushi さんわざわざありがとうございます。

とりあえず、oscの方も文字化けしてるので放置。ぶっちゃけ、もういいや、サーバーを変えるときに治るだろう(笑)くらいに思ってます。
で、ちょっと作業量がいっぱいいっぱいで、今はテストが難しいです。

時間見つけ次第、テストをして結果報告させていただきます。

ちなみに、これは

onfig.inc.phpの utf8 を書き込むと文字化け●▼■から?に変わってしまったので、defoultに変える。

に関しての話ですよね。

個人的には、あまりMODx自体のコードは触りたくないところがありまして,,,環境が変わったと時にリストアなくしてMODxを再構築するのが困難になるからです。
ですので、先回までの障害がおこったのを再現する環境を新たに構築しテストするので結果報告はかなり遅めになります。

でも、このスレッド?が誰かの役に立てばと...頑張ってみます。
わざわざ、ありがとうございました。

[tkfm]

最近のSVNアップデートで、こんな話題があり実装された模様です。
私はMySQL関係は全く分からないので話題についていけていませんが、MySQLの設定によっては日本語の文字化けが起こりそうなだぁ～と斜め読みしていました。
詳しい方が読めば、何がどう変わったかわかるのかも?
場合によっては、修正の提案も必要なのかもしれませんが...私には... です。

[SSMx]

英語じゃん orz

...すみません

[kazuike]

■現象の概要
文字「～」（チルダ）が文字化けして「?」になる場合がある。
（文字化けした状態でMySQLデータベースに保存されている。）
文字化けする状況（現在までにわかっている範囲ですが）は以下です。
○ドキュメント新規作成（編集で入力しなおして保存すると文字化けしない）
○チャンク（新規作成も編集も、どうやっても文字化けする）

このスレッドをざっと見たところ、同様の報告がなかったようなので（このスレッド長いので、見落としてたらすみません）、とり急ぎ報告だけさせていただきます。

■化ける文字
今のところ、いくらかテストした結果わかっているのは、
機種依存文字以外では「～」（チルダ）が文字化けするようです。
（丸囲み数字やローマ数字等の機種依存文字も同様に化けます）
「〒」や「←」のような記号でも、機種依存文字以外なら化けないようです。
ちなみに、
Macの「〜」（波ダッシュ）は文字化けしません。

■環境
MODx 0.9.6.1p2
PHP 5.1.6
MySQL 5.0.22（サーバ側デフォルト：EUC）
config.inc.php／$database_connection_charset = 'utf8';
（その他、MODx側は全てutf8（Japanese-utf8）で設定している…はず）
MySQLの各テーブルの当該フィールドは「utf8_general_ci」に設定されている。
ブラウザ：WindowsXP／IE6、および、Firefox2、Firefox3

■ドキュメントの場合の応急的対処法
空で新規作成してから、編集で原稿を埋めて保存する。
ということで、対応しています。

■チャンクの場合の応急的対処法
MODx管理画面で保存した後、
データベースをphpMyAdmin等で直接修正し、サイトのキャッシュをクリアする。
ということで、対応しています。

■原因など
現状では、わかっていません。

急ぎの仕事があるので、とりあえず、上記の方法で逃げていますが、
後ほど、ドキュメントの場合に新規と編集とで結果が違うということをヒントに、
save_content.processor.php等を調べてみたいと思っていますが、
もし、上記の解決策をご存知の方がいらっしゃったら、ぜひお願いします。

※追記）波ダッシュとチルダを混ぜて使ってしまっていたので、修正しました。

[ZeRo]

全角チルダ問題だとすると、
http://bbs.wankuma.com/index.cgi?mode=al2&namber=19703&KLOG=38
辺り参考になりませんか？

[soushi]

こんばんわー。

新規作成(INSERT)で文字化けして更新(UPDATE)の時に文字化けしない現象は僕も一度体験しました。
こちらはSET NAMESを書きまくってなんとか文字化けはしないようになっています。

もし参考になれば
http://ayd.jp/p_blog/archive-200806/article-1213119654.html

それで、原因に関してはイマイチわかっていません 

[kazuike]

soushiさん、Zeroさん
ありがとうございます。

チャンクについては、まだ検証できていないのですが、
ドキュメントに関して、今までわかった範囲でご報告します。

ソースを見た限りでは、新規作成と編集の違いは無いように思いますし、
実際、値を追っかけていっても、INSERT、UPDATEの直前まで正しく入っているようでした。

そこで「save_content.processor.php」の新規作成のINSERTの直前（259行目あたり）に、

Code:

@mysql_query("SET NAMES {$database_connection_charset}");

を入れたところ、新規作成でも文字化けしないようになりました。

次に、この行をコメントアウトして、新規作成を行なったところ、
見事に文字化けしました。

ちなみに、UPDATEの直前でも、同じ事をしてみましたが、
こちらは、入れても入れなくても文字化けは起こりませんでした。
（ま、当たり前ですね？）

MySQLのリファレンスマニュアルの「9.4. 接続のキャラクタセットおよび照合順序」
http://dev.mysql.com/doc/refman/5.1/ja/charset-connection.html
の真ん中あたりに、以下のような記述がありますが、
この違いが、INSERTには影響し、UPDATEには影響しない？
（それとも、単なる不具合なのかも？）

SET NAMES 'x'ステートメントは下記の３ステートメントと等価です。
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;

SET CHARACTER SET xステートメントは下記の３ステートメントと等価です。
SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

取り急ぎ、ご報告まで。

[kazuike]

チャンクについて調べたことを、ご報告します。

チャンクでも、SQL（INSERT、UPDATE）を送信するまでは、正しい値が入っているようです。

そこで、「save_htmlsnippet.processor.php」の
INSERTの直前（42行目あたり）と、
UPDATEの直前（88行目あたり）に、

Code:

@mysql_query("SET NAMES {$database_connection_charset}");

を入れたところ、新規作成でも編集でも文字化けしないようになりました。

当然ながら、上記コードをはずすと、元の通り文字化けします。

取り急ぎ、ご報告まで。

[soushi]

こんにちわ。
多分kazuikeさんも僕と同じ現象のようです。

modxのソース中にSET CHARACTER SETを指定しているところがあるのですが、その下にSET NAMES入れると文字化けは解消されると思います。
ちなみにSET CHARACTER SETの手前にSET NAMESを書いてもダメでした(少なくとも僕の場合は)。

この修正のほうがsql文の直前にSET NAMESを入れていくよりは楽だと思います。
それでも結構修正箇所はありますが
(修正箇所は昨日お知らせしたURLのページに書いています)

取り急ぎ連絡まで。

[kazuike]

soushiさん、ありがとうございます。

soushiさんに教えていただいたやり方で直ることは間違いないと思います。
直そうかと思ったのですが、INSERTとUPDATEで違うというのが、どうも気持ちが悪くって、
せっかくですので、直してしまう前にちょっと調べておこうと…

とりあえず、「save_content.processor.php」のINSERTとUPDATEのそれぞれ直前で、
MySQLの設定値がどうなっているか「SHOW VARIABLES LIKE 'character_set%'」で調べてみました。

INSERTの直前（抜粋）

character_set_client => utf8
character_set_connection => ujis
character_set_database => ujis
character_set_results => utf8
character_set_server => ujis
character_set_system => utf8

UPDATEの直前（抜粋）

character_set_client => utf8
character_set_connection => utf8
character_set_database => utf8
character_set_results => utf8
character_set_server => ujis
character_set_system => utf8

なんと、「character_set_connection」が違っているのです。
なるほど、INSERTで文字化けして、UPDATEで文字化けしないわけです。
でも、どうしてこんな違いが生まれたのだろう？
というか、なんで「character_set_database」が違うのか？？？

MySQLのリファレンスマニュアル
http://dev.mysql.com/doc/refman/5.1/ja/charset-connection.html
の「SET CHARACTER SET」の説明の中に

SET CHARACTER SET xステートメントは下記の３ステートメントと等価です。
----
SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;
----
collation_connectionを指定するとcharacter_set_connectionも照合順序に関係するキャラクタセットに指定されます(SET character_set_connection = @@character_set_databaseを実行することと同様)。

とあるので、「SET CHARACTER SET」によって、「character_set_connection」が「character_set_database」と同じ値に設定されているようですが…

[kazuike]

さらに、UPDATEの際、「save_content.processor.php」のどこでMySQLの設定が変わるのか調べてみました。

「save_content.processor.php」の407行目

Code:

$was_published = $modx->db->getValue("SELECT published FROM $tblsc WHERE id='$id'");

を通った後で、MySQLの設定が変わっています。
つまり、DBAPI（manager/includes/extenders/dbapi.mysql.class.inc.php）の接続を使った（接続した？）後では、
MySQLの設定が変わっています。
ざっとソースを見た限りでは、「SET CHARACTER SET」も同じように設定しているように見えるのですが…

[kazuike]

とりあえず、私として導き出した結論は、

PHPの「mysql_select_db」は、与えられたデータベース名がバッククォートで囲まれていると正しく動作しないらしい。

ということです。
PHPマニュアルには、残念ながらそのあたりは載ってませんね。
http://jp.php.net/manual/ja/function.mysql-select-db.php

MODxの中でも、mysql_select_dbを使う箇所では、
たいていの箇所でバッククォートを削る処理を入れています。
（ってことは、MODxでは、データベース名に「create」等のMySQL予約語は使えないってことですね）（※２）

例えば、DBAPI（manager/includes/extenders/dbapi.mysql.class.inc.php）も、
mysql_select_db直前の91行目で、バッククォートを削っています。

Code:

$dbase = str_replace('`', '', $dbase); // remove the `` chars

残念ながら、管理画面の「manager/index.php」等、何箇所か、これをやっていないところがあります。
そのため、「character_set_database」が壊れて、文字化けの不具合が出ていると思われます。

で、一番簡単な対処方法は「manager/includes/config.inc.php」の10行目あたりの

Code:

$dbase = '`hogehoge`';

の2つのバッククォート「`」を削って、

Code:

$dbase = 'hogehoge';

とすることですね。

なお、この現象、および、対処法の対象となる環境は、（私のわかる範囲では）以下です。

MODxの設定をutf8にしていて、MySQLサーバー側のデフォルトがutf8以外、さらに、
MODx用のデータベースを「utf8」で設定（character_set_databaseをutf8に）している場合、
多くの場合で、全角チルダ「～」や機種依存文字が「?」に化ける。
（ドキュメント新規作成では化け、編集では化けない。チャンクは新規も編集も化ける。等）

ちなみに、設定値を調べるには、phpMyAdminやコマンドラインから、
MODx用のデータベースに対して、SQLで「SHOW VARIABLES LIKE 'character_set%';」を実行します。

あと、参考までに…

対処方法として考えられる方法に、
mysql_select_db直前で、バッククォートを削る以下の行を挿入する。

Code:

$dbase = str_replace('`', '', $dbase); // remove the `` chars

ということが考えられます。

MODx0.9.6.1p2では、「mysql_select_db」を使っている箇所が15箇所あり、
そのうち、上記の対応済みと思われるものが9箇所、
以下の6箇所が未対応と思われます。（使われてなさそうなものも含む）
--------
manager/index.php(140):
manager/includes/document.parser.class.inc.php(2480):
manager/includes/veriword.php(79):
manager/media/browser/mcpuk/connectors/php/config.php(49):
manager/media/ImageEditor/config.inc.php(22):
manager/processors/login.processor.php(23):
--------
ちなみに、以下の2箇所に関しては、現状では呼び出し側で対応しているようです。
--------
install/sqlParser.class.php(28):
manager/actions/bkmanager.static.php(269):
--------

（※１）タイトル変えました。
（※２）データベース名にMySQL予約語を使っても大丈夫そうです。

[soushi]

そうしです。

kazuikeさん、細かい検証ありがとうございます
う~ん、バッククォートのあるなしで動作が変わるのは困ったものですね。
バグのような気もしますが、どうなんでしょう。

気分的にはバッククォートをすぱっと取り除きたいところですが、バッククォートがないとデータベース名に"-(ハイフン)"が含まれている場合にエラーになっちゃうんですよね。
でもMODx内部でバッククォートの取り扱いがまばらだったって事は"-(ハイフン)"付きのデータベースを使っていたら動かなかったって事か。。。
ただ、データベース名に"-"入れる人ってあまりいないような気もしますが

ちなみに僕のときはサーバからクライアントまで全部UTF-8で統一したときはこの文字化けは発生せず、サーバ側のデフォルト文字コードがShift_JIS、作ったDBとクライアントの文字コードがUTF-8の時に文字化けが発生してました。

あとちょっと関連してるかは不明ですが、kazuikeさんのMySQLのサーバ側デフォルト文字コードがEUC(ujis)だということなので。。。
僕は以前UTF-8なMySQLにDBダンプデータをリストアした際にダンプデータの中に"character set ujis"が紛れ込んでいて、全角チルダ"~"が"?"になったりしたことがありました。
そしてMacの「〜」(波ダッシュ)は文字化けしません。
このときはダンプデータの中のcharacter set ujisを片っ端から消してリストアして事なきを得ましたが、文字化けのタイプとしてはkazuikeさんの方と似てる気がします。

[参考]
http://ayd.jp/p_blog/archive-200702/article-1171908362.html