[PHP]ハングルを扱うサイト。メール送信で文字化け。

Read More

はい、PHP。

多言語対応のサイト構築についての話。

アメリカ向けのサイトならば文字エンコードは気にしなくてもよいのだけど、中国向けとかだと中国漢字が入ってくるのでそうはいかない。


今日はMさんに多言語サイト作成時の文字化けについて尋ねられた。

M:「フォームからハングルの値を送ったら次画面で文字化けするんだけど解決方法わかります?」

へえ。
ハングルってことは韓国か?


以前中国語サイトを作ったときフォームから値を送ったときは文字化けなんかしなかったけど、ハングルだとまた少し違うのかね。


とりあえずローカルで適当にフォームを用意してさっそく試してみた。

すると…

ん?別に普通にできてるぞ。
画面遷移を挟んだって文字化けせずちゃんと値が取れてる。

ってことは何かいらんことやっとるんだろうな。
やれやれ。


ひとまずサーバのPHP設定を確認してみた。

phpinfo()っと。

…おいおい、文字エンコードが設定初期のままじゃん。

internal_encodingがEUC-JPになってて、ファイル自体はUTF-8、http_inputがautoでencoding_translastionはONになってる。

むちゃくちゃだ。
そりゃ文字化けするわ。


文字化けの原因が特定できたので簡単に説明してやった。
php.iniの設定でmbstring辺りを変更しなさいと。


しかし聞くと、すでに稼動しているものなのでいまさらphp.iniの設定変更ができんらしい。
どこに影響が出るかわからんからと。


ふっふっふ。




あほか!




だったら全部作り直せよ。

現時点で文字化けに困っているのにいまさらも何もないだろう。
多言語サイトとか作るんだったらまずこの辺からちゃんとしろ。
むしろよくこれで今まで問題にならなかったもんだ。

…とは言わなかった。
思ったけど。


まあよくよく聞くとこのサイト、他の会社の人が主だって進めているらしい。
その会社の方が解決方法がわからずどうしようもなくなってMさんへ泣きついてきた、ということらしい。

だから作り直ししようとするとそちらから動かさなければならない。

まあ現実的に考えたら説明することはともかく、相手に納得してもらうのは簡単ではないな。
というかそこまでしてやる義理もメリットないし。



とりあえずその場しのぎとして.htaccessで指定ディレクトリだけでも文字コード変更したら?って伝えた。

M:「…うーん」

???
いまいち反応がにぶい。

聞くとどうもmbstring周りの設定を完全に理解してるわけではないぽい。


仕方ないのでこちらで設定してやると…

ん?あれ?htaccessが効かない。


まさかと思いながらサーバのヘルプを読むと、
「セキュリティの関係で.htaccessが使えない」
ってしっかり書いてある。


マジかよ…
サーバ借りるとき、もしくは案件受けるときに確認しろよ。

しかし逆に納得した。
なるほど、それで(方法がわからんから)PHPの設定変えずにそのままやってたんか。


どうしようか考えていると少し下のほうに、
「.htaccessの代わりにphp.iniが利用できます」
と書いてある。

しかもphp.iniが指定ディレクトリに設置できるぽい。

何じゃその設定…まあいいけど。


php.iniを指定ディレクトリに設定して、改めてフォームからハングル文字を入れて送信してみると、
次画面で問題なく表示できた。


あとはがんばってくれ。



…数十分後…


M:「メールにハングル入れたら文字化けするんだけど…」



知らんわ!ww



あんた俺より年上でしょうwwww
今までよくそれでやってこれたねwwww


でもまー原因はなんとなく想像ついたので聞いてみた。

俺:「メールの文字エンコード何使ってます?」

M:「iso-2022-jpです」

俺:「(市ね!)…そうですか…」

多言語メールに何の疑いもなくそんなもの使うなよ…


まあ韓国のことは詳しくないので知らんが、
日本語同士でも文字化け問題はある。

複数の文字エンコード間での変換がうまくいかないのだ。
その主なものにShift-JIS、EUC-JP、UTF-8と3つある。

だからきっと同じように韓国にも2~3個文字エンコードがあるんだろう。
そんで日本と同じように文字エンコードの変換で文字化けとかもありそうな気がする。
# 調べてないから知らん

日本語ですら解決は難しいのに韓国語とか中国語とかが文字エンコード変換で文字化けしたら日本人の俺にはきっと解決不可能だろう。


いちいち国ごとに文字エンコードを設定するのも変換かけるのも色々と面倒ごとが多そうなのでUTF-8で統一してやったら?と薦めた。

た、だ、し、
日本でもUTF-8メールは完全対応してないメールソフトがあって文字化けが発生することが十分ありえるよってことだけは伝えた。



…数十分後…


M:「UTF-8でもうまくできない。どうやったらいいかわかります?」

俺:「…ふ」

もはや乾いた笑いしかでなかった。


カタカタカタ…
fsocketを使ってUTF-8のメール送信処理を書いてみた。

自分向けにメール送信と。ぽち。

…コーン!

どれどれ…って普通に問題なく送れてるね。
文字化けもしてない。


その後も何度かチェックを行ったが特に問題なし。


もはやMさんに確認するのも面倒だったのであくまでこれは想像だが、
Mさんはたぶんmb_send_mail()あたりを使ってるような気がする。

fsocket使ったメール送信の仕組みを説明するのも面倒だったので、
処理ファイルと関数ファイルの2つを渡した。


俺:「それをサーバにそのまま置いて、一切何も変更せずWebアクセスしてみてください。」
俺:「そしたらメールが飛んでくるので確認してみてください。」



…数分後…


離れた席から声が聞こえる。

M:「おーできた。できました。」

俺:「…(そりゃできるわ)」



…さらに数分後…


M:「なんか本文の途中から文字化けするんだけど…」

俺:「」



気を取り直して確認するとなるほど、
確かに本文の途中から文字化けしている。


俺:「とりあえず文字化けした本文の元データまるごともらえますか?」

もらった。


自分の環境で試してみた。
…問題ない。

本番サーバで試してみた。
…問題ない。


あれれ?



~ここから結論まで長いので省略~



さて結論。
Windowsのメールソフト(OutlookとThunderbird)だとUTF-8でハングルを受信しても問題ない。
Macのメールソフト(名前は知らん)だとUTF-8でハングルを受信すると本文の一部が文字化けする。

つまり送信自体が問題なんじゃなくて、あくまで受け手側の問題だったことが判明した。


おー早速メールソフトで差異がでたか。


先述したようにUTF-8でメールを送ると対応していないメールソフトで問題がでることがあるってことは知識として知っていた。
だが実際に自分がその現象にぶつかったことがなかった。


今日始めてMさんが役に立った気がした。

自分一人じゃハングルとか扱うこともないしMacを使うこともないのでこの現象はきっとわからなかっただろう。

今回は色々時間を取られたが、まあこの現象に遭遇できたことはいい経験になったからよしとしよう
↑ポジティブ

ま、根本的な解決方法はわからずじまいだけどね。





ちなみにMさんは、
「Macのメールソフトを使わなければいいだけ」
と言ってそのままUTF-8を使うことを決めたようだ。


まあ俺もそれしかないと思う。




人柱、人柱




-- 2012/05/02 修正 --
"文字コード"という表記から"文字エンコード"という表記に変更。