vs文字コード

ブンのローカル環境や実際に動かすWebサーバー上では問題ない。でも別の人のローカル環境だと文字コードの関係でテストコードでエラーが発生する

と、いう問題にぶち当たって脳が死にそうだった数日前…文字コードなんてキライ…

なんとか解決にこぎつけたので、メモメモ。

原因になっていたのはmbstring関数

まあ、あるあるだよネ?

ていうか文字コードが文字化けして問題が起こるのってだいたいこれ絡みじゃなかろうか?違う?違ったゴメン。

ブンはmb_convert_kana()を利用して、全角スペースを半角スペースに変換する処理を入れていました。それからtrim()で余分なスペースをカットしようというのです。

さらにそうした後、特定の1文字だけの入力であった場合はエラー!

と、したかったのですが、これが上手く引っかからない。引っかからずスルーして「エラーはないよ」って結果を返してしまう。

ぼんやり、「文字化けしたせいで別の文字判定受けてるんだろうなー」ということは理解。相談に乗ってくれた人がハッシュ値というものを出力して確認してくれて、やっぱり変に変換されてベツモノになってしまっている、ということが確定しました。

ハッシュ値…とは…(ま、また別途勉強しときマス…)

mbstringにはデフォルトの文字コード設定がある

知らんかった(ドーン

mbstring.internal_encoding

これネ、この設定。これ自体は知ってるし、内部文字エンコーディングという言葉も知っていた。でもそれが意味するところを分かっていなかった。これが敗因か…!

内部文字エンコーディングって、単純にmbstring関数で文字コードの指定がない場合(デフォルト)に使用する文字エンコーディング設定らしい。

ブンのローカルphp.iniはEUC-JP。で、別の誰かさんは…UTF-8とか多分その辺だったのでは。(確認はしてないけど)

だからようするに、mbstring関数で処理したくて渡した文字列の文字エンコーディングを関数の引数で指定してなかった場合、内部文字エンコーディングの設定値で文字列が処理されるのだ、ということ、のようだ。

へえ、へえ…それで実行する環境によって化けたり化けなかったりするわけだな!

ということで修正

PHP公式マニュアルをチェック。

string mb_convert_kana ( string $str [, string $option = “KV” [, string $encoding = mb_internal_encoding() ]] )

最初の$strつまり処理したい文字列以外は省略可能。で、ブンは…

mb_convert_kana($str, 's')

という形で記述していたわけです。(’s'は全角スペースを半角に変換する指示オプション)

これを、

mb_convert_kana($str, 's', 'EUC-JP')

こうじゃ!

はい、これで環境に左右されずに(自分のローカルphp.iniをUTF-8に書き換えたったヨ)エラー判定が正常に行われました…めでたしめでたし…

ちなみに、指定文字エンコーディングは、ブンが扱っているプログラム群のファイルが基本EUC-JPだからこうしているだけで、UTF-8のファイルだったならUTF-8でいんでないかな?