実は一般公開はしてないんだけど、２年前、ウチのバンドのメンバー専用にコミュニケーションサイトをPHPで自作したの。
基本はPCとケータイ、双方からアクセスできる掲示板サイト。
それに簡易メーリングリスト機能を取り付けたやつ。
要は誰かが掲示板に書き込むと、メンバー全員に同じ内容のメールが届く仕掛け。
もちろん送らない選択もできるようにしてある。
あと自分でも頑張ったなと思うのは、管理ページにアクセスして次の練習日と場所、一言を入力すると、サイトのトップページに入力した内容のバナーが自動作成されてスクロール表示され、練習日の３日前になるとメンバー全員にリマインダーメールが自動送付されるって機能。
当時はバリバリとスクリプトを書いてたから勢いで作れたけど、今じゃもう無理ですな(^^;)。
ソース読み返してもそんな面倒くさいコード書いた記憶がない！
でも２年前はPHPを知ったばっかりの頃で、自分でそういう機能を組み上げるのが面白かったんだろうと思う（遠い目）。
ただ、ひとつだけ、当時からちょっとした不具合を抱えてた。
原因が分からなかったのと、再現性がなく、致命的な問題でもなかったのでそのままにしていたんだが・・・。
文字化け。
たまにサイトから送信されるメールが文字化けをしてたのですよ。
でも掲示板サイトの文字は化けていないので、届いたメールが読めなくても、ワンクリックして掲示板サイトに飛べばその内容はすぐにわかるようになってるんだよね。
なので今までそんな気にしなかったんだけど・・・でも・・・丸々２年そのままにしておくってのは、う〜ん、さすがの僕も気が引けるって感じで・・・ムムムッと、やっと重い腰を上げるに至りました(^^;)。
で、昨日の午前中、色々ネットでググって調べてみたんだけど、どうも「これが原因！」ってのがわからない。
言われるがまま、試しに色々スクリプトを書き直したりしたんだけど、文字化けが直るどころかもっとひどい状態になってしまったorz...。
で、右往左往しながら結局辿り着いたのがこのサイトでした。
携帯にメール送信すると文字化けする
文字コードとか改行コードってちょっとややこしいんだよね。
WinとMacではそれぞれ違うし、Linuxでも違う。
ウェブサイトの文字も、それを扱うサーバーやクライアントPCの出自によってコードがバラバラだったりする！
ホントこれが困るのよ。
Winや昔のMac、ケータイ用のウェブサイトはSJISの文字コードで作られてるけど、UNIXやLinux、今のMac用のサイトはEUC-JPという文字コードが主流です。
さすがに最近はUTF-8で統一させようとする動きはあるみたいだけど・・・それはそれで色々と問題があるらしい(^^;)。
ケータイ以外の、最近のPC用ブラウザーはみんな自動的に文字コードを切り替えて表示するから、サイトを閲覧するにはほとんど問題ないんだけどね。
大きな問題が出るのはウェブサーバーからメールを扱うときなんですよ。
これが曲者なのでございます。
実はメールで使う文字コードはISO-2022-JPってやつ。
当然、SJISやEUC-JPを扱ってるウェブサーバーから、文字データを直接メールサーバーに渡したりなんかしたら大変なことになってしまう。
全部文字化けです。
なので、その間にエンコード作業を入れこんで、文字を変換させる必要があるわけです。
PHPの関数でいうと、それを行うのがmb_convert_encodingってやつ。
２年前、その当該スクリプトを書いたときも、この関数を「テキトー」に使って文字コードを変換してたのでありました。
どのくらいテキトーとか言うと・・・。
「あ。さっきは文字化けしてたけど今回はちゃんと送れた。よかった〜成功成功！あ。でも今送ったやつが文字化けしたな・・・まあいいや。サーバーの調子が今イチなのかな。うん。そのうちなんとかなるわ。なるなる。ほらなった〜！今度は成功！」
・・・っていうぐらいテキトーでした。
ごめんなさいorz...。
実は僕はここで大きな間違いをしていたのでした。
PHPは基本的によくできる子なので、メールを送信する前にわざわざ文字コードをmb_convert_encodingでISO-2022-JPに直さなくてもよかったらしいのです。
なんと、メールサーバに送信を受け渡す関数、mb_send_mailがエンコードも含めて一手に引き受けてくれていたようなのです。
ウ〜ン。
つまり僕は２重にエンコード作業をしていたと。
しかもエンコードする文字コードの種類も間違ってたっぽいしorz...。
あ〜救いようがございません。
まあでもとりあえずこれで文字化けの原因が判明したわけで。
早速コードを書き直して、約２年ぶりにこのサイトのバージョンを０．０１上げました(^^;)。