がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

マルチバイト周り基準のphp.ini調査

一度整理したかったんだけど…思った以上に魔窟でした orz


大分とメモ書きなところもあるので、適当に脳内補完しつつ読んでみてください。
「理屈はえぇから設定みせろや」な場合(…まぁエンジニアとして妥当な姿勢かどうかには果てしなく疑問が残るところではありますが)、マルチバイト周り基準のphp.ini 設定草案( http://d.hatena.ne.jp/gallu/20120726/p2 ) をごらんくださりませ。


では早速。


default_charset = 出力文字コード
PHP_INI_ALL
header()

PHP は、デフォルトで常にContent-type:ヘッダで character encodingを出力するようになっています。charsetの送信 を無効にするには、これを空にしてください。

この辺は、個人的にはviewクラスで処理したいなぁ。
だから、offをお勧め。


magic_quotes_gpc = Off
PHP_INI_PERDIR
?

この機能は PHP 5.3.0 で 非推奨となり、 PHP 5.4.0 で削除されました。

躊躇なくoff。丁寧にやるなら「バージョンチェックしてから」なんだろうけど、ざっくり確認すると「ini_setでのtypoはメッセージとか出ないぽい」ので、問答無用上書きでもいいと思った〜。
違ったら音速で修正するw


?
?
setlocale(LC_ALL, 'ja_JP.UTF-8');

ロケール情報を設定する

結構あちらこちらに影響するぽいのだけど。顕著で致命的なあたりだと、fgetcsvとか。
おっかないのは「ロケールの命名方式は、システムによって異なります」ってあたり。なので一端Linux前提で。

内部文字コード…そろそろ固定UTF-8でもそろそろよくないかしらん?

うちの手元のLinuxの場合、可能なロケール情報って以下程度。

$ locale -a | grep ja_JP
ja_JP
ja_JP.eucjp
ja_JP.ujis
ja_JP.utf8

でも、あちこちのサンプルだと大抵「setlocale(LC_ALL, 'ja_JP.UTF-8');」なんだよねぇ。大文字小文字はいいとして、ハイフンは必要?不要?あっても無視?
一応あちこちで引っかけてみた、使えるか分からんのを書いておきま

ja_JP.UTF-8
ja_JP.utf8
ja_JP.eucJP
ja_JP.SJIS
ja_JP.ShiftJIS
ja_JP.ISO-2022-JP
en_US.utf8
C

MW的には、内部文字コードは「utf8一本」にしたいところだなぁ。一応ちゃんとDRYだから、変更するのは手間じゃないと思うので。


?
mb_language

e-mailメッセージのエンコー ディングとして使用されます

しらなかったなぁ「mb_send_mail」専用ですかw
だとすると、フレームワークの「初期設定」としては「書かない」が正しいんじゃないかしらん?
mail系クラスに書くべきなんだろうけど…まぁそもそもmb_send_mail、おいちゃん使わないしなぁ(苦笑


mbstring.detect_order = UTF-8,sjis-win,eucjp-win,JIS,ASCII
PHP_INI_ALL
mb_detect_order("UTF-8,sjis-win,eucjp-win,JIS,ASCII")

文字コード検出のデフォルト値を定義します。

まぁ色々悩ましいところ(苦笑
でもまぁそろそろ「UTF-8固定」にしたいところぢゃないかなぁ?
後は、判定用に、ダガー(†)なり美乳なり(おいちゃんは「雀の往来」がお気に入り)を入れるとして。


mbstring.encoding_translation = Off
PHP_INI_PERDIR

入力される HTTP クエリに関して、 文字エンコーディング検出および内部文字エンコーディングへの変換を行う 透過的な文字エンコーディングフィルタを有効にします。

ようは「http requestで入ってきた情報を、問答無用で内部文字エンコーディングに変換処理行うよ」的な。
Offを限りなく推奨。


mbstring.func_overload = "0"
PHP_INI_SYSTEM
?

シングルバイト対応の関数を mbstring 関数の対応する関数でオーバーロード (置換)します。

これやると結構あちらこちらで「致命的」なので( http://ie2.php.net/manual/ja/mbstring.overload.php )、全力で避けましょう。
精々が"1"、が限界かねぇ。


mbstring.http_input = "pass"
PHP_INI_ALL
?

HTTP 入力文字エンコーディングのデフォルト値を定義します。

autoかpassか。自力でやった方が良いので、passを選択。
やるべき場所は「cgi_request」クラスが妥当だと思う。


mbstring.http_output = "pass"
PHP_INI_ALL

HTTP 出力文字エンコーディングのデフォルト値を定義します。

mbstring.http_inputと同様に、passで。
やるべき場所はviewクラスの出力時。


mbstring.internal_encoding = UTF-8
PHP_INI_ALL

内部文字エンコーディングのデフォルト値を定義します。

mbstring で使用される言語設定(NLS)のデフォルト値。 この設定は mbstring.internal_encoding を定義するため、 php.ini の中で mbstring.internal_encoding は、 mbstring.language の後に置く必要があることに注意してください。

実際には「mb系関数の、文字エンコーディング指定が省略された時のdefault値」。
内部はUTF-8固定でよくない? いい加減。


mbstring.language = "Japanese"
PHP_INI_ALL

mbstring で使用される言語設定(NLS)のデフォルト値。 この設定は mbstring.internal_encoding を定義するため、 php.ini の中で mbstring.internal_encoding は、 mbstring.language の後に置く必要があることに注意してください。

今ひとつ不明なれど、おそらくinternal_encodingとセットになるブツ。


mbstring.strict_detection = Off
PHP_INI_ALL

厳密なエンコーディング検出を行います。

今ひとつ不明なれど、どうも mb_detect_encoding() 関数と深く関わるらしい。
第三引数で明示的に指定すればいいので、一端offで。


mbstring.substitute_character = ""
PHP_INI_ALL

無効な文字を代替する文字を定義します。

文字コード変換で「おかしな値」が入ってきたときに出す、代替文字の指定。"?"でもいいような気がする。
「mbstring.substitute_character = none」って設定方法だと「だめぽよ〜」って情報あり(未検証)。
MWでは?にしておきませう。「消える」と色々びっくりするからw


mbstring.http_output_conv_mimetypes
PHP_INI_ALL?

PHPマニュアルでざっくり見ても見つからず orz
リスト( http://www.php.net/manual/ja/ini.list.php )にも乗ってない orz
しもさんところ( http://d.hatena.ne.jp/shimooka/20080919/1221800058 )が、一番丁寧で詳しくてわかりやすいと思う
おいちゃん的にはmb_output_handler使わないからいらないかなぁ。この手の処理は、viewクラスにまとめて委譲しちゃってるし。
ところで、http_output_conv_mimetype?http_output_conv_mimetypes?どっち?


mbstring.script_encoding
PHP_INI_ALL

リスト( http://www.php.net/manual/ja/ini.list.php )には乗ってるんだけど、詳細なし orz

script_encodingは、スクリプトをinternal_encodingとは違う
エンコードで書きたい場合の指定。
スクリプトから文字定数を変数へ代入した際はinternal_encoding
へ自動変換される。
スクリプトphpタグ外に記述されているHTMLも同様)
ただしscript_encodingが有効となるのは、--enable-zend-multibyte
コンパイルされたPHPのみ。

との話。
http://d.hatena.ne.jp/do_aki/20111208/1323315995
がわかりやすいかも。
おいちゃんそもそも「コードん中に出力用の文字とか書かない主義」なので、気にせず。


むぅ…色々とあるなぁ(苦笑

全体的に、ここが面白かった。
PHPの文字化けを本気で解決する( http://hain.jp/index.php/tech-j/2007/02/13/p125 )
一読をお勧めします。