price-change:blog CodeIgniter リクエスト値を内部文字コードに変換処理
PCサイトと携帯サイトを同じURLで運営してると、フォームで送信した場合、データの文字コードの問題が出てくると思います。それなら、統一してしましょうと頑張ってみた。 やり方は2通りあると思います。一つは、Inputライブラリの CI_Inputクラスを拡張する方法。もう一つは、コアファイルをいじることなくフレームワークの内部動作を変更する方法(フック)です。個人的には CI_Inputクラスをいじりたくないので、フックする方法で文字コード変換処理を実現させてみたいと思います。 まずは、application/config/config.php の設定値を変更。 $config['enable_hooks'] = TRUE; 続いて、application/config/hooks.php に以下のコードを追加。$hook['post_controller_constructor'] はコン
htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
mb_check_encodingは何をチェックするのか（その1 SJIS編） - hnwの日記
(2009/02/15 17:20)「個人的な感想」を追記しました。また、下記はPHP5.2.1以降の挙動です。PHP5.2.0以前のmb_check_encodingは更にカオスなので、あまり使い物にならないと思います。 (2009/02/16 12:30)追記2：バグっぽいと思った件は本当にバグで、修正がhttp://news.php.net/php.cvs/56276の通り取り込まれました。PHP5.2.9から修正される予定です。 (2009/02/22 16:20)追記3：他のエンコーディングについても調査しました。「（その2 EUC-JP編）」と「（その3 UTF-8編）」も合わせてご覧下さい。 PHPのmb_check_encoding関数が一体何のチェックをしているのか、エンコーディングごとに一通り調べてみます。 まずはSJISとSJIS-win(CP932)について調べてみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
