MySQLコミュのMySQLで文字化けする

はじめまして。あとむといいます。

早速ですが、LinuxにMySQLをいれた環境で携帯サイトを運営しています。絵文字を扱いたいので、文字コードはShift_JISでそのまま保存をするようにしています。

最近ちょっとハマっていまして、「廿日市」という地名をﾃﾞｰﾀﾍﾞｰｽに登録したところ、その文字以降が化けています。
自分で調べたところ、「廿」や「日」のそれぞれだけだと化けませんが、「廿日」のように組み合わせるとそこを拠点に文字が次々とばけてしまいます。

こういう事態を解消するには、読み書きの段階でどのような対処をすれば良いでしょうか？要因などをご教授いただけると助かります。

コメント(15)

最初
全て
最新の40件

[1] mixiユーザー 12月08日 10:55

お使いのバージョンを記載して頂かないと、
明確な回答は期待できないと思います。

[2] mixiユーザー 12月08日 13:42

そうなんですね。MySQL version 3.23.58です。これで何かわかります？

[3] mixiユーザー 12月08日 13:47

mysql側のcharacter_setなど関係しているような・・・

↑つづりあってます？ｗ

[4] mixiユーザー 12月08日 14:35

MySQL 側で文字コードの変換はやってはいけないと思いますよ。

例えば、PHP4からMySQLを呼び出すときは、PHP4の内部コードはEUC-JPにしていると思うので、MySQLもEUC-JPで保存しないといけないと思います。

[5] mixiユーザー 12月08日 15:08

フォームから受け取ったデータ文字コードの変換は一切行っていません。
Shift_JISのフォームからShift_JISで送信されﾌﾟﾛｸﾞﾗﾑで受信し、そのままMySQLのﾃﾞｰﾀﾍﾞｰｽにinsertしています。読み出したときもそのままにしています。

このような動作だけでも内部で（自動かなにか）で変換されてたりしますか？

[7] mixiユーザー 12月08日 18:32

PHPのバージョンやビルドオプションによっては、SJISでの統一が不可能な場合もあります。
PHP 4.3移行で、かつzend-mutibyte有効、script encoding指定してShift JISで統一するってなことをしたとしても、addslashesなどSJISセーフでない関数もありますからね・・・。あまりSJISで統一するのはお勧めできないかと。携帯サイトのようなので絵文字を使いたいとかそういう理由からですかね。

PHPのinternal encodingもSJIS、MySQLのcharsetもSJISですか？
MySQLへのinsert時はmysql_escape_stringとかかけてます？
他にPOST/GETされたデータに対してかましてる関数や、MySQLから読み出した後表示するまでにかましてる関数などありますか？Smarty等のテンプレートライブラリなどは使ってますか？

ってな感じで、調べるところはいっぱいあるかも。

[8] mixiユーザー 12月08日 18:55

ありゃ？PHPとは書いてないのか。失礼。

[9] mixiユーザー 12月08日 19:39

> フォームから受け取ったデータ文字コードの変換は一切行っていません。

ということですが、

クライアント
SJIS ↓ ↓ ↓ (無変換)
アプリケーション SJIS
SJIS ↓ ↓ ↓ (アプリケーションレベル、データベースレベルいずれも無変換)
データベース SJIS

な状態なのでしょうか？

[10] mixiユーザー 12月08日 19:49

さらに携帯がクライアントである場合に入力データが必ずSJISで送信されてくるのでしょうか？

[11] mixiユーザー 12月09日 07:36

> クライアント
> SJIS ↓ ↓ ↓ (無変換)
> アプリケーション SJIS
> SJIS ↓ ↓ ↓ (アプリケーションレベル、データベースレベルいずれも無変換)
> データベース SJIS
↑このとおりですSJIS以外を使うシーンはありません。

METAでﾀｸﾞShift_JIS宣言をしていますし、なにより問題の文字以外の部分(入力項目)は全てShift_JISでやりとりできていることで必ずShift_JISで送られていることは証明済みです。

文字コードとしては全体を通して無変換ではあったのですが、プログラムの別の部分で絵文字に対する処理（絵文字をキャリアに会わせて置き換え）が加えられていたようでした。DBそのものではなく、この部分が原因の可能性もでてきましたのでそちらを調査してみます。

みなさんいろいろとありがとうございました。

[12] mixiユーザー 12月09日 12:50

PHP使われてるのか、Perl使われているのか、Java使われているのか、よく分からないのですが、表面上はShift_JISを使っていても、内部コードは別なコードである可能性が高いですよ。（というか、普通は違う）

あと、絵文字を使っていなくても、MySQL に文字コードを変換させると、化けますよ。

[13] mixiユーザー 12月09日 14:28

> 12
・HTML/ﾌﾟﾛｸﾞﾗﾑで文字コードを揃えて記述し文字コードの変換をプログラム中で行わない状態(11の説明のとおり)、であってもなぜかどこかで変換をされているのものだという解釈で良いですか？この件についての資料や参考ﾍﾟｰｼﾞなどあればご紹介ください。

> MySQL に文字コードを変換させると、化けますよ。
MySQLに文字コードを変換させた覚えはないですが、命令なしでも勝手に変換するものなのでしょうか？経験上そういった変換を目の当たりにしたことはないのですが。ちなみに絵文字は問題なく読み書きされていました。

[14] mixiユーザー 12月09日 15:51

プログラム(PHP?)にデバッグコードを入れた上で
* ブラウザー入力時の「廿日市」
* ウェブアプリが受け取った時の「廿日市」
* ＤＢに格納したときの「廿日市」
* ＤＢから取得したときの「廿日市」
* ブラウザーに表示した時の「廿日市」
の文字列データを取得して、どこから変わっているのか確認したらどうでしょうか？(unixのodコマンドなどを使って)
原因の可能性が限定できると思います。

[15] mixiユーザー 12月09日 16:47

ぬさんの方法で特定したところ、ブラウザに表示する寸前まで化けていないことが分かりました。

11にも書いたようにブラウザに出力させるタイミングで携帯に合わせたの絵文字の置き換え処理がありましたのでそこが原因であると思われます。(DBとは無関係の処理になります)お騒がせしました。また、色々なご意見ありがとうございました。

ログインすると、みんなのコメントがもっと見れるよ