月が替わって、トラブル発生!MySQLで文字化け発生中

月が替わったイメージ

早いもので、もう3月です。

普段は、あまり月の話などしません。

しかし、月が替わってトラブルが発生しました。

アクセス解析のデータが、文字化けし始めました。

急に、文字化けです。

気が付くと、3月になっています。

この辺に、原因がありそうです。

アクセス解析のデータは、MySQLで保管しています。

すぐに、データベースを見てみました。

2月から、このブログを始めたので、今回初めて、月が替わります。

確認すると、3月のデータテーブルが出来ていました。

月ごとに、新規のテーブルが作られるようです。

いやな予感がしました。

私は、趣味でプログラムを組んだりします。

そして、データの保存には、MySQLを使います。

ここで、いつも問題になるのが、文字化けです。

これには毎回、悩まされます。

そして、解決するまでに、かなり時間が掛かります。

いつもMySQLで文字化けが発生した時は、日本語と言う言葉をうらみます。

もし、日本も英語をしゃべっていたら、こんな苦労はしません。

一人、文句を言っています。

じつは、ある程度の文字化け対策はあります。

しかし、私は趣味でプログラムを作るので、いつもどうやったかは、綺麗に忘れています。

思い出すのに、調べたりして時間が掛かります。

考えられる、原因はテーブルの文字コードが変わったことです。

そこで、テーブルの文字コードを調べました。

すると、2月のテーブルと、3月のテーブルでは文字コードが違う事がわかりました。

どうも、プログラムの不具合だと思います。

なぜならば、2月の間は、文字化けなどありませんでした。

ちなみに、MySQLのテーブルの、文字コードをたしかめるsqlは

SHOW FULL COLUMNS FROM hoge_table;

これによって、新しく作られたテーブルの文字コードが違う事がわかりました。

しかし、一度作ったテーブルの文字コードの変更がわかりません。

調べてみましたが、やり方を見つけることが出来ませんでした。

いろいろと考えた結果、とりあえず変更する事が出来ました。

そのやり方は、まず、テーブルをエクスポートします。

そして、出来たsplを開くと、テーブルを作るsqlが書いてあります。

それを見ると、テーブルの文字コードの指定があります。

それを、変更したい文字コードにして、インポートします。

しかし、文字化けしたデータはそのままです。

とりあえず、これからはちゃんと表示されるので、良かったです。

ちなみに、ソフトが原因だと思っていた文字化けの発生でしたが、それは違いました。

先日、サーバーを引越しした時に、アクセス解析のデータベースも引越ししました。

そのときに、改めてデータベースを作ったのですが、文字コードの設定を間違えていました。

思い込みってこわいですね~ はっ、はっ、はっ

アクセス解析のソフトを作った作者の方、疑ってすみません。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク