phpinfo()のmb(Multibyteつーことだと思われ)関数の部分の見方が分かりやすく説明されているページをめっけ。
元ネタは、nakahara21(まみお)さんちのこの記事。
で、ウチの利用中のサーバのmb関数settingを確認すると・・・
こんな感じ。
Multibyte Support |
enabled |
Japanese support |
enabled |
Multibyte (japanese) regex support |
enabled |
mbstring extension makes use of “streamable kanji code filter and converter”, which is distributed under the GNU Lesser General Public License version 2.1. |
Directive |
Local Value |
Master Value |
mbstring.detect_order |
no value |
no value |
mbstring.encoding_translation |
Off |
Off |
mbstring.func_overload |
0 |
0 |
mbstring.http_input |
pass |
pass |
mbstring.http_output |
pass |
pass |
mbstring.internal_encoding |
none |
none |
mbstring.language |
neutral |
neutral |
mbstring.substitute_character |
no value |
no value |
ウチも、mbstring.languageの値はneutralだったりするんだけどなぁ。
ま、今のところ、さしたる大きな文字化け問題などないし、いいか・・・つー感じだし、このサーバってspencerさんの管理だから、settingに穴があることもあるまい・・・ってな調子で考えているんですけど、だめっすか!?(^^;;
今いちどころか、今10ぐらいこのあたり分かってないなぁ・・・私。
ん?それとも、nucleusを2.5とかに上げると問題でたりするのかちら。
コメント
こんにちわ。
僕もよくわかってませんが、PHPのバージョンアップ時に文字化けが起こることは
あるみたいです。
僕もべつにmbstring.language=neutralで問題なかったのが、
ちゃんと指定しないと文字化けするようになって以前に焦ったことが。
PHPが無指定時のオプションの解釈を変えるようになったのかな?
>僕もべつにmbstring.language=neutralで問題なかったのが、
>ちゃんと指定しないと文字化けするようになって以前に焦ったことが。
なにをしたらそうなるんですか?
やっぱ、Nucleusのヴァージョンアップとか?
>PHPが無指定時のオプションの解釈を変えるようになったのかな?
分かってしまえば、至極簡単なセッティングの優先順位なんでしょかねぇ・・・
# ますます、ちゃんとPHPの本買わないと・・・(^^;;
まみおさんちのAndyさんのコメントのコードを実行した結果、
ウチのサーバでは、
ASCII→JIS→UTF-8→EUC-JP→SJIS
という順で、検出されているようです。
mbstring.detect_orderの値がno valueとかautoに設定されている場合、こうなるという話が、
例の“One Shot — Mb Function”というページにも記載されているので、ま、実害が出てから考えようかと、のんびりしています。 😳
>なにをしたらそうなるんですか?
>やっぱ、Nucleusのヴァージョンアップとか?
いえ、先にも書きましたがPHPのバージョンアップ時です。
ホスト会社がそういうの何も連絡しないのでものすごくあせりました 😆
detect_orderがautoだとそれがデフォルトですね、検出順。
(detect_orderがASCII→UTF-8しかない例って海外のサーバーかと)
僕の場合はdetect_orderは問題なく、encoding_translation、internal_encodingが
バージョンアップ時に影響を受けてたみたいです。
よくよくチェックしたらlanguageの影響は特になかったみたい・・・
そっかー・・・
mbstring.encoding_translationと、mbstring.internal_encodingを規定しない場合、振る舞いが、phpのヴァージョンによってちょいと変わる場合があると・・・。
φ(..)メモメモ