人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

PHPで携帯サイトを作成する際の質問です。

PHPの設定で「mbstring.encoding_translation」(HTTP入力文字コード自動変換)
というのがありますが、どういった状況で変換の必要があるのでしょうか。
変換が発生するケースを教えてください。
また、この「mbstring.encoding_translation」の設定値が「Off」(無効)の場合
手動でHTTP入力文字コードを変換する必要があるかと思いますが、
例えば下記のようなコードで変換した場合、変換元と変換後の文字コードが同じ場合、
二重に変換されることはないのでしょうか。

mb_convert_variables(mb_internal_encoding(), 'SJIS-win', $_POST);

その他、「mbstring.encoding_translation」は「On」にした方がよいという意見や、
WebサイトでのHTTP入力処理の定石みたいな情報も歓迎いたします。

●質問者: mikadeko
●カテゴリ:コンピュータ ウェブ制作
✍キーワード:HTTP ON PHP SJIS webサイト
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● pahoo
●50ポイント

どういった状況で変換の必要があるのでしょうか

たとえば、携帯サイトにFORM入力を用意したような時、携帯ブラウザから送られてくる文字コードはシフトJISになっており、PHPスクリプトがEUC-JPで書かれている場合が、それに当たります。


二重に変換されることはないのでしょうか

ありません。


WebサイトでのHTTP入力処理の定石みたいな情報も歓迎いたします

私は下記のような設定をお勧めします。

  1. HTML フォーム
    1. accept-charset 属性を指定しない。
    2. enctype="multipart/form-data"を指定しない。
    3. エンコード・タイプを変数として渡す。(例:ei=UTF-8)
  2. サーバサイド(PHP)
    1. mbstring.http_input を pass にする
    2. mbstring.internal_encoding を明示する
    3. POST 渡しする側の HTML フォームを mbstring.internal_encoding に合わせる
    4. 受け取った PHP スクリプト側では、エンコード・タイプを元に、 mb_convert_encoding でコード変換するとともに、不正なデータでないかどうか検証する。

詳しいことは「ページ間での文字化けを解消する」をご覧ください。

◎質問者からの返答

回答ありがとうございます。

>たとえば、携帯サイトにFORM入力を用意したような時、携帯ブラウザから送られてくる文字コードはシフトJISになっており、PHPスクリプトがEUC-JPで書かれている場合が、それに当たります。

なるほど。最終的に表示されたページの文字コード(ヘッダーのcharset)でPOSTされるからということでOKでしょうか?

>ありません。

了解しました。

>1.accept-charset 属性を指定しない。

これはブラウザによって未対応だからということでしょうか?

>3.POST 渡しする側の HTML フォームを mbstring.internal_encoding に合わせる

携帯サイトの場合はSJISで表示すると思いますので、その場合、mbstring.internal_encodingとPHPスクリプトもSJISにするということでしょうか?


2 ● b-wind
●50ポイント

どういった状況で変換の必要があるのでしょうか。

ご自分の書いたサンプルコード通りだと思いますが。

GET/POST で渡ってきたパラメータの文字コードと PHP で使用する内部文字コードが違う場合に使用します。


例としては携帯サイトの様にキャリアごとに適した文字コードが違う場合、

DBとの兼ね合いで内部文字コードを特定の物にしたい場合などがありますね。

あとは最新のバージョンはどうだか知りませんが、PHP は Shift_JIS 系の文字コードの扱いが苦手だったと記憶しています。


変換元と変換後の文字コードが同じ場合、

二重に変換されることはないのでしょうか。

エスケープ処理や何らかの変換処理ではなく、単なるマッピングなので「文字コードがまったく同じ」ならば何も起きません。


WebサイトでのHTTP入力処理の定石

文字コード周りはややこしいのでいくつか方法が有るでしょうが、基本的には On にしない方が良いでしょうね。

理由はどんな文字コードが入ってくるかが原理的に保証できなく判定ミスの可能性がある事と、必ずしもすべて変換できるとは限らないからです。

公開された環境では何が送られてくるか分かったものでは無いので、入力が想定の範囲内であることを確認してから

手動で変換処理を行います。

とはいえ、ある程度アクセスの限られた状態であればリスクを覚悟すれば On にすることもあります。

自動はやはり楽ですから。


出来るならば、ブラウザ・PHP・DBの文字コードはすべて統一し、どの部分でも一切変換処理が入らないのが理想です。

よく問題になるのは「?」ウェーブダッシュですね。

詳しく書けばきりがないのでこんなところでしょうか。

◎質問者からの返答

回答ありがとうございます。

>出来るならば、ブラウザ・PHP・DBの文字コードはすべて統一し、どの部分でも一切変換処理が入らないのが理想です。

そうですね。色々調べるのも大変ですし、Web上の情報も交錯してますし、自分でもそうしたいのですが、携帯サイト等のように文字コードに制限があったり、最新のDBや開発環境等でのUTF-8化があったりと階層間の足並みが揃ってないので個人では遺憾ともしがたいように感じています。


3 ● pahoo
●50ポイント

最終的に表示されたページの文字コード(ヘッダーのcharset)でPOSTされるからということでOKでしょうか?

ブラウザによっては、ページのcharsetで応答を返すとは限りません。(とくにIE)


> 1.accept-charset 属性を指定しない。

これはブラウザによって未対応だからということでしょうか?

その通りです。


携帯サイトの場合はSJISで表示すると思いますので、その場合、mbstring.internal_encodingとPHPスクリプトもSJISにするということでしょうか?

その通りですが、PHPはシフトJISを扱うのが得意ではありません。

XMLやWebAPIを扱うのであればUTF-8がデフォルトなので、出力の部分だけSJISに変換した方がいいように思います。

◎質問者からの返答

再度の回答ありがとうございました。

なんとなく入力から出力までの流れが見えてきたような気がしますが、新たな疑問も湧いてきそうなのでお二方ともその節はまたよろしくお願いします。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ